Box2D linearVelocity problem

[wizlon]

Hi

I've come across a very weird problem that I can't get to the bottom of, I'm hoping someone can help although Box2D seems to be a bit of a law upon itself sometimes.

Essentially what I'm doing is "firing" (think, out of a cannon) the player using setLinearVelocity using an X and a Y force (gained by finding the X and Y coordinates of an angle and multiplying them by a force), most of the time this works just fine but every now and again the force exerted is far too large for the values supplied and the character gets propelled further than anticipated, it isn't completely random as this happens with some cannons more than others but for no discernible reason.

I have dropped in some log points and the values passed are consistent every time even when the anomaly happens. Suspecting a problem with my input I've added in touch buffers and timers to make sure the function isn't be called more than once but that doesn't appear to be happening/have helped. It's also worth nothing that before applying the setLinearVelocity I am removing any existing physics from the body so they do not mess with what I am doing at the time, or at least I think I am (may have to log this data to make sure).

If anyone could shed some light on this I would highly appreciate it.

[Saurav]

Are you actually firing it 'out' of a cannon object? Could it be colliding with something on its way out, and that's changing the direction of movement?

[wizlon]

Good thinking, but no, I have a amnesty timer which ignores the collision of the player and the previous cannon. The anomaly isn't like it's a collision problem, in it doesn't fire in the wrong direction, it appears to apply more force than it should be. I have noticed this problem happens with cannons that are closer to geometry though so there may be some kind of collision going on... somewhere.

If there's one sort of bug that really grinds my gears, it's inconsistent ones.

[mzechner]

Do you use variable delta times for your world stepping or fixed times?

[wizlon]

I use the variable delta step function that I borrowed from some of your examples:

Code: Select all

accumulator += delta;
          while (accumulator >= stepTime)
          {
             step(stepTime);
             accumulator -= stepTime;
          }

As a result everything seems to be consistent between PC and Phone, even this inconsistent bug.

[mzechner]

You could cap the "delta" to something like 1/20. I can imagine that something in your game makes for a loong pause for some reason, making the delta time huge (e.g. 1 second or more). This would be the only explanation i could come up with explaining what you see. Could you give it a try? Could you also output the delta and screen it for such an anomaly?

[wizlon]

Sorry for the late reply, been away for the weekend, I'll give that a try later and see if that helps. Cheers for the help though.

[wizlon]

Yo.

Again, sorry for the late reply, I've been putting off looking into this bug (a bad idea, I know) but I've finally decided to have a look into it.

To investigate I put in a log every update to output the delta and a log of the force I am applying on my character to "fire" them across the map. Here is a section of what I got.

Code: Select all

: Delta: 0.001542457
: Delta: 0.0015335176
: Delta: 0.0015589672
: Delta: 0.0015776589
: Delta: 0.0015907472
: Delta: 0.0015961364
: Delta: 0.0015552461
: Delta: 0.0015425426
: Delta: 0.0015681207
: Delta: 0.0015931424
: Delta: 0.0016129886
: Delta: 0.0016100373
: Delta: 0.0015734669
: Delta: 0.0015597369
: Delta: 0.0015833045
: Delta: 0.0016264191
: Delta: 0.0016466931
: Delta: 0.0016485325
: Delta: 0.0016200034
: Delta: 0.0016163677
: Delta: 0.0016315093
: Delta: 0.0016785162
: Delta: 0.0017126913
: Delta: 0.0017167547
: Delta: 0.0016925882
: Delta: 0.0016563602
: Delta: 0.0016418602
: Delta: 0.0016567878
: Delta: 0.0016779602
: Delta: 0.0017029392
: horizontalForce 0.45369342| verticalForce 12.992081
: Delta: 0.0017052488
: Delta: 0.0016626047
: Delta: 0.0016653851
: Delta: 0.0017325804
: Delta: 0.001797723
: Delta: 0.0018491779
: Delta: 0.001888657
: Delta: 0.0019049101
: Delta: 0.0019160736
: Delta: 0.0019198805
: Delta: 0.0018937469
: Delta: 0.001913422
: Delta: 0.0018924208
: Delta: 0.0018536688
: Delta: 0.0018022567
: Delta: 0.0017679104
: Delta: 0.0017286881
: Delta: 0.0016960527

As you can see before and after the force is calculated and applied everything seems fairly ok, just the usual fluctuations you would expect.

I them decided to just to start changing things (when in doubt eh?) and I modified the steptime from 0.03, and reduced it to 0.028, since I did that the problem appears to have dissapeard (either that or I'm getting very unlucky and it won't replicate). What could cause this behavour? Unfortunately since I've channged the step time it's making the physics work differently and it's breaking some of my levels (i'v only done a dozen or so, so it's not too bad).

Any thoughts or suggestions? This whole thing is a bit.... odd.

Thanks again. A

[wizlon]

After looking into this further (I must have spent a dozen hours on this now) I've now managed to descover the problem. For some reason my character is colliding with the level geometry when I am firing them out of the cannon, but this isn't happening every time. It's not happening on all cannons, just ones near geometry so the simple solution is to move the cannon away from the geometry, but I would rather solve this problem properly.

Is there a way to turn the collisions for an object off for a short time, it only has to be for a couple of frames, just so I'm not getting the collision.

Failing that, can anyone think of a solution for this problem?

Any help would be more than appreciated as I'm seriously running out of ideas, cheers.

[t4ils]

you can use filters to ... filter collisions :p
http://www.box2d.org/manual.html (goto 6.2 Fixture Creation, filtering)

just tell your character not to collide with the geometry until X frames. (thx to category an mask bits)
You put a filter so that no geometry is touched when firing, and then set this filter to be able to touch anything X frames later