Poseball Anti Hide/Show

HIyas Everyone,

I have existing poseballs rezzed that show/hide on chat channel 1. I would like to create a small script to drop in an object that will cover a range of poseballs that prevent other avatars from showing/hiding those poseballs.

I'm starting out with the following script which seems logical to me but for some reason I am not registering other avatars keys. All help will be greatly appreciated!

This is anti-show

integer chan = 1;
key owner;

default
{
    state_entry()
    {
        
        llListenRemove(chan);
        owner = llGetOwner();
        llListen(chan, "", "", "");
    }

    on_rez(integer start_param)
    {
        llResetScript();
    }

    listen(integer channel, string name, key id, string message)
    {
        if (message == "hide" && id != owner)
        {
            llSay(chan, "hide");
            llSleep(1.0);
            llResetScript();
        }
    
    }

}

That's a really complicated script!

integer CHAN = 1;

default
{

state_entry()
{
    llListen(CHAN, "", NULL_KEY, "hide"); // filter before the script
}

listen(integer chan, string name, key id, string message)
{
    if(id != llGetOwner()) // There's no net savings in caching llGetOwner();
        llSay(chan, "show"); // You want to "unhide", right?
}

}

Thanx Argent!

in which context? speed? code size? reliability across sim bounds (ok, a stretch there)?code size, yeah, speed, I dunno, reliablity (a granted edge case).. does get owner stay reliable, w/o the owner there? I forget =/

llGetOwner() returns your own owner, which is stored with the prim you're running in... if it's going to fail so is llGetTexture() and any other llGet*() call that inspects the prim you're in. If you cache it you have to have a bunch of code to check for all the places the owner can change. It doesn't take many event firings to make caching it a net loss.

I'm not so sure about that last part... using LSO I get 15 bytes more for the function call than for referencing the variable, although the extra code involved in storing the variable is larger (I don't see multiple callings affecting them overall since it's a one time spike), but I'm sure the variable reference is faster than the function call.

I suppose if it's pure speed you're looking for the variable is the way to go, or if you are doing several other things with that key after you've got it. as just straight test, the function is more effective memory-wise. although I see the opposite of what you're describing, in that multiple calls to the function in the same section of code aproach the limit of the stored variable bytecode size (during run) and eventually overtake it. (8 references takes more memory with a minimally encoded update on changed owner [you can precode the creator key] if you aren't reseting. 10 uses if using standard reset + state entry logic, -1 if the changed event was already there for something else.)

I was thinking about the llKey2Name issue re: reliability, which doesn't apply here.

The function call is only in one place, there's only one thing being done with the key. If you were using the value two or three places, I'd write "key owner = llGetOwner()" at the top of the listen event, because the value isn't going to change during the listen event... but that's a different matter from adding all the code to handle properly caching and updating the value in a global variable. All those changed() events aren't free, they fire whether the thing that changed() is something you're looking for or not, and an event not handled takes 0ms.

On the other hand if you have a more complex program that is handling changed() events anyway, that's different.

It's like where I did an llListen() for "hide". If it was listening for "hide" and "show", I mightn't do the check there, I'd think about doing it down in the function. If there were four or more cases, it'd be llListen() for "" and a check in the body for sure.

good point, which I suppose reduces the positive to only be in cases where the update code reuses events (and then there's still the case of those events triggering the update check needlessly...)

I concede, there's very limited circumstances where storing it might be an improvement. consider me a convert =)