Do region restarts reset scripts?

Self-explanatory question. The script wasn't sleeping at all, and I'm not at all sure that there was a region restart, but something unexpectedly caused all the variables in a rezzed object of mine to reset themselves while I was offline.

The most likely possibility, I guess, is my friend was messing about with the build, but I'm just trying to exclude other possibilities before I yell at her.

No, not usually (unless the script has an on_rez event that resets the script, which is common). However, the Lindens MAY have done something a little more drastic on this last rolling restart. There was a bug that caused scripts in deleted objects to still be scheduled, and the workaround many have been using for this was to stop all scripts in the sim, reset them, and restart the sim. If LL decided to clean out all or some sims that were experiencing this problem, all the scripts in rezzed objects would have been reset.
.

Thanks.. that may well explain it. I hadn't realised that things get re-rezzed when a region restarts, but, of course, it makes perfect sense.

To be on the safe side, I had better put in something to check for change & REGION_START, I think.

it's also possible that a land manager on an estate can stop scripts via estate tools... but I did hear some complaints in RA that scripts were being reset in the last rolling restart (not a usual occurrence)... sometime a bad sim crash will do it to, but not often.

I've also learned that if you stop a script (e.g., uncheck "running" or llSetScriptState(name, FALSE)) and the sim restarts, the script gets reset when set back to running. This also happens for taking into inventory and re-rezzing.

It never occurred to me that every script gets an "on_rez()" event on a sim restart. Frankly, I don't think it *should*, but if that's how it is, well, that's how it is.

They don't. If they did, there'd be no need for the changed/CHANGED_REGION_START flag that was introduced for HTTP-In. Sim restarts do NOT cause new object rezzes. If they did, people relying on persistent prim URLs for in-world servers would've had MAJOR problems a LONG time ago.

See:

http://wiki.secondlife.com/wiki/LlRequestURL
http://wiki.secondlife.com/wiki/CHANGED_REGION_START

But you were right about it being reset if the script is not running. Actually it is even more pervasive then that though. If you have a script in an attachment that is set to not running, it will be also be reset on a region crossing........................................

I tested this earlier today by setting up two prims to change colour on, respectively, their on_rez and state_entry events, and neither changed when I restarted the sim.

Looks like a case of operator error somewhere. I must investigate further.

Now turn the script off and try that. It will not preserve the state it is in.

region crossings, TPs (to other regions, which are just a differnt sort of region crossing) will reset scriptst that aren't running (dunno about restarts, but it'd make sense).

IIRC this is only ture for MONO... because the mono scheduler doesn't pass references for non-running scripts, and the script state doesn't get saved back to it's contents (under MONO) until it goes to inventory.... the fix would be to save it back immediately upon setting not running...

Yes, I'm aware of that problem, though it's not one that applies in the case that's puzzling me, since the scripts are never set as not running. I meant, rather, that the sim restarting can't be responsible for my problem.

I'm mystified. It's a holovendor that generates a random channel, passes it to the (not temp-on-rez) item it's rezzing, and then uses the channel to tell the item to llDie() before it generates a new channel and rezzes a new item. In tests, everything works as it should, and, by and large, the vendors behave as expected in the the shop.

But twice, once on my building platform and once in one of the shops, we've left the vendor with an item rezzed and then come back later only to find the item doesn't delete itself when we rez a new item. Once the recalcitrant item is deleted manually, everything works fine again.

It's a very intermittent problem, and all I can think of is that something's happening to make one or both of the scripts forget what channel they're using. It's possible, I guess, that someone's been playing with the things and resetting the scripts manually, but I very much doubt it.

We're only using it in our shops at the moment, so, as a work-round, I'm hard-coding a different channel for rezzers containing different product lines and for the items they contain.

But I don't like unsolved mysteries and, if I do eventually start selling the vendor, I would like to use random channels if only I can be sure I've solved the problem.

not knowing the code being used, is it forgetting it's channel, or is the channel being updated (without the msg to die being sent)?

also... why does it need a to keep changing channels like that to begin with? any random channel would work for the whole thing, since you call die on the old before rezzing the new, I can't imagine there being any problem of one objects calls affecting the next.

Stopped LSO scripts also get reset over crossings and restarts. I've been seeing lots of odd mentions being made lately, all over the place, about abilities and efficiencies that LSO didn't really have. Where is this meme coming from?

Thanks for clearing that up. I suspect I'd have had some service calls if it were the case. I know for sure that the UUIDs of rezzed objects don't change on region restart (thank goodness!)

Wow, if that's true -- if LSL does preserve state for stopped scripts -- that'll be a big help for MLPV2. Most recent versions stop scripts that aren't needed, and this causes problems for some of them on region restart or rez. (It recovers, but only after you try to use it, and then you have to wait; meanwhile it appears broken. I also think you have to STOP it as part of the recovery. Fortunately a full reset isn't needed.) The scripts in question can probably be LSL, as they generally wouldn't need lots of memory. At least, some of them can.

Perhaps object chat isn't guaranteed. It's not a "reliable service" in communications jargon -- for that to be the case, we'd need an error indication and there is none. A system *cannot* guarantee delivery. The best it can do is to guarantee that if the message is NOT delivered, an error is signalled. Even in this case, it's possible for the message to be delivered AND you get an error indication.

I suggest you choose a protocol that does not rely on every chat message getting to its destination. For example, if you choose two random channels and alternate between them, if an object misses a message, it'll at least get cleaned up on the next cycle. You may be able to think of better methods more suitable to your particular case.

Yeah, I realise now that I've made an unnecessary problem for myself. I need several channels because of the possibility of having two vendors belonging to the same person, but vending different product lines, close to each other. But I see that I did it the wrong way, now.

I'm more puzzled about the general point of why it sometimes -- though infrequently -- fails. I just don't like not understanding why things don't work as I expect them to.

There's nothing in the scripts themselves to make it forget -- the rezzer tells the object to die, waits while it does a couple of other things and then makes a new channel and rezzes a new object, and the rezzed item just opens the listener and waits to be told to delete itself.

I am wondering, though, if there's something in the other scripts in the rezzed object that's making things go wrong under certain circumstances. They aren't mine, but I will see if I can replicate the problem and deduce anything from that.

news to me, but then I didn't test that, only stated what I've heard. there are some differences in behavior between MONO and LSO, especially in the handling of certain functions, memory size, etc... I never thought to test it because they don't run on the same scheduler, so if that's wrong thanks for correcting it.

if you steal bits from the objects key to make your channel that should solve most of your collision problems with nearby vendors... it seams strange that a product would reset other scripts in the rezzed object, but if it's only happening with certain products that would be the clue, and a good thought to pursue... I'm out of ideas past that

Yes, A friend had started this JIRA long before Mono came to the grid. Still an issue :\

http://jira.secondlife.com/browse/SVC-1853

I think they stopped passing the script image for non-running scripts (if they ever did) for both Mono and LSO. I don't think this is related to the overhead of serializing mono scripts at all.

I'm just wondering why it isn't immediatly saved back to the script... seems like it would be, unless there's no object relative container for it when it's inworld (obviously there is SOME kind of container, or restarting in the same sim would reset it too... and there must be an inventory container as well or all scripts would reset on rez)

Use the first 8 characters of the object's key name, converted to integer. If the result is in the range [0,100], add 100. Bingo, nice key-specific channel, with the chance of collision between any two objects less than 1%, if there are 2000 objects in chat distance using the same trick. If there are fewer such objects, the probabilty goes down dramatically.

On the other hand, by using a random number (I use -1 - (integer)(llFrand(DEBUG_CHANNEL))), you at least have the workaround of resetting the object in the case of a collision. Of course, careful design of the chat messages makes collisions cause no problem other than extra script processing. Well, that's true for inter-object messages; less so for llDialog() messages since the message is the button name (grrrr).

But there's no need to pick a new number each time. I assumed you were doing that to speed up operations; so that you could talk to new objects while old ones weren't dead yet.

BTW, does anyone know whether chat reordering, which we often see client-side, can happen between objects? I haven't seen any clear evidence either way, but I suspect that MLPV2 would have (more) bugs if it could.

For a particular script, I believe the messages always arrive in order. But of course one script could receive messages A, B, and C before another script receives A.

They might conceivably become reordered if they're chatting across a region boundary.