Is anything being done about this? I have the same problem. Working on a physics game and found out about this bug after I had started the game. I can’t get around it, and I’d like to have this fixed before I buy a subscription. [import]uid: 50195 topic_id: 16297 reply_id: 80177[/import]
@Gravedrinker
Here is a post I put up about this and some common fixes, then some abstract fixes that worked for me.
You can hit me up on twitter @cellphonegaming I’ll help you out. You could either post your sample code using simple shapes on here, or email it to me.
Here is the post:
http://developer.anscamobile.com/forum/2012/01/02/box2d-collisions-and-how-it-fails-sometimes
Basically, you will have to REALLY think differently. I ended up using scale of 6, and then 300 on gravity, and density of around 0.1. I was trying to get the same effect as if the scale was 60, gravity was 10 and density was 5. It still “feels” the same, yet it fixed 99% of my issues 
Let me know what you want to do, I’ll do my best to help you out
ng [import]uid: 61600 topic_id: 16297 reply_id: 80199[/import]
Thanks for the reply, I tried that out and what it got me was basically a very heavy ball, and it felt nothing like before. The bumpers and flippers weren’t strong enough to shoot the ball around anymore and when I increased the power the ball fell down extremely quickly due to the high gravity. Since it all moves so slow now I can’t really tell if the problem is any less severe now, since it only occurs at reasonable speeds.
I’m not sure what the next step should be now, I read through the thread you made but I’m not sure where to start. I’d like to keep the speed and feel of the ball physics the same as it would feel wrong if it was too slow or too heavy. [import]uid: 50195 topic_id: 16297 reply_id: 80356[/import]
–The main.lua
Here is some code to give an idea, I made this specifically for you Gravedrinker (lol, do you drink grave juice or something? hehe)
Basically, you said you are making a pinball game of sorts? I made a flipper “within” a flipper (one is red, one is green) then welded it to another object (refpoint)
What I want you to test out is if you have your flipper working now in your project, resize the flipper and place wherever you want. You only have the change the x and y of the refpoint which will move the flipper to wherever you like.
also, if you decide to resize the flipper1 and flipper 2, you may have to mess with the joint so the back of the flipper “centers” on the refpoint.
Soooooo here we go. Let me know what you come up with (I’m assuming you have a button or touch function that flips the flipper up and down, I provided some drag code you can see to drag the flipper up and down manually).
-Nick
--// the whole point of this is to demonstrate what I call a MULTILAYEREDMULTIOBJECTCOLLISIONDETECTION
--// or MLMOCD for short.
--How it works (it may NOT work for you, depends on your needs) you create an object like a wall for example
--Then you create a wall within the wall so it's essentially 2 layers. What happens is a fast moving object will hit the first wall
--and \*sometimes\* be caught by the second wall (it depends on your needs and how fast your objects move).
local gameGroup = display.newGroup()
local groundGroup = display.newGroup()
local physics = require "physics"
physics.start(true)
physics.setGravity(0, 80)
physics.setPositionIterations(128)
physics.setVelocityIterations(128)
physics.setDrawMode( "hybrid")
physics.setScale(6 )
--shorcut variables to call the content width and height
local \_W = display.contentWidth
local \_H = display.contentHeight
local ball = display.newCircle (45,100,10)
physics.addBody(ball, {radius = 10})
--refpoint, this is what the "Flipper" will weld to and pivot off of
--This is also serves as the reference point for the flipper
--if you want to move the flipper, just move the refpoint
--this will save you time instead of recoding all the x and y's of other objects
--I use this type of style for all my games (saves a ton of time!
local refpoint = display.newCircle (44,500,1)
physics.addBody(refpoint, "static", {isSensor = true})
--I use the isSensor = true, that way it doesn't react with other physics object.
--if you wanted it to you would have to add a function etc, hit up techority.com (peachpellen's site) and search for "sensor"
--primary flipper (the first line of "defense")
--Red flipper
--since we are welding and the refpoint is static, give it some room, which is why
--there is a +10 on the refpoint.x (if you don't it will act strangely)
local flipper1 = display.newRect (refpoint.x,refpoint.y-10,100,30)
physics.addBody( flipper1, "dynamic")
flipper1:setFillColor (255,0,0)
gameGroup:insert( flipper1 )
--embedded flipper (the 2nd line of "defense") ..i know crazy
--Green flipper
local flipper2 = display.newRect (flipper1.x-50,flipper1.y-7,100, 15)
physics.addBody( flipper2, "dynamic")
flipper2:setFillColor (0,255,0)
gameGroup:insert( flipper2 )
--you COULD add a 3rd object layer, but I can't get the behavior to work correctly.
--weld weld flipper2, to flipper 1, using the flipper2.x and flipper2.y locations
--using "weld" type of joint on here (so it doesn't move)
local myJoint = physics.newJoint( "weld", flipper2, flipper1, flipper2.x, flipper2.y)
--now we create the attachment to the refpoint created earlier so we have a flipper
local myJoint2 = physics.newJoint( "pivot", refpoint, flipper1, refpoint.x, refpoint.y)
local ground = display.newRect (0, \_H/2 +200, \_W, 30)
physics.addBody( ground, "static")
groundGroup:insert( ground)
physics.addBody( groundGroup, "static")
local Lborder = display.newRect (0,0,20, \_H)
physics.addBody( Lborder, "static")
groundGroup:insert( Lborder)
--// I'll assume that you already have some code with a listener that triggers the flipper
--This is some drag code (pixel perfect, where you touch is where it "grabs"
local function dragBody( event )
local body = event.target
local phase = event.phase
local stage = display.getCurrentStage()
if "began" == phase then
stage:setFocus( body, event.id )
body.isFocus = true
--Change body to dynamic while we are moving the maze around
event.target.bodyType = "dynamic"
-- Create a temporary touch joint and store it in the object for later reference
body.tempJoint = physics.newJoint( "touch", body, event.x, event.y )
elseif body.isFocus then
if "moved" == phase then
-- Update the joint to track the touch
body.tempJoint:setTarget( event.x, event.y )
elseif "ended" == phase or "cancelled" == phase then
stage:setFocus( body, nil )
body.isFocus = false
event.target:setLinearVelocity( 0, 0 )
event.target.angularVelocity = 0
--After the event ends, change body back to static.
--// this one is useful if you want to move something, but have it be dynamic, and then turn "static" when done :)
--event.target.bodyType = "static"
-- Remove the joint when the touch ends
body.tempJoint:removeSelf()
end
end
-- Stop further propagation of touch event
return true
end
--add event listener for the flipper so you can drag it around
flipper1:addEventListener( "touch", dragBody ) –the config.lua
application =
{
content =
{
width = 768,
height = 1024,
scale = "Letterbox",
fps = 60,
antialias = true,
imageSuffix =
{
["@2x"] = 2,
},
},
} –build settings
settings =
{
orientation =
{
default ="portrait",
supported =
{
"portrait"
},
},
}
[import]uid: 61600 topic_id: 16297 reply_id: 80732[/import]
If you have a “heavy ball” that means you need to adjust the gravity to a really high amount, and mess with the density etc.
When you change things like I did with a small scale like 5 or 6 and use a .1 density, you have to tune everything else HEAVILY to get the same feel.
Gravedrinker, I’m looking at that pinball example (pinball madness) I feel that pinball example is a quickly put together example that needs a TON of work to even get it working semi correctly.
I would instead, borrow from the example, take the touch functions for the spring, bumpers and flippers and rebuild the rest of the environment
I’m not much of a pinball guy, but this is highly interesting to me for solving the physics issue
ng [import]uid: 61600 topic_id: 16297 reply_id: 80849[/import]
Here I re wrote the physics editor file.
I noticed you had scale 6 in the config.lua, I think that should be part of your main.lua (or if you had modular levels, then a level1.lua etc)
I changed the iterations to 128 on both
physics.setPositionIterations(128)
physics.setVelocityIterations(128)
Also I made the draw mode hybrid so you could see what the corona/box2d engine sees (normal, hybrid or debug)
physics.setDrawMode( “hybrid”)
Basically all I did was increased the thickness of the flipper so it’s beefy as hell. I made it THICK. Since the ball doesn’t really touch the bottom you can get away with it here.
You could argue that when the ball comes down the side, it will hit the bottom of the flipper, this is true. You could add a “peg” basically which is small circle that shows up on some pinball machines in real life to deflect the ball…
Also, I am not sure if you ever tried this option
ball.angularDamping = # (ie, ball.angularDamping = .20)
What that does is slows objects down. When you apply damping, then you need to increase the gravity.
yes, welcome to the pain in the ass world of stupid box2d, which is FTW for the most part, but for this…not so much.
Try this out, and also you can try thickening your walls and bumpers. For the bumpers, you could add an event listener that applys an impulse so you get better bounce. You could also apply x and y offset so when a ball hits it, the bumpter moves a few pixels to the left and right, or up and down…I could go on and on but that is more of a feature and doesn’t help the physics problem
Anyway, here you go. I’m a pro with physics editor, so if you have issues let me know
btw, not sure if you know this but you can change the scale in the PE file (default is 1, but you can change it to something like .80 and it will shrink or zoom in on it, pretty handy in some situations).
this is the flipperright.lua
-- This file is for use with Corona(R) SDK
--
-- This file is automatically generated with PhysicsEdtior (http://physicseditor.de). Do not edit
--
-- Usage example:
-- local scaleFactor = 1.0
-- local physicsData = (require "shapedefs").physicsData(scaleFactor)
-- local shape = display.newImage("objectname.png")
-- physics.addBody( shape, physicsData:get("objectname") )
--
-- copy needed functions to local scope
local unpack = unpack
local pairs = pairs
local ipairs = ipairs
module(...)
function physicsData(scale)
local physics = { data =
{
["flipperright"] = {
{
pe\_fixture\_id = "", density = 2, friction = 0, bounce = 0,
filter = { categoryBits = 1, maskBits = 65535 },
shape = { -61.5, -0.5 , -51.5, -5 , 46, -21.5 , 48, 10.5 , -61, 15 , -66, 7 }
}
,
{
pe\_fixture\_id = "", density = 2, friction = 0, bounce = 0,
filter = { categoryBits = 1, maskBits = 65535 },
shape = { -45, 52 , -61, 15 , 48, 10.5 , 39.5, 49.5 }
}
,
{
pe\_fixture\_id = "", density = 2, friction = 0, bounce = 0,
filter = { categoryBits = 1, maskBits = 65535 },
shape = { 54, 0 , 48, 10.5 , 46, -21.5 , 54, -10.5 }
}
}
} }
-- apply scale factor
local s = scale or 1.0
for bi,body in pairs(physics.data) do
for fi,fixture in ipairs(body) do
if(fixture.shape) then
for ci,coordinate in ipairs(fixture.shape) do
fixture.shape[ci] = s \* coordinate
end
else
fixture.radius = s \* fixture.radius
end
end
end
function physics:get(name)
return unpack(self.data[name])
end
return physics;
end
and here is the flipperleft.lua
-- This file is for use with Corona(R) SDK
--
-- This file is automatically generated with PhysicsEdtior (http://physicseditor.de). Do not edit
--
-- Usage example:
-- local scaleFactor = 1.0
-- local physicsData = (require "shapedefs").physicsData(scaleFactor)
-- local shape = display.newImage("objectname.png")
-- physics.addBody( shape, physicsData:get("objectname") )
--
-- copy needed functions to local scope
local unpack = unpack
local pairs = pairs
local ipairs = ipairs
module(...)
function physicsData(scale)
local physics = { data =
{
["flipperleft"] = {
{
pe\_fixture\_id = "", density = 2, friction = 0, bounce = 0,
filter = { categoryBits = 1, maskBits = 65535 },
shape = { -35, 57 , -49, 34 , -60, 10 , 49, -2.5 , 49.5, 19.5 , 31.5, 57 }
}
,
{
pe\_fixture\_id = "", density = 2, friction = 0, bounce = 0,
filter = { categoryBits = 1, maskBits = 65535 },
shape = { 52.5, 13.5 , 49.5, 19.5 , 49, -2.5 , 53.5, 5 }
}
,
{
pe\_fixture\_id = "", density = 2, friction = 0, bounce = 0,
filter = { categoryBits = 1, maskBits = 65535 },
shape = { -63.5, -12.5 , -55, -22.5 , 49, -2.5 , -60, 10 , -65, -1 }
}
}
} }
-- apply scale factor
local s = scale or 1.0
for bi,body in pairs(physics.data) do
for fi,fixture in ipairs(body) do
if(fixture.shape) then
for ci,coordinate in ipairs(fixture.shape) do
fixture.shape[ci] = s \* coordinate
end
else
fixture.radius = s \* fixture.radius
end
end
end
function physics:get(name)
return unpack(self.data[name])
end
return physics;
end
[import]uid: 61600 topic_id: 16297 reply_id: 80911[/import]
Thanks a lot, I’ll check that out. As for the thickness of the walls and bumpers, I never had the ball passing through those, only the flippers when moving. The zooming out thing is something I wanted to look into as well. I was thinking that if everything was really big (bigger than the screen anyway) and then zoomed out to match the screen size it would maybe make the ball physics look more fluid, but I don’t know if that works, it was just a thought.
I’ll let you know how this worked out, thanks for putting so much effort into is. [import]uid: 50195 topic_id: 16297 reply_id: 80914[/import]
If you’re trying to limit the upper speed of physics objects you could try playing with their linearDamping (and possibly angularDamping) values. Both default to 0, or no damping.
For a physics object “ball” this line will set linear damping:
ball.linearDamping = 1.0
If you set damping too high then objects tend to feel “floaty”, but even just a little linearDamping on the ball, say 0.1, might be enough to limit the speed without floatiness. Useful values are probably going to be different depending on the scale of all the other variables in your simulation, so experiment.
If the paddles are physics objects controlled by forces then you could also try >0 damping values on them as well. Who knows, maybe that would help prevent paddles going through the ball.
Linear damping is kind of like air friction. Eventually a falling body in air reaches a terminal velocity. In a virtual pinball machine with 0 damping the ball would behave as if in a vacuum which might not be what you want.
You could also simulate air friction by applying a force every frame in the opposite direction the ball is moving, increasing the force with the speed of the ball. That might be a more realistic simulation of air friction, but not as simple to set up as linearDamping. [import]uid: 9422 topic_id: 16297 reply_id: 80932[/import]
I already played around with the damping, sadly that didn’t help. The ball often goes through the paddles when it’s moving at a steady speed, not necessarily when it’s suddenly accelerating or anything. Also it doesn’t fly through when the paddles aren’t moving, just when you flip it.
I just can’t get this to work AT ALL. [import]uid: 50195 topic_id: 16297 reply_id: 81482[/import]
I had similar issue,
made below change worked for me
physics.setPositionIterations( 16 )
edit: not entirely solved problem, it is happening occasionally [import]uid: 97420 topic_id: 16297 reply_id: 87305[/import]
@y.sravankumar
For me I COMPLETELY solved my problem but I’m dealing with a different set of circumstances. I can’t even reveal what I’m doing really, but it’s doing things with physics in a special way that gets around problem with Box2d.
With that said, I had to really mess with angular and linear damping, and doing calculations on retrieving velocity and slowing down velocity when it detects a collision (a pixel or 2 before hitting an object) then using that data to give a force or impulse in the projected direction(equal angle in, equal angle out like this symbol < ).
so if an object bounces towards a wall and the | is a wall
the O is a ball
—>>>O |
O<<
Then the ball goes back the way it came. Unless, it’s at an angle, then I have to take that stupid angle and reverse so the ball its one angle and comes out at an equal angle.
Then you have the matters of what if the ball is spinning? Then more stupid complex piss me off math comes into play and offset the angle based on some basic physics calculations…grr. This becomes important in a billiards based game where you apply “english” and spin on various parts of the cue ball (I toured 9 ball circuit and spent way to much time playin that game). This is probably something 99.9% won’t mess with, as unless you are crazy like me and want ultra realistic stuff then you have to get your hands dirty and do something about it.
Yes, it works but it’s unique to my situation. I’ve tried to apply what I’ve done to others, but everyone is different [import]uid: 61600 topic_id: 16297 reply_id: 87324[/import]
problem I’m facing is similar to kunio’s problem.
i read your other post
http://developer.anscamobile.com/forum/2012/01/02/box2d-collisions-and-how-it-fails-sometimes
my problem is exactly same as “gtatarkin” mentioned in above thread.
I’m running out of trials now, and getting frustrated with this stone age old implementation of physics in Corona
BTW, you have lot of patience to type that long posts (I checked most of your posts)
[import]uid: 97420 topic_id: 16297 reply_id: 87333[/import]