VERY Basic Question - The "Running" tickbox on the editing window.

I guess (to me) this seems totally obvious, but I'm aware that what might SEEM logical, may in fact NOT be logical

So, I have an object with a script. We'll take two very basic examples.

Texture flipping (for a prim fire) and a Rotation (for a globe)

Open up the script editor and the "running" tickbox is checked because it's working and doing it's stuff.

But I untick the box (so I would guess this means the script has now stopped) but it's STILL working.

Can anyone explain the logic here?

Some functions, like llParticleSystem and llSetTextureAnim are actually properties of the prim itself. The same goes for llSetText (hover text). The properties stay with the prim even though the script is disable or removed. The only way to disable them is to set the properties accordingly with another statement. The only other way is if the prim was reset by an SL crash or database failure and the prim's properties were reverted to defaults.

When you uncheck the Running box the script simply stops where it is.
The script is not reset. So any function, like llTargetOmega for rotation, that is called in state_entry will be effective when not running.

Like this for example:

integer count = 0;
default
{
state_entry() {
llTargetOmega(<0,0,1>, 1, 1);
llSetTimerEvent(2);
}
timer()
{
count += 1;
llSay(0,(string)count);
}
}

When you uncheck Running the counting stops and rotation continues. When you check, the counting RESUMES.

Same goes for texture functions.

Ah thanks.

In plain English

So with these (and poss some other examples) you are just TELLING the prim how you want it to behave and once it's "Told" It then knows how it should behave and does not need telling again, unless something goes wrong and then it would need it's instructions again.

Does this mean that there is any benefit to Users (Client or Server) side to turning say a rotation off after it's started. by that I mean, is this one less script that the sever has to keep running?

In this case, does a rotating prim thats had it script stopped (but keeps on going) cause any loading whatsoever on the SIM, or is it running "For Free" as it were?

=== EDIT ===

So is it worthwhile, or totally pointless to move around any scripts you can see and turn them off, if the "Effect" keep running.

Just experimenting myself. I had a 1 prim log with particle effect fire and a cracking sound which I turned both the particle script and the sound script off and it all still works fine.

Also a small particle waterjet with colour changing script also, both of which I turned off and it still keeps running.

Good practice, or just a waste of time?

The scripts you are talking about have already done their job. They aren't "running" in the sense of doing anything. Particles are like color, transparency, flexi, or other properties of prims that need to be set -- either in EDIT or by a script -- but don't have to be told to continue existing. Once a script has told a prim "make particles" or "be red," it's not doing anything else. You could remove it if you like, but it won't make any difference either way.

Thanks.

This is what I didn't understand.

What I thought might be happening was that as (for example) a rotation script was "RUNNING" it was continually looping round this running script 1000's of times, when all it needed to do was run through the settings once and stop.

So, you are saying that it does in effect do this?

The running script just runs through the list of settings and then stops itself.
Only (I guess) running again, in the event of a crash or something?

I had in my mind that all scrips that were running (not unticked by the tickbox) were constantly looping around day and night for no reason.

Actually, experimentation on scripts shows a couple of oddities:

1. An idle script does take up a very small amount of time on the sim. At least it did with the LSL2 interpreter and since this time was attributed to the server's event handler logic it SHOULD still be true for Mono.

2. Some prim attributes (apparently including rotation) don't seem to reliably get restarted after a sim reset unless the script that started them is still set running.