When do scripts reset?

[Xxaxx Constantine]

Based on reading about Watchdog Scripts I am surmising that scripts do not automatically reset after a crash.

If I do not use a watchdog script, when can I expect a script to reset?

Thanks

 

[Dora Gustafson]

If the script does not call llResetScript() in some event,
say: on_rez(integer param) { llResetScript(); } then you can expect it will never reset

:smileysurprised::smileyvery-happy:

add: when a script has crashed it can do nothing on its own:smileysurprised:
It must be reset (and set running) manually or by a watchdog script as suggested in your reference

[Innula Zenovka]

In the normal course of events, you should expect scripts to reset when you tell them to,    I say "in the normal course of events," because there is, or at least used to be, a nasty bug that caused scripts that had been set to not running (by themselves or by another script) to be restarted, in state entry of state default, if a region restarted (and, I think, too, if taken into another region).  That may have been fixed, but would certainly be worth checking before relying on how scripts are likely to behave under those circumstances.

I can't get in to check, but I am a bit dubious about the example to which you link.   Have you verified it actually works?   As far as I know, the wiki is correct when it says in the article on llResetOtherScript that 

• If the script is not running, this call has no effect, even after the script is set running again.

That is, if a script has crashed the only way to restart is is manually, to the best of my knowledge, anyway.

[Nova Convair]

llGetScriptState - works and detects if the script is running or not

llSetScriptState - does not work for crashed scripts

llResetOtherScript - does not work for not running scripts ( I never tried to use it on a crashed script though since i rather debug the crashed script )

So there are 2 options left in case llResetOtherScript doesn't work

1 - llRemoteLoadScriptPin - requires a copy of the scripts and some preparations

2- Debug the script and make sure it does not crash. It's a bug if that happens !

 

[Xxaxx Constantine]

Well, all of your comments have been a very definite wake up call for me. Being new to the LSL Scripting world I had fallen into the trap of taking content on the wiki as more or less correct.

The notion that this watchdog script would be so utter wrong had not occured to me. So thanks for the heads up.

I agree that a crashing script obviously needs better maintenance. I found my way to the watchdog thing from the wiki page on llGetAgentList. The part about possible STACK_HEAP_COLLISION_ERRORs got me to thinking that monitoring a script with a watchdog could tell me when or if the script was encountering such mem problems.

By the way, I got to the llGetAgentList looking for a less laggy method of maintaining stats on visitors. The scanner based scripts all seem to have been created prior to this new approach and I wanted to see if it was more efficient.

So I guess my real question should be what are the best practices when using a function such as llGetAgentList -- which has known memory issues.

 

[Rolig Loon]

It's always possible to run into memory poblems when you have a script like a greeter that continually adds new data to existing lists or strings.  You can usually avoid the problem by including a simple memory test to tell you when you're getting close to a limit and start deleting the oldest entries.  The challenge with llGetAgentList is that you might overwhelm the script's memory in one single function call if you were on a really busy sim.  One quick way to minimize that chance would be to call llGetRegionAgentCount first.  If the result is large enough that it might swamp your script's memory, don't call llGetAgentList. 

[Profaitchikenz Haiku]

There is also the possibility to have multiple scripts inside a single prim, and use llMessageLinked(LINK_ALL_OTHERS...)  or (link-number... to send the other scripts the details to be stored, so that the main script simply obtainss the immediate data, then sends it to the appropriate script which adds the data to the list. The main script could also monitor either the time and message a  child script each time midnight comes and goes to tell it that it is the new logger, or each script doing the storing could send an alarm message back to the main script when it detects the free memory is less than a certain amount, and the main script then selects the next child script as the recorder. 

 

I use this method in a singlke prim to record details for each day of the week, with Monday_1, Mondeay_2, Monday_3, Monday_4 allowing me to keep up to a month's records in the prim.

 

I do not know if there is an upper limit to the number of scripts a prim can hold, I suspect there is one but I haven't found it yet. ( I appreciate this isn't answering the OP's original question about telling if a script is stuck or how to reset it, but in this instance I suspect the best approach is to plan to avoid the sort of memory-usage issue which would crash the script in the first place.)