PreCollision does not fire when isSensor = true

Solar2D General Questions/Discussion
#1

Hi!

In my game, the physics body and the collision detection of the “hero” is declared like this:

physics.addBody(hero, "dynamic", { density = 0.0, friction = 0.0, bounce = 0.2, radius = 75 }) hero.collision = onHeroCollision hero:addEventListener("collision", hero) hero.preCollision = onHeroPreCollision hero:addEventListener("preCollision", hero)

There is also a “bomb”, which is declared like this:

physics.addBody(bomb, "static", { friction = 0.0, bounce = 0.0, isSensor = true })

If isSensor for the bomb is set to true, the precollision for the hero does not trigger when the hero collides with the bomb. It only triggers when isSensor to false. I cannot find anything about this in the documentation. Have I misunderstood anything?

#2

sensors only detect contact, they do not collide, period, so you won’t get pre/post collision events on a sensor.

it can be a bit confusing (and/or misleading) that box2d’s begin/end “contact” callback maps to Corona’s “collision” event (and pre/post-solve callbacks map to pre/post-collision events), but rest assured that sensors only generate contacts not collisions - as that is exactly their designed/intended purpose.

#3

@davebollinger: the thing is that the collision listener is triggered, it’s just the PREcollision listener that is not triggered. Also, in the documentation for isSensor it says:

"A sensor is a fixture that detects collisions but does not produce a physical response. Sensors do not generate contact points.

The isSensor property is a set-only boolean value that, if set to true, prevents any visible collisions from happening to the object, although “began” and “ended” collision events are still fired."

To me, this would indicate that the sensors do/should produce collision events. I’m not saying you’re wrong, I just do not understand how you mean…

#4

Corona uses the event “collision” to handle the box2d callback “contact”.  That is, when corona says that your sensor has a “collision”, what they really mean is that your sensor has a contact - a sensor will not ever have a true collision.  Or reworded: when corona docs says “detects collisions” what they really mean is “detects contact”; when they say “visible collisions” now they’re talking about “collision response” (which will not occur on a sensor).

A true collision implies a potential *collision response*, which does not happen with sensors.  When no collision response is needed, box2d won’t generate the manifold (the thing that stores the collision points) because it’s not needed and would be wasteful calculation, so corona docs are correct that there will be no contact points available during a sensor “collision” (as corona calls it, though it’s the wrong terminology)

A true collision, with a potential response, and therefore a manifold needed, is the only way to get contact points, and/or pre/post collision events which, again, will never happen with a sensor, since sensors don’t “collide” when you understand what that word means and use it properly (and corona does NOT use that word correctly, or at least not in the same manner that box2d internals use it).

#5

It took me a few readings but I think I understand what you mean now…

So the collision event is really is a “contact event” and the collision listener is really a “contact listener”, which is triggered for all contacts (sensors and non-sensors). The pre/post-collision events, however,  are events triggered only for those special cases of contact where there is a contact response (non-sensors).

Is that correct? If so, it would be nice if the documentation reflected this so that it becomes clear why sensors behave the way they do.

#6

change that bit to “collision response (non-sensors, dynamic bodies).” and you’ll have a good summary.

corona’s terminology is fine most of the time for casual audience.  it only becomes an “obstacle” in these tricky cases when trying to truly understand its inner workings, contrasting those docs versus the wealth of box2d experience out there using other terminology.

#7

Thanks for all your help!

#8

sensors only detect contact, they do not collide, period, so you won’t get pre/post collision events on a sensor.

it can be a bit confusing (and/or misleading) that box2d’s begin/end “contact” callback maps to Corona’s “collision” event (and pre/post-solve callbacks map to pre/post-collision events), but rest assured that sensors only generate contacts not collisions - as that is exactly their designed/intended purpose.

#9

@davebollinger: the thing is that the collision listener is triggered, it’s just the PREcollision listener that is not triggered. Also, in the documentation for isSensor it says:

"A sensor is a fixture that detects collisions but does not produce a physical response. Sensors do not generate contact points.

The isSensor property is a set-only boolean value that, if set to true, prevents any visible collisions from happening to the object, although “began” and “ended” collision events are still fired."

To me, this would indicate that the sensors do/should produce collision events. I’m not saying you’re wrong, I just do not understand how you mean…

#10

Corona uses the event “collision” to handle the box2d callback “contact”.  That is, when corona says that your sensor has a “collision”, what they really mean is that your sensor has a contact - a sensor will not ever have a true collision.  Or reworded: when corona docs says “detects collisions” what they really mean is “detects contact”; when they say “visible collisions” now they’re talking about “collision response” (which will not occur on a sensor).

A true collision implies a potential *collision response*, which does not happen with sensors.  When no collision response is needed, box2d won’t generate the manifold (the thing that stores the collision points) because it’s not needed and would be wasteful calculation, so corona docs are correct that there will be no contact points available during a sensor “collision” (as corona calls it, though it’s the wrong terminology)

A true collision, with a potential response, and therefore a manifold needed, is the only way to get contact points, and/or pre/post collision events which, again, will never happen with a sensor, since sensors don’t “collide” when you understand what that word means and use it properly (and corona does NOT use that word correctly, or at least not in the same manner that box2d internals use it).

#11

It took me a few readings but I think I understand what you mean now…

So the collision event is really is a “contact event” and the collision listener is really a “contact listener”, which is triggered for all contacts (sensors and non-sensors). The pre/post-collision events, however,  are events triggered only for those special cases of contact where there is a contact response (non-sensors).

Is that correct? If so, it would be nice if the documentation reflected this so that it becomes clear why sensors behave the way they do.

#12

change that bit to “collision response (non-sensors, dynamic bodies).” and you’ll have a good summary.

corona’s terminology is fine most of the time for casual audience.  it only becomes an “obstacle” in these tricky cases when trying to truly understand its inner workings, contrasting those docs versus the wealth of box2d experience out there using other terminology.

#13

Thanks for all your help!