How scripts work when "Run Scripts" is off (Scripts disabled)

Hi everyone,

I've been doing some scripts for a HUD and I've noticed how if I go into an area with scripts disabled (Run Scripts is off in the parcel settings), my HUD ceases to function. I understand this is typical - I wouldn't expect to be able to interact with my HUD - but I do except my HUD to still actually function and keep doing what it's meant to (such as changing text and saying things through llOwnerSay).

I do not understand what it is that is causing my HUD to completely cease functioning when I go into a no script area. Every other HUD of mine (radar, AO, defences, etc.) all still function as though scripts were still on, it's just I can't interact with the HUD itself to change anything.

Can anyone suggest how I can get my HUD to still do its basic functionality? All my other HUDs manage to, and I don't understand what's different.

I'll really appreciate some advice on this matter.

Thank you,

Ethari

no scripts means the stop running... at all.

however it has been discovered that if a script takes controls, it'll continue to function even though it's on no-script land. this is used most for thing that MUST RUN all the time (like AO's).

Interesting... My radar would have no need to take controls, yet it still works in no-script areas. Perhaps it is taking controls somehow even though it's not using them, simply to exploit this to keep it running.

Any ideas? I'll investigate.

Edit: Haha! That's amusing. I just did "Release Keys" and every single HUD of mine, except my own that I made, got detached. It would seem all of them take controls in some way, probably exactly for this reason.

Edit 2: I can confirm this works! It seems to be per script, and not per object. Therefore it needs to be done for each script that needs to function. I am wondering if there is a way to detect if scripts are disabled so I can set my HUD into a different mode (like a basic mode that needs little functionality).

now you're catching on... you don't actually have to DO anything with those controls.

Yep. Did very basic control taking (actually did mouselook left mouse button, as that rarely even gets fired) and set control blank.

Now I need to figure out how to detect if scripts are off so I can do a basic working mode. Otherwise I'm going to have to put control taking into every script, which is rather stupid considering I have about 40+ scripts in my HUD to handle text.

:: blink ::

40+ ?

in a single hud?

WHY!?!?!?!!!!

:: sigh ::

as for detection that's easy.. non control script that just relfects a message... if the message doesnt come back, you're on no script land... or in your control script you can check the land flags for where you're at (llGetParcelFlags( llGetPos() )), or even llScriptDanger( llGetPos )

there are uses for all three methods.

Detecting whether you're in no-script land won't help because... when you're in no-script land, you can't detect it and take controls, because you're already not running! It's like trying to open a package with a crowbar inside the package.

Yep, I understand the issue with taking controls after you're already in no-script land. My requirement was to figure out if I was in no-script land after I had already taken the controls previously (so I could change some things). I just realised I don't really need to do it anymore though

And Void, there are a lot of HUDs with a lot more scripts than that in It's what you get when you've got complex HUDs with many buttons and text and layout arrangements.

I've been testing things out and I think there may be a limit of controls you can take for the same thing within the object. I tried it with 6 scripts or so that all took mouselook left mouse button and some of them didn't work. Changing half of them to something else then worked. The undocumented 64 and 128 work too.

I'll need to do more investigating, but it may seem I need to get a way to evenly distributed different controls to different scripts. Perhaps a different combination.

This is getting rather silly, huh.

Thanks for all the help by the way I would never have figured out that controls are required to keep a script going in no-script land.

Just in case you've got scripts just to say "I'm a button and somebody pushed me!", take a look at llDetectedLinkNumber. It's sometimes a lot easier (and nicer on the sim) to name button prims with meaningful names then use llGetLinkName(llDetectedLinkNumber(0)) in the main scripts touch_start.

Not entirely true, a script can detect when it's on a no-script land, and send a brief message, much like if an item is detached. I have a couple of huds that if you go over no-script land, it warns you.

You sure they're not taking controls?

This

another option is the llDetectedTouchUV (or ST) functions, which will allow you to have a single texture with your buttons on it, and decide what button is pressed by the position of the touch....

one script to control them all... and in the dark prim interior, bind them (and all that jazz)

Also, I believe above a certain elevation over the ground (50m?) scripts continue to run. I think that's if scripts are turned off in the parcel options, not if they are turned off for the whole sim.

didn't know it worked differently for the who sim setting (unless you mean disabling all scripts from top scripts)

it's higher than 50 if memory serves... but easy to check. hit ahren note ground level fly up slow until things start working again (like ao's).

oo I did forget... TPing into a no script area will still turn it off IIRC, but walking into one wont

Nuh-huh. I TP into no-script areas all the time and my HUDs are still happy.

There is a corner case with something like that, it's more about relogging into a no scripts area, and not having all the scripts taking controls/asking permission doing it the same way.

All scripts requesting control permissions in the same prim should all do the same thing (if one actually takes controls, all requesters should take controls). Otherwise, some scripts can end up running and others stopped until the avatar wanders out of that no script area, then the usual stuff works. Scripts in the same prim that don't request control perms in the first place aren't affected by this, they keep on running.

wait, you're saying that if ANY script in a prim requests controls, ALL scripts in that prim recieve the no script area protection!? now THAT I didn't know.

@Argent:
I could've swore my AO quit working on tping into the WA but rebooted and worked fine once I slew up and reactivated it. but it's been awhile since I tested.

Not so far as I know.

Yep. But it's only the same prim, not the whole object.

Maybe the corner case is that logging in might require that scripts re-obtain controls, and they can't do that because they stop executing first? Don't know. Just a guess.

It did seem to be something like that. Somewhere in the horrific mess that passes for my inventory is a pair of scripts that will trip that problem, if I ever get really really bored I'll try to find the exact combination of things that don't work together.

I was about to say "I don't think so!" but then noticed you said prim and not object. It would be nice if this was per object.

And about your earlier recommendations on touches, thanks for informing me but I am well aware My scripts in my prims carry out a LOT more than simply that

good to know, but you do realize that every running script takes up some resources whether it's doing something or not, right? if nothing else the script time is constantly updated whether it's used or not. you might want to consider consolidating scripts that use similar functions at the very least (or ones that use completely different input/output methods as they can't collide) 40+ is alot for even a huge feature set, and if multiple scripts are processing the same inputs you're adding to your script time overhead unnecessarily.