On llTakeControls and permissions

Hi all. I'm getting a headache from trying to reliably use lltakecontrols.

I have a hud with 36 prims. The Main collects data and distributes to the children. Works perfectly, except in NoScript areas and so I decided to try out llTakeControls. All of the scripts have this code:

state get_control
{
state_entry()
{
llSetTimerEvent(10);
if (debug == TRUE) llOwnerSay("@SE";
perms = llGetPermissions();
if ((perms & PERMISSION_TAKE_CONTROLS) == PERMISSION_TAKE_CONTROLS)
{
llSleep(2.0);
llTakeControls(CONTROL_ML_LBUTTON, TRUE,TRUE);
controlled = TRUE;
if (debug == TRUE) llOwnerSay("ct@SE";
}
else
{
llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS);
}

}
run_time_permissions(integer perms)
{
llTakeControls(CONTROL_ML_LBUTTON, TRUE,TRUE);
controlled = TRUE;
if (debug == TRUE) llOwnerSay("ct@rtp";
state default;
}
timer()
{
if (debug == TRUE) llOwnerSay("TMO@g_c";
llSetTimerEvent(0);
state default;
}
}

on the state_entry of default is:
if ((take_control == TRUE) && (controlled == FALSE)) state get_control;

take_control is initialized with TRUE, controlled with FALSE as globals.

Here's what happens.

I lay the scripts into the prims. Each one EXCEPT the Root prim responds with a permission request panel. The Root prim debug reports "ct@rtp" from the debug.

The Hud works perfectly in any area. However, when I DETACH and then wear the hud
all the prims start timing out repeatedly. Precisely 5 prims (never the Root) respond with the permissions panel and stop timing out. If I DETACH and wear again it repeats with a different and random 5 prims requesting and getting permission.

I am clearly mistaken about llTakeControls and getting Permission, but how so?

Can't say as I understand what's going wrong, but I also don't quite understand what's being attempted.

I'm not sure if an unlimited number of scripts can--or should be able to--simultaneously llTakeControls. It would mean that the control() handler of each of those scripts would be queued every time any control was pressed, which seems like a Bad Idea... but I don't know that this is actually limited.

Also, I'm not sure it's necessary to take controls at all. I haven't had a chance to test this, but according to a comment on http://jira.secondlife.com/browse/SVC-556, it's only necessary to get the permission to take controls--not to actually take them--in order for the script to continue running on no-script land. So that might be worth a try.

But finally, I'm also not sure whether that all those HUD prims really need to be scripted at all. If possible it would seem better to use llSetLinkPrimitiveParams (and, for input events, llDetectedLinkNumber), perhaps with a little help from llGetLinkName so it's not fragile to change of link order. If that's viable, it would cut down on the number of scripts that need to get permission, not to mention the number of scripts that need to exist at all.

I'm a little focused on the problem, and need to widen my field of vision. The Hud is a data collection device. It provides a means to collect and manage information on people, places and things with notes, timestamps, and coordinates distributed under the name SLLogger (SL Logger).

By example, it allows a person to record a particular vendor at a particular site with a particular item for a particular price. (Or would, if the site allowed scripting.)

That you can disable scripted objects, but only ALL scripted objects is, I believe, a shortcoming. However, I do understand that ANY distinction opens an entire dimension of cases to handle. Nonetheless, a distinction could be made for intra-object communications, as opposed to rezzing, movements, or effects on others.

You do raise a possibility I haven't considered, that obtaining permissions may be sufficient. Thanks for that, at least it's something to try.

My separating the lltakecontrols and permissions processing into another STATE appears to have been the root problem.

Compounded by a timing issue.

Here is what my testing yielded:

1. Requesting controls alone produced no good result, whether for the Root Prim or all prims.
2. Getting Control for the root Prim did NOT enable any other Prim to execute at all, including getting a linked message.
3. Every Prim that needs to receive OR pass a linked message, or function in any way in a NOSCRIPT zone has to complete the llTakeControls function successfully.