preCollision fires after "began" phase of collision?

Games
#1

Reading the api doc I got the impression that the time sequence of a collision event is preCollision - collision began - collision end - postCollision. But the print out from Collision Detection sample is this:

first crate: collision began with ground
Global report: ground & first crate collision began
**** 1 – 1
preCollision: first crate is about to collide with ground
preCollision: first crate is about to collide with ground
postCollision force: 132.51472473145, friction: 0
first crate: collision ended with ground
Global report: ground & first crate collision ended

It seems the sequence is collision began - preCollision - postCollision - collision ends

What is the proper sequence? and How do I nullify a collision right before it is about to happen? For example, I need to do certain calculation when the collision is about to happen but don’t want it to actually happen.

Thanks. [import]uid: 8745 topic_id: 4071 reply_id: 304071[/import]

#2

Just wondering if you managed to find a workaround. This bug s still there, still nobody cares to reply about it. [import]uid: 21280 topic_id: 4071 reply_id: 26466[/import]

#3

I encountered some weirdness when I was trying to use “postCollision”. “Post” was happening before “ended” according to the terminal, but when I checked the timing of the events with the system timer, they were actually being fired at the same time.

Posted about it here:
http://developer.anscamobile.com/forum/2011/03/04/collision-cannot-translate-resolved-error-bug-workaround

So maybe collision event states are buggy in general.

On the other hand, my pre-collision events were fine. You might try changing crate to .isSensor=true on “began” and setting all velocities to 0 (basically ‘pausing’ it), do your calculation, then change the sensor/velocity settings back. [import]uid: 41305 topic_id: 4071 reply_id: 26479[/import]

#4

Thanks for the tip, I’ll give it a try and let you know.

Here’s the bug that I encountered, can you please run the example and say if you have the same result. Maybe I’m using wrong build, which version you have? Are you on subscription or using free version?

http://developer.anscamobile.com/forum/2011/03/05/urgent-precollision-happens-after-collision-bug
Thanks [import]uid: 21280 topic_id: 4071 reply_id: 26484[/import]

#5

I’m a subscriber but haven’t gotten a chance to install the latest build, so I’m using the free version. Your code executes the same on my machine; checking the timer, the pre fires the same time as the actual collision.

I was also wrong about saying that my precollisions worked fine–turns out that i’m just making the object.isSensor=true at the point of collision and not using precollision at all.

I’m a bit surprised so few people apparently are having this issue. [import]uid: 41305 topic_id: 4071 reply_id: 26497[/import]

#6

I’m also surprised how nobody seems to notice or care about some of these glaring bugs, not the Corona team and not the community. This is precisely the reason why I’m still undecided of using it for our projects. I posted another bug on incorrect multitouch events and it took me a great deal of hassle to get any acknowledgment from Corona. The bug is now apparently noted in their system but I as the free user can’t track it, id= #3558.

In regards to timer, I don’t think it’s necessary that time should be different in milliseconds on preCollision and collision, it depends how it’s implemented. But definitely it should be in correct sequence, i.e. first the pre-collision and then the collision.
I tried to use isSensor as you suggested but it doesn’t work at all. In fact I can’t get the isSensor to work at all. This might be yet a third show stopper bug.

This example is useless: http://developer.anscamobile.com/reference/index/bodyissensor#comment-26593

When I modify it as such, then it doesn’t work at all. Do you have maybe a working example to see how isSensor works in action?

Non working isSensor example:

local physics = require "physics"  
  
physics.start()  
local platform = display.newRect( 20, 200, 280, 15 )  
platform.myName = "platform1"  
physics.addBody(platform, "static", { density=1.0 })  
   
 platform.isSensor = true  
   
   
local box = display.newRect( 20, 20, 50, 50 )  
box:setFillColor(255,255,0,255)  
box.myName = "box"  
physics.addBody(box, "dynamic", { density=1.0 , bounce=.7 })

[import]uid: 21280 topic_id: 4071 reply_id: 26595[/import]

#7

Here is how I got around my problem. I realized that all I needed was to track the collision event but not let objects changing trajectory. So I simply used isSensor=true and avoided the original problem altogether. [import]uid: 8745 topic_id: 4071 reply_id: 26602[/import]

#8

Last snippet I posted shows that isSensor is not working at all - that is, the box stil bounces. Do you get the same behaviour? [import]uid: 21280 topic_id: 4071 reply_id: 26603[/import]

#9

I checked isSensor on your previous box example and it works fine, on either of the boxes.

Yeah, Corona’s support side as far as bugs go isn’t exactly a well-oiled machine. These forums are the only place for help, and they’re not organized very well and mod support is good–when it happens. The SDK may be in beta, but developer support is definitely stuck in alpha. Hopefully more people will start asking questions on stackoverflow.com and the like. [import]uid: 41305 topic_id: 4071 reply_id: 26626[/import]

#10

isSensor works as advertised in my case. Not sure why it doesn’t in your situation. [import]uid: 8745 topic_id: 4071 reply_id: 26628[/import]

#11

@both: You mean it does go through the platform, it does not bounce off? In my case it bounces off, no matter which one is sensor, even if both are set to sensors. [import]uid: 21280 topic_id: 4071 reply_id: 26633[/import]

#12

I used the old build. It works with Build: 2011.268
Thanks all. Yeah I get your point about developer support and that’s exactly why I can’t decide to purchase yet. [import]uid: 21280 topic_id: 4071 reply_id: 26635[/import]

#13

I just put a sensor above each platform that makes the body active when hit. Not elegant but it works really well. [import]uid: 8192 topic_id: 4071 reply_id: 32701[/import]