script reset order

If you go tools-reset on a prim that has a number of scripts in it, I think what I'm observing is that the scripts are being reset in reverse alpha order. Or at least, the popup window that comes up listing the scripts it is acting on, shows them in reverse alpha order.

(a) is this the order they are being reset in;

(b) is this the order they are being reset in *this week* in SL and it was different last week and will be different again next week?

Design your scripts so that it doesn't matter.

So Kidd, you're saying you don't no. ?

Well, it's certainly trivial to test for oneself with a little debug code, but on the other hand, I don't think it's knowable in any way that's determined from one server update to the next. And perhaps worse, I don't think it's all that sequential: If you have multiple prims selected and you reset all their scripts, it's by no means sure that it will do all the scripts in one prim before starting another, or complete the state_entry processing of one script before starting the next. So... if scripts were to actually depend on this sequence, it would be a very fragile thing.

>> Well, it's certainly trivial to test for oneself with a little debug code,

Yep, and that's what I'm seeing. First reverse alpha order for all the scripts in the rot prim itself, and then scripts in other linked prims (haven't looked at their order).

What I was wondering is just out of curiosity, those far longer in the tooth than me, had noticed the same, and just out of curiosity, whether it changed from time to time with various Viewer releases. I certainly wouldn't count on it.

Why I'm paying attention is that I have a translator script that *has* to start first.

So I'm putting sleeps in all the other scripts to make them wait a few seconds before they start up their sequences, so make sure the translation engine is ready for their requests. If anyone has a better idea, I'm all ears.

p.s. I'm also providing a reset button on a menu that will reset them all in proper order, but just taking this extra precaution anyway in case of manual resets.

p.p.s. yep translation engine has to be separate. I do all my user interface / interaction stuff in four different languages (people languages that is), and the number of terms required in 4 different languages was causing other scripts to hit memory limit in a New York minute.

Well, perhaps llSetScriptState() and llResetOtherScript() might help. And/or having every script other than the first await a link message before passing to their real operational state.

Actually, I'm saying I don't care, and neither should you.

But Qie is right, use linked messages to puase the others.

well Kidd, sadly I *have* to care. And there's nothing wrong with just coming out and saying you don't know.

No, seriously. You have to *not care*. If your code depends upon the order, that's a bug. It may be a latent bug, but it's a bug.

It's not simply a matter of not beinig willing to say I don't know, because whart I do know is that the answer is not knowable. It's quite likely non-deterministic, so no simple test will give a definitiive answer. And whether or not it's changed in the past proves nothing about whether or not it will change in the future.

You must write your scripts to work regardless of the order, as I and others have said.

What exactly is it about your translator script that makes it so important that it reset first?

It's not at all trivial, and the rest of your note explains why. You can't just report the start or stop of the state_entry handler, you have to use timestamps. You could have script A report that it started, then the default state_entry handler for script B runs to completion, then the rest of the state_entry handler in script A runs.

Even then, how many times do you have to run the test to be sure the answer is the same all the time? Do you have to run it with various loads on the server, to ensure that the load doesn't affect the order?

>>And whether or not it's changed in the past proves nothing about whether or not it will change in the future.

Exactly. Now we're closer to the same page. As I said in the first posting, "is this the order they are being reset in *this week* in SL and it was different last week and will be different again next week?"

>> What exactly is it about your translator script that makes it so important that it reset first?


kk first lets cover why the translation engine is its own script.

It contains all the messages sent to users, in English, French, German and Italian. The messages exist in a separate script because (1) all that extra text being repeated 3 additional times besides English takes up memory, (2) I'm sure you know that most other languages are way more long-winded than English (though granted I'm on my way to disproving that right here and now), which causes this translated text to take up *even* way more memory, and (3) it's *way* more convenient to keep all the human text that has to be translated all in one place, and to be able to call upon it there. It's how I do it in my RL coding, and I think pretty standard practice for many people in multilingual programming to separate the actual coding and design from the text. Don't tell me I"m the first in SL to blaze the trail of localization in programming? I *hate* it when that happens, grin.

kk why must it load first?

All the user messages include user error messages such as "can't find config note card", "oops you didn't fill this part in", "hmmm that doesn't look like a real vector", etc. Before the script that loads the config card starts, it has to know *how* to say "you dummy you". Should the variable for MsgDummy be set to "Dumbkopf", should it be set to "ma che stupido", etc.

The right language message for each msg variable has to be ready to go, right from the start.

I'm currently implementing the idea that Qie Niangao suggested, and that you seconded. It seems imminently sensible. I wasn't actually going to rely on any reverse alpha order loading of scripts -- that was just an observation I made, but I certainly wasn't going to count on SL always doing it that way, grin. I were just curious, I were.

>> It may be a latent bug, but it's a bug.

Are you American? Americans tend to think it's a bug when people speak anything but American. Grin. Witness just trying to work a French accent into a script.

Absolutely. Though I'd consider storing the text in notecards, a separate one for each language, so that you don't have to have all four languages in memory.
If you are, you should be proud of it, not hate it.


Actually, the message variable doesn't need to be ready until the message is triggered. In theory, your message function could just read the appropriate line out of the appropriate notecard whenever necessary, rather than loading them all up front. Unfortunately, that's slow. Regardless, your client script will ask the translator script for a translation, and the translator script at that point just needs to make sure it's fully initilizaed before responding. If, for example, the translator script did everything in the default state, then the state_entry handler is guaranteed to run to completion before any link_message handler.

[/quote]
As it happens, yes, but I was working with i18n before many SL users were born. I don't think it's a bug because I'm American, I think it's a bug because I have a background in software quality engineering.

>> I have a background in software quality engineering.

Kewl. Me too. Though sadly because I live in Canada, I rarely have the luxury of just being able to take 1 human user language into consideration.

>. the translator script at that point just needs to make sure it's fully initilizaed before responding.

aye, and there's the rub.

>> If, for example, the translator script did everything in the default state, then the state_entry handler is guaranteed to run to completion before any link_message handler

guaranteed??? By Linden Labs or else I get my money back? grin. In practice, that just wasn't always the case, and wasn't reliable, sadly. It's the way I had it the past week and the scripts nicely were sending out a lot of blank messages. Granted, that solves the language problem. What's not to understand about blank? grin.

Really? The state_entry handler is supposed to run before either link_message or listen handlers. And a handler is supposed to run to completion before another handler gets invoked. It's possible that some messages were getting dropped, due to the 64 message limit on linked messages. If you're sure it wasn't your code, then it ought to be reported as a bug in Jira.

While I would have to look at the code to be 100% sure, I am 99% sure that the way it works is that when a script is reset, the memory image is reloaded from a copy, and all the associated extrascript management data structures are cleared (ie, the event queue), and the state_entry event is put into the queue as the first entry automatically. As such, it should always be the first event executed.

To throw my L$8 in..

This is another one of "those things" you shouldn't design your software to depend on. Use some kind of synchronization mechanism to guarantee yourself that the modules are loaded in the right order. That's pretty much the way I have done it in cases where I needed to be sure something was initialized and ready for data before I used it.

state_entry() is guaranteed to run first, and guaranteed to run to completion before any other events like link messages, because LSL is by design non-reentrant. I have never seen (nor would I ever expect to see) anything short of catastrophic failure interrupt the state_entry() event, or any other in-process event for that matter.

While I may not be very well versed in software globalization, I am well versed in synchronization issues, and I think that the pointers given earlier in this thread are solid and right on the money.

If you can implement a synchronization scheme rather than using what is most likely non-deterministic behavior, you will be doing yourself a favor in the long run.

.

>> If you can implement a synchronization scheme rather than using what is most likely non-deterministic behavior, you will be doing yourself a favor in the long run.

I am *totally* (emphasis here, grin) not going to rely on what seems to be the non-deterministic (gotta love this computer lingo sometimes, eh?) startup order of the scripts. Why on earth would I rely on anything in SL that I don't have to, LOL. I was merely, only, simply, vaguely, in passing, curious if anyone else had noticed that scripts in a single prim, appear to be inviting us to believe that they are restarting in reverse alpha order. In fact, in my original posting, I mused that even if that were the case this week, in SL you couldn't count on it to be the case next week. Heck, even stuff which is officially supported in documentation you still can't count on it to be working next week without interruption.


I am going with the solution suggested by Qie, and it has worked a treat.

you are not getting it. any one of us can know with a two minute hack. but what we 'know' today will likely be untrue for some non-trivial set of tommorow. write your scripts to not be dependent on reset order or you are likely to live to regret it.

I think I've noticed something similar for the root prim, but on one of my products the reset order of the scripts in child prims doesn't follow an obvious pattern. It seems to follow a consistent one, but not an obvious one.

Still, as you can probably guess from my earlier post, I didn't look into it too closely

.

>> you are not getting it. any one of us can know with a two minute hack. but what we 'know' today will likely be untrue for some non-trivial set of tommorow. write your scripts to not be dependent on reset order or you are likely to live to regret it.

Nope, I get it. I'm pretty sure translation engine needs to start first and that's what I've done, thanks to Qie's suggestion, and it's working great finally. But I swear if I live to regret it, I will be honest and report back.

p.s. does anyone know if JEVN server scripts just start up in a random order? I know for instance that MLP scripts start in a certain order.

>> any one of us can know with a two minute hack.

kk once again, re the alpha order thing... i really don't care about that! It was just a "musing", I repeat, just a "musing".