Keep script running at non-script sims fails after some time. Why?

[FantasmoX]

I have scripted a avatar attachment that displays the role on our roleplay sim.
This script is configured to work also in "no script sims", in order to turn off that display when elsewhere.

The script works fine for some days, then suddenly its functionality to override "no script" areas cease working. The script still works fine in script-enabled areas.

 

I call llRequestPermissions(user, PERMISSION_TAKE_CONTROLS); in state_entry

 

and

 run_time_permissions(integer perm)
    {
        if(PERMISSION_TAKE_CONTROLS & perm)
        {
            llTakeControls(CONTROL_FWD,TRUE, TRUE); // make this so it works in no-script areas
        }
    }

 

This seems to expire over time, but I don't see why!

 

Resetting the script restores its functionality for some days!

 

Any hint would be appreciated.

[Rolig Loon]

Was the region restarted maybe?

[FantasmoX]

No, it occurred regularly. Once in a while I teleport to a non-script region, just to check if the script fails, and it does... but only after days...

 

[Quistess Alpha]

would be interesting to see the results of llGetPermissions() and llGetPermisisonsKey() when the script doesn't have no-script area abilities.

[PheebyKatz]

3 hours ago, Quistess Alpha said:

would be interesting to see the results of llGetPermissions() and llGetPermisisonsKey() when the script doesn't have no-script area abilities.

I was thinking it might be something like this, myself. My titler works all the time, but it's just floating text, set as a prim property, and I only ever change the title at home, and we have scripts enabled. The OP's looks similar to an actual RP unit/meter, and yeah, I could see that not working on a no-script sim if perms somehow expired or something, and it had to call for them again.

My own stuff usually either works no matter what, or simply doesn't do anything when the region doesn't allow scripts. This thread has piqued my interest, because now I'm curious about why something would keep working and then just go ~urrrk~!

[FantasmoX]

17 hours ago, Quistess Alpha said:

would be interesting to see the results of llGetPermissions() and llGetPermisisonsKey() when the script doesn't have no-script area abilities.

But how do i get those, when the script is NOT running (in the no-script region)?

 

[FantasmoX]

14 hours ago, PheebyKatz said:

My own stuff usually either works no matter what, or simply doesn't do anything when the region doesn't allow scripts. This thread has piqued my interest, because now I'm curious about why something would keep working and then just go ~urrrk~!

Indeed, that's what is puzzling me.

And to make it worse: Its not teleports or logins or outfit changes (wear/unwear) what cause any of that, it is really after some period that things go ill.

I use this "no script region" to test

http://maps.secondlife.com/secondlife/Dixon Canada/32/96/21

 

Edited August 16 by FantasmoX

[FantasmoX]

Ok, some more research revealed that, who would have guesses, it is my fault.

I don't detach the object very often, as it turns off when elsewhere.

Turns out that each time I detach /attach the item, it fails working on "non-script" sims.

I was operating under the assumption that the permission stay put, but when I had a more suspicious look at the Wiki entry for llTakeControls, I found this in Caveats:

"The script will also lose this permission on reset, or if the object is deleted, detached, or dropped."

Adding a llResetScript in the "attach" event should solve it, as this will trigger the state_entry where I request the permissions.

 

Edited August 18 by FantasmoX

[FantasmoX]

Addition:  I put llRequestPermissions(user, PERMISSION_TAKE_CONTROLS); in the attach event, cause llResetScript caused issues with permission calls in the state_entry event (that fires on detach and goes through only halfway. This triggered script errors (Script trying to take controls from owner but PERMISSION_TAKE_CONTROLS permission not set!) when the rest of state_entry was run upon reattach.

[Quistess Alpha]

26 minutes ago, FantasmoX said:

that fires on detach and goes through only halfway. This triggered script errors

Your ultimate solution is more correct, but for the record, you have to check the id parameter in the attach event to know whether it's an attach or detach:

attach(key ID)
{ 
  if(ID)
  {  // attached, ID == llGetOwner()
  }else
  {  // detached, ID == NULL_KEY
  }
}

 

[FantasmoX]

Yes, I figured that, but then I thought that I actually do harm resetting the script, as it forgets things it needn't forget. So I opted for the simple refresh of permissions in the attach event.

The problem in my case was though that the state_entry event contains the requests for permissions, but upon detach this runs only halfway through before the object is in the inventory. Next time restored, it runs the rest, but has forgotten about the PERMISSION_TAKE_CONTROLS, as it looks.

So it throws an error.

Above solution doesn't solve this. I would have had to rearrange things. (put the requests only in the attach event)

What I might do actually, as a streamlining measure. It seems cleaner and makes more sense in "attach" than "state_entry", when I think about it! Then the permissions all are handled at one location in the script!

Edited August 18 by FantasmoX

[PheebyKatz]

I find this thread exciting to come back to.

The Scripting section is like my version of the Adult section. Just saying.

Seeing other people make progress with a scripting project is almost as good as having real scripting myself.

[sandi Mexicola]

On 8/18/2024 at 3:08 PM, FantasmoX said:

Ok, some more research revealed that, who would have guesses, it is my fault.

I don't detach the object very often, as it turns off when elsewhere.

Turns out that each time I detach /attach the item, it fails working on "non-script" sims.

I was operating under the assumption that the permission stay put, but when I had a more suspicious look at the Wiki entry for llTakeControls, I found this in Caveats:

"The script will also lose this permission on reset, or if the object is deleted, detached, or dropped."

Adding a llResetScript in the "attach" event should solve it, as this will trigger the state_entry where I request the permissions.

 

Thank you kindly for giving us the answer!  👍

[sandi Mexicola]

On 8/25/2024 at 2:17 AM, PheebyKatz said:

The Scripting section is like my version of the Adult section. Just saying.

😁