Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

After sim crash/reboot - what happens to timer events?

Feline Slade
Hatstand 2.0™
Join date: 19 May 2007
Posts: 201
04-28-2008 05:04
With all of the sim crashes and reboots recently, I've started to be concerned about my current project. It is currently set up with a timer several days long, but the object is also set to reset the timer in state_entry.

At the time of a sim restart, are state_entry or on_rez executed? And do timer events start over? I could probably wait for another round of rolling restarts to get the answer to this, but I'd rather know so I can think about how to re-engineer this if necessary.

As a sidenote, if multi-day length timers are a bad idea (due to restarts/sim crashes), what is considered best practice when you need to have an event occur 7 days in the future?
_____________________
Forum Cartel inworld events calendar: http://www.google.com/calendar/embed?src=forumcartel%40gmail.com
Send me a PM here or IM inworld to get write access to add events or to have your events added.
Squirrel Wood
Nuteater. Beware!
Join date: 14 Jun 2006
Posts: 471
04-28-2008 05:26
Scripty usually continue from the point they were interrupted at during a sim reboot. As if nothing had happened at all.

Though there are very rare cases where a script might be reset. Chances are that you will never see that happen though.
Salvador Nakamura
http://www.sl-index.com
Join date: 16 Jan 2007
Posts: 557
04-28-2008 06:59
if you really need to be sure the timer is exact, i would suggest using: llGetUnixTime
Shadow Subagja
Registered User
Join date: 29 Apr 2007
Posts: 354
04-28-2008 15:00
The big question here is whether its every 7 days, a certain day of the week, or specifically on a given date that happens to be seven days from now. The approach would be quite different depending.
Feline Slade
Hatstand 2.0™
Join date: 19 May 2007
Posts: 201
04-28-2008 16:55
Thanks, all, for the responses.

I'm trying to track a series of statuses, each of which will cause the script to have different functions available. For example:
Default status is A.
After 7 days elapses, status changes to B.
After 3 days elapses, status changes to C.

I have prototyped this with timer events running much shorter intervals than 7 days, and it works fine. I'm only concerned with the durability of the solution given the likelihood that the region where the script is running will probably be restarted at least once, if not more, during that 10 days.

The prototype script looks something like this:
From: someone

string strStatus = "Status1";

statuscheck()
{
if (strStatus == "Status1";)
{
strStatus = "Status2";
llOwnerSay("Do status 2 stuff here.";);
llSetTimerEvent(10); // Change to to next status interval.
return;
}
if (strStatus == "Status2";)
{
strStatus = "Status3";
llOwnerSay("Do Status3 stuff here.";);
llSetTimerEvent(8); // Change to next status interval. If this is the final status, don't put this line here.
return;
}
}

default
{
state_entry()
{
llSetTimerEvent(10); // set initial timer interval for first status change.
}

timer()
{
statuscheck();
}
}


It works. But will I be sorry I didn't do this a harder way?
_____________________
Forum Cartel inworld events calendar: http://www.google.com/calendar/embed?src=forumcartel%40gmail.com
Send me a PM here or IM inworld to get write access to add events or to have your events added.
Shadow Subagja
Registered User
Join date: 29 Apr 2007
Posts: 354
04-28-2008 18:23
I would consider recording a timestamp when the script starts, then just checking on a regular timer of say half an hour or so if the new timestamp is equal to the original one plus the interval you want. I'd trust the state of a script variable farther than I would the continuation of timer event through a restart.. though depending how timers are implemented it may boil down to the same thing regardless.

I tend to consider script events 'plausible' rather than 'confirmed' most of the time.