Detect Key of rezzing 'parent' object ?

I don't think there's really a good solution for this, but no harm in asking, maybe I've overlooked a posibility.

Is there a proper way to have an object know the key of it's creator? object_rez gives the creator object a key of the rezzed object, but on_rez only has the parameter.

I'd hate to use listens, emails or sensors to 'communicate' the key, but maybe there is no other way..

We've had to implement that in the Sloodle project, and it was only ever practical with a listen. If you want extra security, you could generate a random channel number, and pass it into the object's "on_rez" parameter, and then have the object only listen on that channel. Additionally, you could simply ignore any message which comes from an object owned by a different avatar.

EDIT: btw, one thing to watch out for is lag! You may need to sleep the rezzer for about 0.5 seconds before sending the chat message.

there is an indirect approch I use myself:

typeChanel = -1234567;
someID = "vfrgtb5#!"
default   // in rezzing object
{
...
}
state invDiff
{
    state_entry()
    {   
        llRezAtRoot( , , , , typeChanal );
        llSay( typeChanal, someID ) ; // handshake rezzed objects
        state begynd;
    }
}

    
someID = "vfrgtb5#!"
default // in rezzed object
{
...
    on_rez( integer parm )
    {
        typeChanal = parm;
        llListen(typeChanal, "", NULL_KEY, "");
    }
    listen(integer kanal, string name, key id, string message)
    {
        if ( message == someID ) rezzer_key = id;
    }
}

I too typically do this with a random channel number passed as the rezzed object's start parameter, then a chat protocol for communicating the information. I usually filter on object owners too (where region boundaries aren't an issue) just in case.

It's usually best to wait until the "object_rez" event before sending the 'handshake' chat message, because rezzing can often be delayed (especially when the asset servers aren't playing nice!).

Oh. I often actually start a listen from the parent before even making the call to rez, then have the child initiate the chat and the parent respond. That way you can be CERTAIN the child is ready. It depends a little on the application though. If you rez one or two child objects at a time it works well. Otherwise it may take too many listens, too much memory, etc. Even then you might be able to get away with a single channel that rotates when the number of responding children has caught up with a count of the number rezzed or something.

I personally use a pattern of the following for secured rezzing:

X = originating Object
O = Rezzed Object.

X: open a listen on CHANNEL - 1.
X: REZ object with number CHANNEL

O: set CHANNEL to REZ number.
O: listen on CHANNEL.
O: Respond to X on CHANNEL - 1

X: hears O, checks for owner and name of object to match what was rezzed.
X: respond with data to O about what it should do.

O: gets data on CHANNEL, and sets it's rezzer to be equal to X's KEY.

Etc...

I also advise to have timers based on if this breaks down, O deletes itself and X tries a rez again.

Then again, I'm spending 75% of my coding time building against 'worst case issues with SL' that seem to happen a whole darn lot.

Go fig...

I once made some code that causes the rezzed prim to link with its mother on rezz.
-Mother transmits its key to its rezzed prim.
-Rezzed prim can only attatch to its mother if the owner is the same and if both prims are modifiable.
-Linkmessage is a fast and private channel.

-This is worth its deelay if you want to copy actual inventory to the rezzed object or transmit a lot of variables.
-may not work with attachments or large (physical) linksets.