Listens and LinkedMessages and Removing and... o.o

I am about to revamp a bit of code now that I know more about LSL.

But I have questions... questions that must be answered, in fact, if you are viewing this, you have to answer, even if you don't know the answer. o.o

And what I mean by that is...

Will someone please explain the concept of listeners "piling up" when they are not removed? If I have an object that has llListen(blahblah) in its "state_entry()", and I do not have an llListenRemove() anywhere in the code, and the code does not ever change states, will the object have the problem of the listeners "piling up" every time it is rezzed? What if the object is an attachment? I am trying to learn everything there is to know about listeners and removing them.

Also...

If I have an attachment... say... a pair of wings. A single object, with 7 prims, 3 prims for each wing, and another prim for the center point. Say I want a hud button to change the color of these wings... should I put a listener in each of the 6 prims that make up the wings, or should I put a single listener say... in the 7th prim, the center piece, and use LinkedMessages to communicate the information to the other 6 prims?

ALSO...

What's the deal with llGetOwner having problems when the object with the script with llGetOwner in it is given to a new owner?

This code was taken from the wiki...

default
{

state_entry()
{
llListen(0, "", llGetOwner(), ""; // listen to my owner
}

listen(integer channel, string name, key id, string message)
{
llSay(0, name + " said: " + message); // repeat owner's text
}

on_rez(integer start_param)
{
// every time we're rezzed, reset the script
// this ensures that if we're transferred to a new owner, we're listening to them and not still to the previous one
llResetScript();
}

I did not see what the llResetScript is needed, would the script not execute the line "llListen(0, "", llGetOwner(), "";" every time it is rezzed anyways? I would give the object to the new person... and they would rez it in, or attach it... and the first thing it would do is llListen to llGetOwner, which would return the current owner...

In fact, I have an object that I have done this with, and it seems to have no problems...

I think that is all.

?

First off: I never used a hud to communite with an attachment. I am using dialogs for this. Just add an on_touch to the root-prim and generate dialogs for the colors.

Next topic: I'd use linked Messages. Just use one listener as the receiver, and then send linked-messages to all the child-prims, telling them to change color.

If you transfer an items, the scripts wont be reset. So "state_entry" would just be executed once if you had no resetscript in onrez. The items would still listen to the old owners commands bu not the new ones. Use this snippet - should work great for you:
http://secondlife.com/badgeo/wakka.php?wakka=llListenRemove


LG,
Ninn

OK, if you only have 1 listener ever then no it won't pile up from the state_entry event... reason state_entry only runs when you enter that state (as you might guess from its name) which happens when 1) you change to that state or 2) it's state entry in the default state and the script is reset or recompiled (putting the script from inventory into a prim resets it btw).

However, a lot of people turn listeners on and off, especially on channel 0, if you just add new each time, then they will build up.

The llResetScript() in the on_rez event forces the script to reset, and so run the state_entry event for the default state, setting the owner correctly each time. When you buy a scripted object the script does not (well did not anyway, perhaps it's an undocumented change, but it seems unlikely after yesterday's experience for me) reset or recompile. Thus state_entry does not run. The exception being if they only buy the script and put it into their own prim. Because state_entry does not run it carries on using the old listener values. llGetOwner() is not a "magic wand" that autoupdates, it simply provides the key of the current owner when it's run. Since that's you when you compile the script, it will continue listening to you. Hand it to someone else without reseting and it will carry on listening only to you, because that's what you've told it to do.

There are other ways to do this btw, depending on the functionality - changed() registers a CHANGED_OWNER value which can be used to either reset the script again, or remove the old listener and call a new one if you prefer.

Talk to me in-world sometime and I'll show you the object/give you a copy so you can see for yourself that it works...



You did not answer that question at all.



Okay, that's a welcome suggestion, but can you tell me why?

I do appreciate the feedback...