Can you please submit some code (or a sample) showing this physics issue in action with multi-bodies? If there is something going on there in 2.0, it needs to be investigated, but I’d like to see your sample or code exhibiting this behavior.
Thanks,
Brent
We are working to fix the public build archive page problem. Check back periodically.
Rob
fish = display.newImage( "images/fish.png" ) --fish.anchorX = fish.width / 2 --fish.anchorY = -fish.height / 2 fish.x = screenLeft fish.y = screenBottom - 40 fish.alpha = 0 fish.type = "fish" fish.collision = fishCollision lfx = fish.x fish:addEventListener("collision", fish) physics.addBody ( fish, physicsData:get("fish") ) fish.angularDamping = 2
For rock:
physics.addBody ( object, "static", physicsData:get(obj.name))
fishCollision:
local function fishCollision( self, event ) if event.phase == "began" then ...
physicsData:
local physicsData = (require "shapes").physicsData(1.0)
And shapes.lua is generated from physics editor:
["fish"] = { { pe\_fixture\_id = "", density = 2, friction = 0.6, bounce = 0.2, filter = { categoryBits = 1, maskBits = 65535, groupIndex = 0 }, shape = { 71.5, 15 , 72.5, 4 , 77.5, 13 } } , { pe\_fixture\_id = "", density = 2, friction = 0.6, bounce = 0.2, filter = { categoryBits = 1, maskBits = 65535, groupIndex = 0 }, shape = { 3.5, -46 , 31.5, -48 , 49.5, -34 , 72.5, 4 , 66.5, 23 , 28.5, 47 , -19.5, 1 , -17.5, -29 } } , { pe\_fixture\_id = "", density = 2, friction = 0.6, bounce = 0.2, filter = { categoryBits = 1, maskBits = 65535, groupIndex = 0 }, shape = { -13.5, 24 , -19.5, 1 , 28.5, 47 , 3.5, 43 } } , { pe\_fixture\_id = "", density = 2, friction = 0.6, bounce = 0.2, filter = { categoryBits = 1, maskBits = 65535, groupIndex = 0 }, shape = { 66.5, 23 , 72.5, 4 , 71.5, 15 } } , { pe\_fixture\_id = "", density = 2, friction = 0.6, bounce = 0.2, filter = { categoryBits = 1, maskBits = 65535, groupIndex = 0 }, shape = { 66.5, 23 , 61.5, 31 , 45.5, 43 , 28.5, 47 } } ...
rock:
["rock"] = { { pe\_fixture\_id = "", density = 2, friction = 0, bounce = 0, isSensor = true, filter = { categoryBits = 1, maskBits = 65535, groupIndex = 0 }, shape = { -28.5, -32 , -60, 3.5 , -54.5, -28 } } , { pe\_fixture\_id = "", density = 2, friction = 0, bounce = 0, isSensor = true, filter = { categoryBits = 1, maskBits = 65535, groupIndex = 0 }, shape = { -89, 17.5 , -118, 41.5 , -106.5, 11 } } , { pe\_fixture\_id = "", density = 2, friction = 0, bounce = 0, isSensor = true, filter = { categoryBits = 1, maskBits = 65535, groupIndex = 0 }, shape = { -60, 3.5 , -89, 17.5 , -75, 1.5 } } , { pe\_fixture\_id = "", density = 2, friction = 0, bounce = 0, isSensor = true, filter = { categoryBits = 1, maskBits = 65535, groupIndex = 0 }, shape = { -118, 41.5 , -140.5, 63 , -139, 49.5 } } , { pe\_fixture\_id = "", density = 2, friction = 0, bounce = 0, isSensor = true, filter = { categoryBits = 1, maskBits = 65535, groupIndex = 0 }, shape = { 98.5, 21 , -140.5, 63 , -118, 41.5 , -60, 3.5 , 44, -32.5 , 75, -21.5 } } , { pe\_fixture\_id = "", density = 2, friction = 0, bounce = 0, isSensor = true, filter = { categoryBits = 1, maskBits = 65535, groupIndex = 0 }, shape = { 143.5, 63 , -140.5, 63 , 98.5, 21 , 133, 38.5 } } , { pe\_fixture\_id = "", density = 2, friction = 0, bounce = 0, isSensor = true, filter = { categoryBits = 1, maskBits = 65535, groupIndex = 0 }, shape = { -60, 3.5 , -118, 41.5 , -89, 17.5 } } , { pe\_fixture\_id = "", density = 2, friction = 0, bounce = 0, isSensor = true, filter = { categoryBits = 1, maskBits = 65535, groupIndex = 0 }, shape = { -60, 3.5 , -28.5, -32 , 2, -63.5 , 3, -63.5 , 44, -32.5 } }
And that’s it.
Hi @mk_osowa,
I re-assembled your code and I’m getting all of the expected collisions using build 2076. This includes all parts of the physics body on the fish and rock. Please confirm that you’re not shifting groups around independently of each other.
Best regards,
Brent
All physics bodies are in the same group. I don’t know what I could make wrong. Friend sent me direct link to older version, which I still can’t access, I installed it and now physics are working well.
Hi @mk_osowa,
Please download the simple project that I put together based on your code. It uses the body definitions you provided but (of course) not the images, for which I substituted vector rectangles. This sample is giving me proper collision detection in build #2076… you will see “COLLIDE” printed in the Terminal repeatedly as the “fish” moves through the “rock”.
https://www.dropbox.com/s/pje6nrj0qzpbmas/stest.zip
When you download this, please let me know, so I can remove it from DropBox.
Thanks,
Brent
Hi
I’ve just made a lot of debugging and found this:
rock has referencepoint like this:
object:setReferencePoint(display.TopLeftReferencePoint)
if I turn it off reference point is center by default.
Then rock is placed on the wrong place of course, but collisions work as in older version!
I KNOW that now are anchor points, but I’m using compatiblilty mode. So compatiblity mode sucks 
Hi @mk_osowa,
Thanks for debugging this. I’ve always managed physics bodies on a center orientation. Admittedly, V1 compatibility will still require some changes for migration purposes, and this appears to be one of them (non-center-referenced physical objects).
Best regards,
Brent
There’s another strange issue with hybrid mode physics in graphics 2.0. If you move the Display Group that contains all of the physics bodies, all of the overlays for joints etc get out of line. I put all of my objects into a Display Group called ‘camera’, then on enterframe do:
camera.x=- player.x
Everything gets out of whack, at least visually with the hybrid mode, but it seems like collisions etc still work, so maybe it’s not that big of a deal but it sure makes developing a little harder to view your physics construction. If I take out the enterframe, it looks fine visually but then the player just runs off the screen which sort of isn’t so good. I’ve tried running in V1 compatability mode but it did not fix. With graphics 1.0 everything looked fine.
Welcome to Corona SDK - breaking your code since 2009 
I love your sense of dark humor!!! If this forum supported signatures that quote would be my signature going forward!
A whole day? You spent a FULL day on it, and didn’t finish? Now that’s some “true grit” right there! (j/k)
Seriously though, in mobile development (and most everything else technological) the one thing you can bank on is change.
Devices change. Operating Systems change. And consequently, good sdk’s change. One big plus of Corona actually, is how few “migrations” like this one (to graphics 2.0) are. IOS 6 came out, and you didn’t have to re-write your application. Or for iOS 7. Or for Android Ice Cream Sandwich. Or for Jelly Bean. Or for Nook. (and soon hopefully, not for Windows 8).
And so finally CoronaLabs implemented a major engine change (switching to openGL 2.0) and updated their API calls at the same time. Yes, this particular SDK update does force a “migration” instead of a simple rebuild of our apps (previous sdk updates hid many of the big OS changes in the past - and we never even noticed).
But a day and a half of migrating to be compatible with 1 billion+ devices isn’t really that much, relatively speaking.
Another way to put it is: CoronaLabs usually is able to keep your Ferrari race car driving around the track without stopping while they change out parts. In this very unusual case, they require you to pull in the pit stop for a quick migration.
IMHO CoronaLabs is doing a KICK ASS job. Period.
I admire Corona to have the guts to make breaking changes. These anchor points are much better than reference points for example. I’m sometimes annoyed by how they priorities some things though.
I’m on day 2 of converting my project. My biggest challenge has been when to apply the anchorChildren property. I would think I should have it always true as that was the previous default behavior but then strange things happen.
@jonjonsson - I’d agree the anchor points, and everything else I’ve looked at (after the bugs were gone) seems to work a lot better…
Agreed about the anchor points. It’s a lot better dealing with masks / masking too… and it’s also nice not having to reposition text objects after changing the text string (it repositions automatically now - so we can pull out the old code that would change text, reset the alignment and reset the x coord to get it to redraw properly).
I’ve got one big project, over 150,000 LOC and it took about a week to fully migrate on both platforms (must have been almost a thousand setReferencePoint calls, ugh). A dozen or so tableViews also took a little time to position / tweak just right, and a few other minor issues here and there. (after 2 days straight of only searching / changing setReferencePoint to .anchorX .anchorY I began bouncing off the walls, but a couple shots of romulan ale, and I made it through).
So a couple days aint bad, you’ll get there
@mpappas Wow thats a lot of reference points. I thought mine was pretty biggish with 130.
I didn’t know that we don’t need to reposition text after changing now. That is a nice change.
Was going bonkers with so much conversion – so looked to save a little time, and that helped…
Also FYI – you don’t need masks on your tableViews in 2.0 either… (dunno about other widgets)…
When creating a tableView, you used to set the paramater “maskFile” to your graphics mask, which was applied to the tableView. Now, you just set the height and width when you create it, and it’s automatically masked (so you can ditch the unneeded mask assets)
Didn’t notice any other big time savers.
I tested no mask on scrollViews and they work fine too. Have you tested the new reRender thingy yet? Thats next on my list.
Sorry! This page can’t be accessed.
I don’t agree with anchor Points. I was using xReference and yReference to stick one object to another and fully rotate with him now it’s all screwed and I have to recalculate it somehow… Not to mention 0…1 colors (I’ve read your reasons to change this and completly don’t understand this, 16 milion colours is not enough, huh?). The thing is I don’t know how to fix my problems (I’m talking about compatibility mode only, in 2.0 I’ll faster write game from scratch than fix so much bugs).
For example:
I have 2 backgrounds:
local bg1 = display.newImage(“images/background.png”)
bg1.width = screenWidth
bg1.height = screenHeight
--bg1.anchorX = 0
--bg1.anchorY = 0
bg1:setReferencePoint(display.TopLeftReferencePoint)
bg1.x = screenLeft
bg1.y = screenTop
group:insert(bg1)
local bg2 = display.newImage(“images/background2.png”)
bg2.width = screenWidth
bg2.height = screenHeight
--bg1.anchorX = 0
--bg2.anchorY = 0
bg2:setReferencePoint(display.TopLeftReferencePoint)
bg2.x = bg1.x + bg1.width + 200
bg2.y = screenTop
group:insert(bg2)
And on enterFrame I was moving them to like this:
bg1.x = bg1.x - speed
bg2.x = bg2.x - speed
bg1.y = camera.y + screenTop
bg2.y = camera.y + screenTop
if bg1.x + bg1.width - screenLeft < 0 then
bg1.x = bg1.x + screenWidth * 2
end
if bg2.x + bg2.width - screenLeft < 0 then
bg2.x = bg2.x + screenWidth * 2
end
if bg1.x - screenRight > 0 then
bg1.x = bg1.x - screenWidth * 2
end
if bg2.x - screenRight > 0 then
bg2.x = bg2.x - screenWidth * 2
end
In older version it was working. I had moving world with fish object.
Now there’s an black offset between them. I don’t know why… When I turn off compatibility mode offset is longer… I’m using these constants:
centerX = display.contentCenterX
centerY = display.contentCenterY
screenLeft = display.screenOriginX
screenWidth = display.contentWidth - screenLeft * 2
screenRight = screenLeft + screenWidth
screenTop = display.screenOriginY
screenHeight = display.contentHeight - screenTop * 2
screenBottom = screenTop + screenHeight
display.contentWidth = screenWidth
display.contentHeight = screenHeight
@mpappas: I don’t agree. I wrote an app for android 2.2 (few tousand lines of code), now it’s 4.4 and it’s still working like a charm. This is not how sdks should be updated. And you can’t downgrade to older version 
Strange… I can access it with no problems. Have you tried emptying your browser cache?