What does "run scripts" ACTUALLY do? Avatars can still run scripts with it off... why?

[Sasun Steinbeck]

I've always been a bit baffled by the "run scripts" parcel option. Set up a parcel with all permissions on (Options tab) EXCEPT run scripts for everyone. Leave group scripts on so your stuff still works! I'm doing this testing in an LL region.

Bring in an avatar that is NOT in the land group. Verify that the avatar can see the tiny icon on the top bar that shows that scripts are disabled. Using that avatar, rez a box on the ground, create a default script. Verify that the box is NOT tagged with any group. Don't edit it. Touch the box. The script is obviously running. Why? What exactly does "disabled" mean here? Nothing?

I've tested this on my parcel with an alt that is in NO groups, no special permissions, nothing. How can this avatar run scripts on a parcel where this permission is disabled? What am I missing here?

[Sylvia Tamalyn]

Have  you tried testing scripts that the non-group avatar is wearing, such as a HUD? 

[Sasun Steinbeck]

27 minutes ago, Sylvia Tamalyn said:

Have  you tried testing scripts that the non-group avatar is wearing, such as a HUD? 

Yes it doesn't matter whether the default script is attached or not. In fact the old trick of allowing scripts to run in non-script areas ONLY works for attached scripts but in my test case I'm rezzing a fresh prim and default script on the ground. Picking it up and re-rezzing it makes no difference, neither does relogging to refresh permission checks.

[primerib1]

Well, I have a HUD that I created myself.

The HUD stops working when I entered someone's parcel that doesn't allow scripts.

And it works again as soon as I leave the parcel.

So it seems to work, though what circumstances makes it applicable might need to be clarified.

[Gabriele Graves]

I'm pretty sure that this is only suppose to affect attachments.  If a scripted attachment requests controls, even if it does nothing with them, the script will be allowed to run.  This is to make sure vehicles entering the parcel aren't affected.

Edited November 30, 2022 by Gabriele Graves
Removed incorrect information

[Sasun Steinbeck]

Ok I'm a dummy, because I KNEW THIS ANSWER lol. Scripts are only actually disabled below a certain altitude. I'm doing all my testing in a skybox... where scripts always run. Duh! So yes, on the ground, that setting DOES WORK in all cases, attachment or not. I forget what the cutoff altitude is...

Attachments follow the same rule I believe. To elaborate on what you said, just get PERMISSION_TAKE_CONTROLS permission and your scripts will not stop running if you enter a no-script area (I believe with the exception that if scripts are disabled for the entire region, NO SCRIPTS run, period).

[Gabriele Graves]

2 minutes ago, Sasun Steinbeck said:

Ok I'm a dummy, because I KNEW THIS ANSWER lol. Scripts are only actually disabled below a certain altitude. I'm doing all my testing in a skybox... where scripts always run. Duh! So yes, on the ground, that setting DOES WORK in all cases, attachment or not. I forget what the cutoff altitude is...

Yes, I'm a dummy too because I did know this and the altitude is 50m above the terrain.  Still between us we got there

[Sasun Steinbeck]

Just now, Gabriele Graves said:

Yes, I'm a dummy too because I did know this and the altitude is 50m above the terrain.  Still between us we got there

LOL yes the power of community think Thanks!

[animats]

Huh. I just tried that over at "TONAL 1", which has both no-script areas and marked rez zones.

• If I rez a vehicle and get on, I can drive it through a no-script zone. But if I get off, it won't shut down properly.
• A scripted non-HUD attachment still worked in the no-script area.
• A scripted HUD attachment did not work in the no-script area. But its touch events were queued and things happened once in a script area.

This is all at ground level. Can't fly there, and felt it was rude to rez a helicopter.

 

[Fluffy Sharkfin]

1 hour ago, animats said:

Huh. I just tried that over at "TONAL 1", which has both no-script areas and marked rez zones.

• If I rez a vehicle and get on, I can drive it through a no-script zone. But if I get off, it won't shut down properly.
• A scripted non-HUD attachment still worked in the no-script area.
• A scripted HUD attachment did not work in the no-script area. But its touch events were queued and things happened once in a script area.

This is all at ground level. Can't fly there, and felt it was rude to rez a helicopter.

 

The attachment point (HUD or non-HUD) is irrelevant, the important part is whether or not the script in the attachment has control perms, if it does then it continues to function in no-script areas as long as it remains attached.  If one attachment continues to work and the other does not, the most likely explanation would be that only one of them has requested control permissions.

[Sasun Steinbeck]

1 minute ago, animats said:

Huh. I just tried that over at "TONAL 1", which has both no-script areas and marked rez zones.

• If I rez a vehicle and get on, I can drive it through a no-script zone. But if I get off, it won't shut down properly.
• A scripted non-HUD attachment still worked in the no-script area.
• A scripted HUD attachment did not work in the no-script area. But its touch events were queued and things happened once in a script area.

This is all at ground level. Can't fly there, and felt it was rude to rez a helicopter.

 

I'm guessing that as soon as you get off the vehicle your PERMISSION_TAKE_CONTROLS is revoked and scripts immediately stop. That definitely happens if a scripted object is detached, maybe the same applies to un-sitting.

Also, I just remembered, the important thing to do is not just get PERMISSION_TAKE_CONTROLS but to actually call llTakeControls(CONTROL_FWD, TRUE, TRUE); then your script will ignore no-script settings.

[animats]

8 minutes ago, Fluffy Sharkfin said:

The attachment point (HUD or non-HUD) is irrelevant, the important part is whether or not the script in the attachment has control perms, if it does then it continues to function in no-script areas as long as it remains attached.  If one attachment continues to work and the other does not, the most likely explanation would be that only one of them has requested control permissions.

Ah. That makes sense. The one that works requests CONTROL_ML_LBUTTON, because it lets you point to stuff in mouselook and get info.