Okay, I have been working with corona for about 3 weeks now, and thinks its great! but it has some problems that I have a HARD time getting through. One of these seems to be Physics Bodies. And I just wanted to start a thread where these are THOROUGHLY explained. Because they are driving me crazy, and I think are not very well explained or documented by Ansca (Not complaining!)

So there are three types of physics bodies, we all know that:

Static: Cannot be moved and dont respond to gravity (walls and floors etc)

Kinematic: Can be moved, but dont obey gravity (great for sensors!)

Dynamic: Normal physics bodies, respond to touch and gravity

Then there is the collisions that can happen between them

Static ONLY collides with dynamic

Kinematic ONLY collides with dynamic

Dynamic collides with Dynamic/Static/Kinematic

This is where box2d seems really stupid, because for some reason, they think its easier for EVERYONE to use dynamic objects when clearly gravity is a big factor in designing games. I for one want to use kinematic objects more often, And I know everyone says "Just turn the gravity to 0 and use dynamic", but I am one to say that it doesn't always work like that, and almost always complicates things a lot later on.

Then there is the isSensor property, which still doesn't make a lot of sense to me. From my understanding, its makes that body NOT interact with any other physics object, but still registers collision events, and obeys the same properties of the original body(dynamic/static/kinematic). For example:

A dynamic sensor will still fall from gravity, but will not collide with any static or kinematic objects *Physically*(it will still register collision events)

Or a Kinematic sensor will register collision events, but will not obey gravity, or affect any other normal physics body physically.

So here is where my problem is: I have a couple of dynamic bodies on my stage that I can drag around and throw just fine. They collide with walls and register collision events fine ONLY when they are the ones initiating those events. Then I have a "laser" in the middle of my screen that can rotate all the way around. It is an image that gets shown by changing the "isVisible" property. I have made the image itself a kinematic-sensor. So physics isnt affecting this "laser" in any way. I am rotating it with code.

I have all three bodies attached to a collision function:

1
2
3
4
5
6
7
8
9
10
11
12

local function laserCollision( self, event )
        if(event.phase == "began" ) then
                if(event.other.name) then
                        print(self.name.." with "..event.other.name.." Began")
                end
        elseif ( event.phase == "ended" ) then
                if(event.other.name) then
                        print(self.name.." with "..event.other.name.." Ended")
                end
        end
        return true;
end

Thank you for the response! Let me try to answer all of those:

1. Yes, I have it set to hybrid and everything looks normal, the bodies arent abnormally large or miss-colored or anything

2. No, the console is just printing those collision statements mentioned earlier

3. I am just setting lazer.rotation = whatever I need

4 The lazer is attached to the head of a rag doll. Not by a joint, but I simply made the reference point of the lazer to the left-center, and then do:

1	lazer.x = head.x; lazer.y = head.y;

Okay, I don't really have any way to verify this for sure but I remember reading a while ago on the forums about how using a reference point other than center can cause physics oddities. Doing a quick forum search I found these posts:
http://developer.anscamobile.com/forum/2011/03/20/wrong-physics-collisions-when-body-rotated-and-reference-point-not-centered
http://developer.anscamobile.com/forum/2011/03/06/reference-point-breaks-physics
Unfortunately since you're having problems I'm assuming it hasn't been fixed in Corona yet and there doesn't seem to be a fix or workaround that I can find.

Ahh, case 4272. Reference point throwing off physics. Unfortunently it still seems to be open... And not resolved. @Ansca/@Carlos any update on the situation? The ticket was opened back in March according to the first of the above posts, but no update on the thread. Heading to bump it right now.

Anyways thank you so much for your help, you found the problem at least, and that comes as great news for me, as it means i am not going crazy :) Props to @calebr!

Sorry, I was a bit tired when I posted about the problem and didn't offer a solution (well it's really more of a hack). One workaround that I can think of would be to make a complex body out of the lazer and making one of them a sensor so that it won't respond to anything. So if your lazer is a rectangle shape then just define two rectangle shapes as a complex physics body with one being "static" or "kinematic" and one being a sensor. Then you can have the reference point be the center of the physics body (which means you shouldn't have any physics oddities) but your rotations should still work correctly. Not the most elegant solution but it should work.

I solved this problem of rotation of a pinball flipper around one end of the image by using a transparent graphic so as to position the flipper to one side, putting the pivot at the center of the graphic. You can see the image file and working code at http://martinapps.com/files/pinballphysics.zip

views:1993 update：2011/9/27 18:14:54