Running scripts preserve their state over a region restart (more accurately I guess their stack, heap, permissions etc are saved in the latest region snapshot and they resume with their state as at that snapshot) but this doesn't seem to be the case for scripts which had been running but were not at the time of the snapshot. Scripts not-running at the time of the snapshot are in a virgin state when set to running again after a region restart when the region has been reloaded from the snapshot.

Putting it a different way, I think region backups should include and restore state for not-running (but have been run at some point previously) scripts as well as running scripts

Babbage agrees that this is onerous, and he's triaged it onto the Blighty tasks list as something to tackle after Mono ships (or the next lull we get in working on Mono).

I'll be sure to reference the prior documentation in SVC-26 on the internal JIRA.

"Periapse Linden - 18/Apr/08 11:59 AM
Are you sure this is new behavior? I don't see how scripts could save state when the region restarts, but I will try to get a developer to comment. "

If this is the case then maybe allowing a new toggable flag. Such as llStoreScript(TRUE). Which would effectively allow scripts to keep their stored data on these resets. And for sim owners giving them a advanced feature to force reset of all scripts, even ones with the new flag.

Howver, given the decision not to fix the bug, llSetScriptState should be changed to reset a script when the script is being stopped so that behaviour is consistent whether or not a region restarts whilst the script is stopped

What you're saying is that we can't limit server script resource usage by shutting off scripts that don't need to be running but need to preserve state. Having too many scripts running on a server absolutely kills performance, OTOH because of the limited memory available to a single script, it's often very necessary to have multiple scripts to do complex behaviors, particularly ones that need to keep anything beyond a tiny amount of data. With some design care, breaking this up into multiple scripts and only activating the ones needed at any moment get around both problems, but not if you can't rely on the state being preserved.

The suggestion to keep data outside SL is not very helpful towards limiting server loading and is too slow for many applications in any case.

It's difficult for me to see why this is such an insurmountable problem in any case. Surely, the main difference between an active and inactive script is just if it's in the scheduler queue. Active scripts keep their states, why not inactive?

I suggest you rethink this.

Ralph - If you can attend Babbage's and Scouse's office hour on Wednesday mornings (8am, PDT) you can directly chat with the Mono devs. Alternatively we can carry on a longer latency discussion here. I will add watchers to this issue.

1) There's an inconsistency in how llSetScriptState behaves. Most of the time you can stop and start a script with no data/state/permissions loss. However, if the region the non-running script is in has restarted over that period the script is in virgin condition when it comes to be restarted. Therefore, you cannot rely on llSetScriptState at all unless you back it up with detection of region restarts. If this ticket stays in 'won't be resolved' state, then llSetScriptState should be changed to always reset a script on stopping it so that behaviour is always consistent. Unexpected loss of permissions (especially DEBIT) is particularly awkward because they can't be re-established until the av that granted them can next get to the object.

2) Storing data outworld is not an option. Why?
a) The point of stopping and starting scripts is to help region performance; I don't want to go through elaborate storage and retrieval routines before and after
b) In my specific example, I wake up the stopped scripts when an avatar collides with the insides of the object; I need a startup that's consistently, reliably faster than avatar movement
c) None of the three alternatives satisify point b, specifically
i) email: email is not guaranteed to be delivered instantly, or at all
ii) xml: the issues with the loading and reliability of the xml gateway don't need repeating here
iii) html: could be made to work despite being one-way initiated, but won't result in the instant start I need, and means additional region load as the script recovers all its state and delay before the script is ready to work

3) Script operation should be intuitive, predictable and straightforward. If you stop and start a script either it should always come back how you stopped it, or always come back in a virgin state. Since this cannot be relied on at present, there currently has to be a workround in the deployed script. Currently, I detect region restarts and then reboot the whole object so that all the data and shared state is correctly distributed again (eg I have one script which never stops which owns the main listener, and it sends listen messages around by link_message, but... the other scripts need to know the channel number so that they can initiate dialogs without having to ask the always-running script to do it for them so saving one link message - ok, I could ship around the channel number with the link message but at the time I was designing the communications I thought I could rely on only having to send it around once at startup). Sure, I could use the state-based workround proposed above instead, however then I've got to have additional code to handle the effects of the state change (and, since timers aren't affected by a state change the timer routine would have to be manually stopped and restarted... which in turn means extra code to store the current timer frequency in a global variable). -> -> -> I may not be fully right in some of the technical comments made in these last 12 lines of text, but I think it demonstrates clearly why the current situation isn't fulfulling the criteria of intuitive, predicatable and straightforward - point made!

4) Not addressing this goes against considerate use of region resources. Many people (for whatever reason) just leave scripts running at full tilt whether there's anything for the script to do or not. Every running script with timers, listens or scanners will have a certain impact on a region's script bandwidth. This is a finite resource even with the improvements expected from Mono. It should be easy to pause a script until it's needed again and then do a just-in-time restart with previous state preserved. If it's not easy to do, the majority of scripters will discover the gotchas and decide it's too much hassle to think about pausing their scripts and just leave them running all the time without even bothering to do the extra code to go in and out of another state, cancel timers, etc.

5) There's advice out there that scripts should consider self-moderation, ie if they see time dilation dropping they should reduce their activities or even stop. In the scenario where a script can be stopped, forcing the script to do a burst of activity (any maybe outworld communciation) when it's preparing to stop is adding to the region load, not helping reduce it. If we assume that it's an extreme time dilation dip, it's even possible that the routines to save data will fail for some reason (timeouts exceeded for outworld response, scripts getting out of sync with one another because of message delivery delays/loss etc..)

--Chorazin

But to address another point: A data storage script that's waiting around for a linked message query is not wasting any resources, if all it's doing is waiting for a linked message. Even if it's just doing a listen to a known central server object, it will only hear that object, and the efficiency problem is handed to LL's listen filter code.

Say we have a script that turns other scripts on and off depending on when it wants them. That script is wasting resources, because it has to process the requests and do the switching on and off, all to accomplish something that could be accomplished by simply sending a linked message and waiting for a response. Managing the run-state of scripts is a waste when such management is really unnecessary, especially when multiplied across many in-world instances.

So to solve the script count problem, you add to the script load problem by requiring extra processing per data request. Assuming, of course, that LSL doesn't move as quickly as the server under which it runs.

Edit update: I just made a script that stops itself on touch. It seems to require a full prim update from the server to stop itself. Thus, if you're stopping and starting scripts, you are lag.

That's the stick. The carrot would be fixing this issue (and others like it) that make it currently impossible for content creators to write region-friendly content which scales itself up and down depending how much it needs to do at the time. I already have code in some of my products to implement a standby mode with waking up on a touch or a collision, but I also have to have code stil running which is checking for a region restart during standby so that instead of coming out of standby I do a cold start on all the scripts in the object and then reapply the state which is global to the object having lost the state which is specific to scripts that were stopped - all that code should not be necessary; it's only there because I cannot rely on scripts to retain the state when stopped. There are also scripts I would like to stop, but cannot at all, because they hold permissions (particularly _DEBIT) which are also lost along with all the other state associated with the stopped script.

To Cinco's comment, it should go without saying that starting and stopping a script should be a very cheap operation to perform, otherwise the whole advice about monitoring TD/FPS and scaling script operation to suit is flawed.

But they still will NOT fix issues flagged as MAJOR BUGS?!

Soon I'd imagine, they will charge us L$10 to comment here.

Is there a problem or not?

I am writing a collection of scripts that work together,some of them are for memory of lists and only need to run under certain instances. If they are deactivated via llSetScriptState and during a restart they lose all their lists the whole project is dead. The whole point of this function as I see it is to reduce the need for quiet scripts to be running for hours or even days before they are called to operate. This is why I am writing in the llSetScriptState commands. Now I read a load of conflicting blah about it not working in this that or the other case. Would a knowlegeable Linden please put this to rest with "It is fixed" , "It isn't fixed" , "There is nothing to fix" or some other consise and accurate statement. I need to know ASAP if I should leave all my listens running to avoid list corruption or loss or if I can safely activate those scripts in question as and only when they are needed. Considering the issues surrounding the running of and the quantity of scripts in SL I think this is a MASSIVELY IMPORTANT ISSUE.

I am watching this space. Thanx Lindens everywhere. I love SL.

Plain summary: start a script, suspend it with llSetScriptState. Resume it with llSetScriptState. The behaviour when you resume is indeterminate. If the region has not rebooted whilst the script was suspended the script will resume exactly where and how it was with all running data, permissions and context intact, as you would expect. If the region has rebooted the script will restart from virgin state with all variables, context, permissions etc lost and will begin running in first-run state, ie state default and the entry handler will get executed.

Given the age of this ticket, I've recently abandoned my own efforts to voluntarily reduce script load from scripts that don't need to be running and now keep all scripts running all the time because I haven't been able to make my region restart detection 100% reliable and the script processing to save and reload state in a controlled fashion around llSetScriptState calls and/or tell my object users what's going on and why their settings/permissions just vanished is way in excess of simply continuing to run the script.

Periapse Linden added a comment - 26/Sep/08 02:50 PM
Mono is now live. Http In is underway, and the load limiting it requires makes this issue salient again.

From this very page. Note the date. How about an assignee at the very least for starters?

I am new to scripting and have run into a few bugs already. I assume as I get better and use more functions I will encounter more bugs. I fully understand the complex nature of SL but surely that is the point here. If these bugs ar not delt with in good time as the world develops there will develop more bugs and they will eventually be out of control.

This bug is old and apparently still needs fixing. Why wait till it is at the bottom of a bigger pile to fix it? Please LL can someone at least show they are interested in this issue.

What a great lag reducing tool this would be if it actually worked!

For every MLPV2 menu-furniture inworld, two scripts now must stay running that would otherwise be shut off due to this behavior. MLPV2 sets many of its scripts to not-running when it's stopped (when no pose is selected). However, two of the scripts that could be set not-running have to remain running due to this behavior.

LL should do whatever possible to encourage shutting off unneeded scripts. This would reduce CPU time (due to the time spent visiting dormant scripts), and could also reduce memory usage (if state of "off" scripts were saved to disk).