[slscripters] Status of timer during sim restart

[Fred Allandale]

I am trying to make a script auto-recover from a sim restart.  I have a ‘changed’ event that looks for CHANGED_REGION_START and runs some recovery code, but it does not appear to be triggering after a restart.  I also have a 30 second timer running.  If the ‘timer’ event ever triggers, the script goes to a different state (called ‘faulted’) that does not have a ‘changed’ event. The timer is used to trap failed responses from other scripts and/or dataserver events and is normally restarted every few seconds, so it never comes close to timing out during normal operation.  After a restart, however the ‘timer’ event appears to be triggering before the ‘changed’ event, sending the script into the ‘faulted’ state instead of executing the recovery code. I would have expected the timer to freeze during the sim down time so the ‘changed’ event would trigger before the timer would time out.

 

Does anyone have any insight into what happens to a running timer during the down time when a sim is restarting, if that down time is longer than the timer setting?  Will the ‘timer’ event be triggered immediately upon restart or will the timer simply pick up timing where it left off?

[AnnMarie Otoole]

Attempts by myself in the past to use the CHANGED_REGION_START have all failed.
It is very difficult to troubleshoot and hopefully will get harder :).

If you have critical timing functions that have to survive Time Dilation and region restarts you should use llGetUnixTime and make your own timer loops.

AnnMarie Otoole.

On 3/21/2012 2:47 PM, Fred Allandale wrote:

I am trying to make a script auto-recover from a sim restart.  I have a ‘changed’ event that looks for CHANGED_REGION_START and runs some recovery code, but it does not appear to be triggering after a restart.  I also have a 30 second timer running.  If the ‘timer’ event ever triggers, the script goes to a different state (called ‘faulted’) that does not have a ‘changed’ event. The timer is used to trap failed responses from other scripts and/or dataserver events and is normally restarted every few seconds, so it never comes close to timing out during normal operation.  After a restart, however the ‘timer’ event appears to be triggering before the ‘changed’ event, sending the script into the ‘faulted’ state instead of executing the recovery code. I would have expected the timer to freeze during the sim down time so the ‘changed’ event would trigger before the timer would time out.

 

Does anyone have any insight into what happens to a running timer during the down time when a sim is restarting, if that down time is longer than the timer setting?  Will the ‘timer’ event be triggered immediately upon restart or will the timer simply pick up timing where it left off?

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Maestro Linden]

I don't believe that timer events always queue up if the sim downtime was longer than the timer period. You could test that by calling llGetAndResetTime() in the timer event, and see if the reported time is much less than the timer period, following a sim restart.

You could always check llGetEnv( "frame_number") in the timer() event, and see if it decreased from the last sample - this should always indicate a sim restart. The frame_number would only reach 2^31 after 552 days of sim uptime, so I don't think you have to worry about overflow.

maestro

[Nox Ferocia]

> Date: Wed, 21 Mar 2012 12:47:20 -0600
> From: Fred Allandale <Fred_Al...@msn.com>
> Subject: [slscripters] Status of timer during sim restart

>
> I am trying to make a script auto-recover from a sim restart.  I have a
> 'changed' event that looks for CHANGED_REGION_START and runs some recovery
> code, but it does not appear to be triggering after a restart.  I also have
> a 30 second timer running.  If the 'timer' event ever triggers, the script
> goes to a different state (called 'faulted') that does not have a 'changed'
> event. The timer is used to trap failed responses from other scripts and/or
> dataserver events and is normally restarted every few seconds, so it never
> comes close to timing out during normal operation.  After a restart, however
> the 'timer' event appears to be triggering before the 'changed' event,
> sending the script into the 'faulted' state instead of executing the
> recovery code. I would have expected the timer to freeze during the sim down
> time so the 'changed' event would trigger before the timer would time out.
>
> Does anyone have any insight into what happens to a running timer during the
> down time when a sim is restarting, if that down time is longer than the
> timer setting?  Will the 'timer' event be triggered immediately upon restart
> or will the timer simply pick up timing where it left off?

no insights into the triggering order (sounds like a bug personally),
however, retry logic may work better than immediate faulting for
dataserver type events... immediate faulting whould be safe for user
responses... you may be able to work around the buggy triggering order
by alternatively setting up a second timer by abusing llSensorRepeat
with the objects own key, minimal range, and agent for type, catching
it in the no_sensor event... this should allow the already queued
changed event to trigger beforehand and stop the sensor event or flag
it.