schedule() time variation

#1 i wonder if you're overflowing a U32.
schedule works by getting the current simulation time (milliseconds since the application began) and adding your offset to it, then registering an event to take place at that simulation time.

but as a U32, the current simulation time only wraps every 1,193 hours or so, which implies that you would only see that problem once every 1,192 hours or so. hm..

it might be drift in Simulation Time versus wall time,
which i was noticing a while back but never really pursued.
check out this thread. not much in the way of answers, i'm afraid, but might give you some experimentation ideas.

it looks like you don't have a license,
so one moderately-ugly-but-definitely-workable workaround might be to keep track in script of the reatime when you want this event to occur (eg, "$gEventRealTimeMS = getRealTime() + 60 * 60 * 1000;") and then have a repeating schedule() which fires every twenty seconds or so and checks if getRealTime() is bigger than $gEventRealTimeMS. if it's important that the event fire exactly in one hour instead of one hour plus-or-minus twenty seconds, you detect when the event is coming up in the next minute or so, and then issue a schedule() for it to occur on-the-dot.

#2 woops, that thread is in the private forums, sorry.
it doesn't really say much other than i was noticing that elapsedSimTime was about 0.96 times elapsedRealTime over the course of three minutes.

#3 If Orion has indeed diagnosed the problem (sim time differing from real time), then that could be your issue. However, why not try repeating the schedule every minute, and counting up to 60? This would avoid any potential problems with large numbers.