Communications Functions in No Script Areas

Does anyone know how to get llDialog, and llOwnerSay (and the other chat functions) to work in a No Script Area?

I have at least one purchased object that seems to communicate and function fine in a No Script Area - although generally they don't - but I have failed to produce a script of my own that will do anything but delay its response until outside such an area.

Is there a trick to this, or is it a secret?

If you're high enough the no script zone runs out, just like ban lines etc. I think that's at 30m above ground height from memory.

Alternatively the no-script zones actually stop FOREIGN scripts, the land owner's stuff will work just fine - the option is to allow outside scripts or not, not stop all scripts working.

...for example, the Terra WARP 2.1 speed boost works in all No Script Areas (and at all altitudes )

RequestPermission to, and then takecontrols for at least one key or sit on it.

I think things that are attached that only operate on your (like an AO) or themselves (like some speed boosts) that are working when you enter an area and are continuous might continue.

So no guns (can't rez bullets), but can get warp speed.

A DO WHILE or FOR loop will continue until the loop exits after entering a no script area, but it's a very bad way to make a script opperate in a no script area.

The methods I posted above will work perfectly fine for guns, AOs, blinking prim eyes, or anything else. No rez is the only thing that will stop a gun and then only if the gun is being fired from inside the no rez area.

Even using these methods to get your script to run, link messages will not work. They will be sent, and queued and will suddenly trigger your link message events when you leave the no script area. This actually make a pretty good way for detecting a no script area.

Also, scripts run slower in no script areas using these tricks.

Thank you, Richard... for reasons I don't understand that does indeed appear to work!

I've also set the pass_on parameter to TRUE as I don't actually want to take control of any keys.

I believe the idea was to keep vehicles from going out of control. Probably more to the reasoning than that though .

Actually all you have to do is have a TAKE_CONTROLS permission check in the startup of all the link children (doesn't matter if it doens't do anything with 'em) and link messages work fine too

L8r,
UU

oh? hmm... has it changed? I thought I'd tested it pretty thorougly once but it's been a while. And do you mean I only have to check to see if I have permission to TAKE_CONTROLS? I don't actually have to take them?

Must experiment later . Thanks for the heads up.

I was misremembering a little bit.

I just llTakeControls with pass along set TRUE, nothing else.

default
{
    state_entry()
    {
        llRequestPermissions(llGetOwner(),PERMISSION_TAKE_CONTROLS);
    }
    run_time_permissions(integer perm)
    {
        if(perm & (PERMISSION_TAKE_CONTROLS))
        {
            llTakeControls(CONTROL_FWD,TRUE,TRUE);
        }
    }
}

sometimes SL asks permission for each prims copy but only the first time I make an object.

L8r,
UU

I have noticed one annoying side effect of all this though. If you use the Release Keys button for any one attached object, it causes all objects that have the llTakeControls in force to detach. I guess this makes sense because you can only have one Release Keys button active at a time.

Oddly, if you detach and reattach an object without resetng the script then the llTakeControls (with pass_on parameter set to TRUE) trick is still working only the Release Keys button does not subsequently appear. Although, the object will still detach if the Release Keys button is pressed as a consequence of using some other object.