Vanishing Sprite?

I've hit on a little snag, yet again

Basically I've got a Thrust-style spaceship thing that hits a certain point (I can't determine what, exactly - it seems to occur when it is slowing down/coming to a stop) where the ship sprite just vanishes from the screen.

I've set up a couple of debug text boxes that continuously report the X and Y position as well as the X and Y velocities. After it has vanished, pressing W (to move forward) makes these text boxes report '-1.#IND'

Any idea what that is? Cheers

does your movement code involve divisions? it sound as if it might be dividing by zero once you pass a point, -1.#IND occurs when you divide by zero, a way to remedy it is always make sure you add a small value like 0.0000001 to the divisor, or have a check for the divisor, and if its = 0, set it to 0.0000001 or wtv

alternatively, it might be that your using numbers just way too big and going over the digit limit, but i dont think this is the case. are you using large numbers?

sorry about editing this on the fly i just tested something and i was making it too complicated for nothing

I thought divide by zero might be the cause, all the movement calculations use multiplication - I suppose it's easier to just post the cap here as it's very basic at the point anyways. I guess it's something to do with the friction of thrust calculations?

v99.92

http://www.mediafire.com/?ky1m1p7wcrqblcb

no, it has nothing at all to with your velocity, everything there is fine, it has to do with your value total angle, at a ceratin point if its in a location that allows it/the angle from ship to your mouse is bad, instead of bouncing back and forth, itll encroach zero, at that point, once it gets too long i suspect as a float, itll return -1.#IND or wtv, and then since your other actions are all somehow connected to it (you set the angle of an object, then you set velocity using it and set position and so forth) they all consecutively fail to work, since -1#IND is not a number, and so they return the same value aswell.

i think its an inherit problem with the way your decel on the angle is designed, it just pingpongs and it can be quite irratic as it shrinks (but gains decimal places) until it becomes a problem.

since the problem is that the number is too LONG your going to need to place a limit on what numbers you add with the angle diff

now what im going to post isnt the BEST fix, since im not sure whether or not the bug can still happen on rare occasions, but it does prevent the bug from happening 99.9999...% of the time im estimating

if this worries you, your best bet would probably be to scrap the current way or find a way to fix the way mouse/angle rotation is handled and rewrite it in a more stable manner that doesnt extend complexity as it runs on.

http://dl.dropbox.com/u/1010927/fixdspaceship.cap (fix on your current system)