Stupid question about script limits

In preparation for these (quite apart from any other reason it might be desirable or undesirable so to do) should I be thinking about putting something into stuff so you can (if there's several other scripts involved) set all other scripts in the object to not running when it's not in use -- or won't that make any difference?

Well, it's not really a stupid question, but I've got a stupid answer! There are probably scenarios where this would be preferable and there are probably just as many where it wouldn't be. In short, it's really up to you and, more importantly, how your customers actually use the individual product. I'm actually going around and watching, looking to see how customers are using my products, because they often find ways of using our stuff that we never thought of lol, and how we optimize the scripting may ultimately affect how they use it. Research time!

Thanks. I know that I'd have to watch (or my customers would) for stuff like sim restarts, but I was thinking, in this context, specifically of furniture -- whether it animates several avatars or itself or both -- on the argument that if you're using the sex bed upstairs you're not going to be playing with the kit in the dungeon, and vice versa.

I don't think that script limits are going to be based so much on the number of scripts, but rather the amount of resources being consumed. A piece of furniture waiting for someone to sit on it isn't really doing anything until someone is sitting, and at that it only does what it does for an instant. It does however consume memory though. That's an interesting point. However, I don't think that LL is going to expect you to play musical scripts with one script telling other scripts to stop running. If a particular object does have alot of scripts, then shutting down scripts not currently used will be helpful.

However, I think the push is going to be to expand the LSL link functions so that much more can be done within one script rather than having all those extra scripts in the first place. So, I would recommend at this time to wait and see unless you just want to cover yourself for the future, or, just go all out for script efficiency. In the end I guess it's just up to what you want to do. Either way, adding the code to shutdown unused scripts would be fairly simple to add on in the future should that become the case. Also, one object cannot shut down scripts in another object, but it could relay a message to a control script to do so from within that object. But that seems sort of a moot point, as an object not in use could simply put itself into a sleep mode where the local scripts within it shutdown when not in use/after a certain amount of time has passed.

That's why I was thinking, specifically, of sex beds and the like; the new link functions won't alter the fact I need one script for each avatar I might want to animate.

And, while I agree that the new link functions are going to be very valuable indeed, that doesn't alter the fact I've got a load of toys already and, unless the creators are going to be very nice indeed and update them all (and, if they updating them, until they get round to it, of course) I still need to worry about my rather scripty tentacle monsters and so forth. Do I plan on having to take them into my inventory unless people are playing with them, or do I put on/off switches into the mod ones?

I guess what's confusing me is this. As I understand it, when I rez something with scripts in it, the scripts grab memory -- 16 kilobytes if they're compiled in LSO and 64 kilobytes if they're compiled in Mono -- whether they need at that moment to use it or not. It's like opening Excel spreadsheets as opposed to to Access databases.

I can release that memory by taking the objects back into my inventory, obviously, but I am not clear about whether I can release it by setting the scripts to not running and leaving the objects rezzed.

you can reduce the number of running permission scripts, by only keeping one open (for the first sitter) and only turning on others once you have the first one. but to make this work across multiple objects, they'd have to share permission scripts, or share some type of wake up detection.

setting them to not running *SHOULD* release them from the sim, although no one can be certain because we don't know how LL plans to count them right now. it does take them out of the VM, so they aren't counted by thing like top scripts so it is promising.

^gah^ can't find where Babbage, or possibly Kelly, wrote it ... but scripts set to 'not running' do not require memory and will not be counted. Whether you'll save enough to make it worth the 'control' script in an object is debatable though. Just compare how many scripts you're likely to be able to turn off at any one time with the total number of 'control' scripts you'll need to scatter around all your objects.

Johan - the official Linden word 'so far' is that there will be memory-based limits per-avatar (for attachments) and per-parcel (for rezzed items). While LSO-compiled scripts are only 16k compared to Mono's 64k (always!) LL are 'considering' penalising LSO scripts by making them appear to be higher-cost. This is because they want to discourage use of LSO so they can discontinue support for it.

one control script can affect multiple sub scripts, and can be part of a larger interface script, I don't see that being such an issue.


which is a crap solution, since the limits are going to hit avatar attached scripts the worst, yet the mono insertion/removal problems mean LSO produces less problems for the sim on rez/teleport/region crossing. this is one thing that if they don't fix before instituting will piss lots of people off to no end. they'd be shooting themselves in the foot (not that it would be a first... how many toes ARE left)

If it is the case that scripts set to not running don't count -- as i hope it is, since that should simplify life a bit -- I really hope they fix http://jira.secondlife.com/browse/SVC-1853 too.

I guess in an object that necessarily has multiple scripts (one that animates multiple avatars, for example) I can have the controller script turn stuff off again in the event of CHANGED_REGION_START, but I can see things getting a bit messy.

"one control script can affect multiple sub scripts, and can be part of a larger interface script, I don't see that being such an issue."

Only saying it's a matter of 'count'. If you add one to turn off two, then ok. If you add 7 to turn off 6 then is it worth the communications effort. If you add 900 to turn off 899 then, actually, ia there any point at all.

"which is a crap solution"

Yep. Reading between the lines - which may mean I'm completely wrong, of course - those that know and appreciate the problems, including Babbage & Kelly, hate this idea but if management say it has to be then it will be. *sigh* Nothing new there then.

ah but we've been promised eventually that mono scripts will count as their largest 4k block of usage. and I can scarcely imagine a scenario in which you'd use MORE scripts to run shutdowndows/wakeups than you already had.

heck, if you are the designer, or have access to the scripts, I can't see a scnerio for using more than one and even that should be possible to integrate


I find it hard to believe that even middle management is dumb enough not to understand:
"we have to fix this first, or our super plan to grease the wheels is going to grind to a screeching halt instead""
(hard, but not impossible)

There's a complexity here.

Currently, stopped scripts retain their state (including memory) UNLESS the sim is restarted or it's taken into inventory and rezzed again.

There's a Jira to fix that inconsistency, but who knows whether they will.

Until then, stopping a script by itself does not release memory unless the sim restarts or the object is taken into inventory and re-rezzed. That means that you can sell a scripted object with many features turned off, and turn the scripts on only if the feature is enabled, so the customers get a "pay as you go" option.

However, when they turn the feature off, they'll have to take and re-rez to get the benefit.

And that's only until they decide to fix the bug.

One option for fixing the bug would be to save the state of stopped scripts to asset servers. If they do it right, that means that the memory resources would be freed and you wouldn't be charged. (Also, they'd put a penalty like a delay on restarting a stopped script, to keep you from abusing it. Delays are usually a bad way, but in this case I think it works best.)

Another option would be for them to simply discard script state when it's stopped, in all cases. In that case, you'd get the full benefit without the caveats.

There's another option being discussed but not yet acknowledged by LL, which is an llEnd() function that a script executes to remove its resources, but leaving the script in inventory to be restarted (using some unnamed function or perhaps llResetScript()). That has the advanatage over llStopScript() that its intent is clear and it's not using a side effect of some other operation (like llStopScript()).

MLPV2 shuts off the scripts that run the animations on the avatars. They don't use much memory; this is to reduce the idle script CPU time, which makes a significant difference in a furniture shop but wouldn't have much impact on the typical customer.

Discouraging LSO so they can stop supporting it is ludicrous. Before they can even consider this, they'd need a way to automatically update LSO to Mono.

Otherwise, imagine the cry when peoples favorite old content stops working!

And converting LSO to Mono requires access to the source, which I bet is a missing asset for many working objects.

slight correction, they retain their memory if taken to inventory, at which point they are saved to the asset server.

if they get purposely reset, cross a sim boundary, or are still out when a sim crashes or is reset, after being stopped, and the above hasn't occurred, THEN they lose it.

however, in both cases they are removed from the active VM and don't affect script times (and it's also why sim crossings reset them, since the vm doesn't pass the reference for the stopped script to the next sim)

My experience shows otherwise.

If I stop a script, take the object into memory, then rez the object, then set the script state back to running, the script resets. This caused a hassle for MLPV2 and I'm quite sure that's what happened.

I'm getting really confused here. I hadn't considered it before, but obviously, yes, if I have an object rezzed that contains a script that's holding stuff in its memory, take it back into my inventory and then rez it later, the stuff's still there unless I reset the script.

So whatever it's remembering is stored somewhere, and continues to be stored whether it's in my inventory or rezzed in world.

So how does taking the object back into my inventory help matters if I get over the proposed memory limits for my land, or is it not the data's stored somewhere but that it's accessible when the object's rezzed but not when it's in my inventory?

The sim takes a snapshot of the script state and saves it with the object, then it's the asset cluster's problem and not the sim's any more.

hmm I take it back, I just tested again... that wasn't always the case though, because I remember testing that exact scenario... at least in mono... damnit, shit keeps changing every time I turn away =(

With STOPPED scripts? I think you're thinking about running scripts.

When an object with running scripts gets taken into inventory, its full state is saved in the asset servers, including all variable contents. Nothing new there.

But if you've stopped scripts (by unchecking the "running" box or by using llSetScriptState(name, FALSE)), the stopped scripts lose their state.

I'm speaking of Mono regarding state bbeing lost on sim restart or taking into inventory. I haven't tested LSO.

It's the same with LSO. That's SVC-26, FWIW, but it's way older than PJIRA.

Sorry.. I didn't make myself clear. I was talking about running scripts too.

It had just occurred to me that if I take something containing a running script that holds a long list in its memory, that list is still there when I rez it again, so the long list must be stored somewhere while it's in my inventory, is all.

Thanks, Viktoria. Now I understand.

As it turns out, you were talking ONLY about running scripts. Unfortunately. :-/

not exactly... as long as the sim isn't reset, and the object stays in the same sim, that memory is recoverable if the script is set back to running...

Yeah, which is what I said in the first place. The bottom line is you can't rely on stopped scripts retaining their memory. If you do, you have a bug, because sims get reset.