object ownership initialization

Let's say I've created an object, it has one or more scripts in it. In that object, in state_entry() I say.....

key id = llGetOwner();
string name = llKe2Name( id );

Further down in the object, in one of the other scripts, I do some llDialog work too.

Now - I give a copy of the object to a friend and she gives it a try. To my astonishment, I get the menu's I intended for her to get. Clearly I need some initialization help here. Can anyone tell me why isn't the new owner of the object being picked up by state_entry()? And what I should be using in addition or instead?

The object in question is intended to be worn as a hud, if it makes a difference. And if it does, what should be done in other cases?

Thanks,
Robin

A script remains in its running state unless stopped or reset. Taking it into inventory merely suspends the running state. If you make a copy, BOTH copies have the script still running. The object may have changed owners, but the script doesn;t know that. If you want the script to know that ownership has changed, put a changed event in the script, test for CHANGE_OWNER, and then llResetScript.

Thanks so much!

If I have more than one script in an object, I guess need to add the changed event and llResetScript() to each. Or is there a reason to not do so?

robin

Good plan. While you're at it, be sure that you also have a changed event in each state of a script (if it has more than one state).

changed(integer change)
{
if (change & CHANGED_OWNER)
{
llResetScript();
}
}

there are several reasons why you may not want to reset a script, including preserving current script state, and variable contents, like configuration settings.

in most cases the only reason to reset on owner change is because some initialization data depended on the owner, and once that changed it needed to be updated (command listens are a common example).

it is possible to code around these needed updates without destroying current data, by either putting you initilizing functions that depend on the owner into
A) their own state, and calling that state on change, which afterward forwards to the working state
B) their own function, called from state entry and the changed events

if you are just storing the owners key for comparison references, it's smaller (though not necessarily faster) in most cases to just use the built in llGetOwner() call which will be current every time you call it.

the state method is god if you're canceling old listens and installing new ones (because listens are canceled when you change states), and the function method is probably preferable in most other cases.

Void has right you dont need to reset the script if you have some important data in there , just use another state keeping the esential data in teh first state or make the getOwner call again in your changed owner .

oh, and as a fun "abuse the system" trick...

a common method for providing multiple listens that cancel after a timeout (think multiple users and dialogs) it's often easier to to just jump to an empty state and back, then to track them. (which cancels ALL open listens).

the fun part is if you have special owner only functions/responses defined based on llGetOwner, instead of resetting, or even updating the listen in the changed event, simply force a normal listen timeout, and restart your owner listen as normal =)