Orderly resetting

I have one script (main prim) and a few other scripts (child prims) and I can't really figure out how to handle a reset in an orderly manner. Ideally the "main" script would be reset last (or "know" when all the others have been reset) since it sends a link message configuring all the "child" scripts.

Is there any way to get scripts to reset in a certain order or at least know when it's safe to send a link message after "Reset scripts in selection"?

I'm not fully understanding what you're referring to, but when you do the Reset all scripts in the selection from the menu bar it will give you a progress list of all the scripts and it will tell you when it's done with all of them.

There are ways you could script in a reset that you could perform by a command to the main script. You could then code it to send messages to the child prims to reset and in turn have them message back to the main script....at which point once it verifies it's heard from all of them it will reset itself, but that would all be more trouble than it's worth depending on what you're trying to do.

Sorry . Script A reads the configuration from a notecard and updates scripts B and C accordingly through a link message (they're all in different prims).

When I pick "Reset all scripts in selection" the order seems to be rather random.

If B and C reset before A there's no problem.
If B resets first, then A, then C, then B gets the link message but C won't because it'll be reset after receiving it.

the easiest way I can think of to get around this would have scripts B and C "check in" with a new, 4th script, D. once D knows that B and C has checked in, it will send a link message to script A that it's okay to read the notecard and then update B and C.

But since they're resetting due to the "Reset scripts in selection", D would just get reset as well?

I did find a "good enough in most cases" solution, which will probably have to suffice along with a "reset at your own risk" warning .

If I understand you correctly, I think you can use llResetOtherScript to reset other scripts when your main script is rezzed and enter the state_entry() function.

You can also use link messages from the main script to set your child scripts to reset with LlResetScript.

Well...what Senuka was getting at, and sort of what I was referring to...if you're needing certain scripts to reset, and then another...it easiest to be performed with more scripting.

You set a command that you tell it to reset on a certain message, and they in turn send a message to the other script to let it know that it needs to reset now that they're done.

I'm not the one resetting the scripts .

Someone buys the object, it starts acting up for whatever reason, they figure a reset might get it to behave it so they go to edit, then to World and pick Reset Scripts in Selection and the sims queues up every script to be forcefully reset.

Maybe I'm missing it, but a link message doesn't really solve the problem since every script except the main one now ends up getting reset twice and still in a random order: once forcefully by the sim, then a second time by itself through the link message (or the other way around depending on whether it sees the link message before, or after it's forcefully reset by the sim).

[Edited to add that my "solution" was just going about it the opposite way. The main script pauses itself until it no longer 'hears' child scripts resetting which seems to work, but will probably break on a very laggy sim ]

Ok, I understand what you're saying. Basically though what I mentioned is still feasible. You'd just be adding a feature into the works - a reset option.

The easiest way to do this in your case, since you want it to do this "when something messes up" you would just have to add another script that is only for the reset process so it won't get messed up and it can just reset them in the order that you require and either waits for a message from the script it just reset, or have a sleep command before going to the next reset.



I have a display pad and demo rezzers that I coded to reset either on their own if I add a new item, or in the case of the demo rezzer, I have a command in the touch menu to reset so it can reset the counter of how many demos it's rezzed. (I know I could just reset the counter, but I wanted it to reset the script as well so it would be a multi-function option)

Granted these are 1 script affairs, but the reset option is still sound...depending on your build, you could add a bright red reset button that resets the scripts in the order you specify on touch by the owner.

What I do in this situation is use a different state for resetting a particular script. In the project I'm working on now I have an object that is basically a 'controller' and a few other objects that behave subordinately to the controller. In each of the subordinate scripts, they will listen for an initialization command from the controller, and head into the 'init' state. Once the code in the init state is finished, I use the state_exit() event to inform the controller that init is finished. It then goes back to its usual state, in my case called 'online'.. and the state_entry() event sends a message to the controller that the script is now online.

There are a million different ways to manage orderly initialization, and I think using states and their corresponding entry/exit events is just but one.. probably a very good one at that.

zk

Don't try to control the reset order. Transactionally, what is needed is a "compensating action" on the child scripts.

* Anytime the main script resets, it should send the config information to the child scripts. (Normal behavior.)

* Anytime a child script resets, it should ask the main script for updated information. It must poll the main script until a successful reply is received. (Compensating behavior.)

Between those two actions, all the scripts will stay updated.

Take the above example having script A updating scripts B and C, with the reset order B, A, C.

1. When B starts up from reset, it will ask A for information. The (old) config is sent to it. No harm, status-quo (it already had the old information anyway.)

2. When A now resets, it loads the new config, and updates B and C. Now all are in sync.

3. When C finally resets, it asks A for information. A sends it the new information (again), which is again fine.

All three scripts remain synchonized.

-peekay