The most strange bug ever! REAL light speed

[NickyNick]

I was playing around and suddenly happened this. I don't know what to say... It's amazingly strange!

Looks like insanely big speed. Or teleportation?

[McGinge]

lol thats really random!!!! it must either dissapear to way outside the level boundary or go really fast somewhere....

[Ikerous]

Wow o.O

Why does the portal blink the and the level end five seconds later?

[CN Player]

He will swallow your soul also the dillo.

[TSchultz]

I think it has something to do with the dark paddle being insanely close to blowing up. Add a rope to any node, make a piece of cloth fall on anything. It will go BOOM

It either goes REALLY REALLY REALLY FAST
or vanishes.

I'm too lazy to replace the metal plates with tensioned cloth or something since that'd make more sense i think.

edit:
Tensioned cloth version attached.

Also... The metal plates attached to rocket dissapear too. So i'm thinking the Dillo also dissapears.

[NickyNick]

I think there's bug somewhere in Peter Stock's program. I was lucky and unexpectedly found a combination of objects which make program to use division by zero when setting coordinates of dillo and some other disappearing objects.
No other ideas.

[NickyNick]

O_o When I tried to change level boundaries, bug vanished.

[peterstock]

I've tracked down this bug now - here's an explanation of what's going on:

The problem in this case is in the armadillo-link collision code. A collision is flagged when the armadillo and the relevant part of the link are close enough and their relative velocity along the collision normal axis is positive (i.e. they are moving together, not apart). Then the velocities are stored for the collision and used in the collision resolution calculations later on.

The problem is that because of floating point optimisations, at the point when the test for relative velocity being positive is made, the velocity variables are held at a higher precision than normal floats are stored at. Then the later calculations use these numbers after they've been rounded to the normal floating point precision, but at this point they are equal. Unfortunately this breaks the code which assumes that it can use the relative velocity as a divisor, and hence infinite velocity and thus infinite position in later calculations.

I really should have done some research into the problems that can arise from floating point compiler optimisations before I released the game. Now any change I make will affect the way all levels/solutions play out, so I'm saving up all the simulation-affecting bug fixes to be fixed in a new release.

[NickyNick]

Thanks a lot for fast response, Peter!
I have some features and ideas for new version. If it won't spam you too much, I'll email you them a bit later.