I found the bug. You simply check to see if millisecs() is greater than fire time. But my PC has been running for a week straight, and the number millisecs() is currently returning is negative. That makes it imporrible for millisecs() to be greater than the fire time.
You need to change your timing code to handle when millisecs() is negative. I'm sure some folks here have worked out how to do that. In my own games, I just use the difference in time from one frame to the next, and the milliseconds count up to 0 when they are negative, so timenow-timethen with negative milliseconds works out right to give you a positive length of time between frames.
The only thing to worry about then is when millisecs goes from +2 billion to -2 billion. I check that the same way I avoid bugs caused by unnaturally long pauses when windows is thrashing the disk.... I simply don't update till the next frame if the time between frames is greater than say, 100 - 200ms.
You need to change your timing code to handle when millisecs() is negative. I'm sure some folks here have worked out how to do that. In my own games, I just use the difference in time from one frame to the next, and the milliseconds count up to 0 when they are negative, so timenow-timethen with negative milliseconds works out right to give you a positive length of time between frames.
The only thing to worry about then is when millisecs goes from +2 billion to -2 billion. I check that the same way I avoid bugs caused by unnaturally long pauses when windows is thrashing the disk.... I simply don't update till the next frame if the time between frames is greater than say, 100 - 200ms.