Could we have llRezzerKey() please?

It sure would be nice to have a function like llRezzerKey() in LSL. Call it in a script and it returns the UUID of the agent or object that rezzed the object running the script. Real handy for passing information to just-rezzed objects -- as in
llKey2Name(llRezzerKey()). Wow, that would make my second life easier!

Cheers,
JLB

Apart from the fact you would need to have mod access to the object to place a script in it to tell you who rezzed it....... When that information is already available as the owner (unless it has changed hands since being rezzed)

What exactly are you trying to do?

Call llGetOwner() in the on_rez handler and save it.

The on_rez event already receives an integer parameter from the llRezObject function.
You can just this parameter as a listen channel and the the rezzing object whisper whatever you want - including it's UUID.

http://www.lslwiki.org/index.php/On_rez
http://www.lslwiki.org/index.php/LlRezObject

llRezzerKey() is a good idea however I would prefer on_rez(integer start_param, key id) just like there is object_rez(key id)
The value of id could then be reused into a global variable.

The use I see for this is for the rezzed object to be able to listen to its rezzer only and not all objects named like it.



Being given the rezzer's key on_rez would avoid this.

Yes, yes, I know, that's what I do now.

If I have one object that rezzes another object
and wants to pass a lot of information to it, that's the only way. It involves llListen() and those are slow and can cause lag. It would be much faster for the sim if I could pass the
information by changing the rezzing object's name and then
calling llKey2Name(llRezzerKey()) in the rezzed object.
That's a cleaner solution to the problem, IMHO.

(And, of course, llGetOwner() gets the owner, not the object that rezzed the other object.)

Cheers,
JLB

Ahh, now I see what you mean. How much information are you trying to pass ? Even names are restricted to only 128 bytes (reliably)
How about this as a workaround

Rez the object with a channel ID
Wait for a query from the object on that channel. ("Hello?"
Set the rezer's name
Send a "Data Ready"message on the channel
The rezzed object will receive the rezzer's key as part of the listen event.
Then use the llKey2Name function to get the data.

Listens used in a narrow context for a short amount of time definitely aren't that much of a drain on the server. I think doing all this fiddling around with llKey2Name() would probably end up being just as much of a drain... and it'd be less reliable.

In your rezzing object, you can wait for an object_rez() event, which will tell you the key of the object you just rezzed. Then you can send a message on a channel that mentions that key and the rezzer's key and name (well, I guess those are both implicit in the listen() event) on a channel number passed as the rez parameter, as mentioned above. Make sure that the rezzed object already has the listen event open when it's rezzed (do it in state_entry()). Once it gets the message from the rezzing object, have it close the listen. Very little lag would result.

Gah. I can do that. *sigh*
I still want llRezzerKey() though. Why not?

If you are not put off by the linking (delay), you could have the rezzing object link and unlink the rezzed object and in the meantime use llGetLinkKey()* or link messages.

* Optionally passing the link number as start parameter.

Oh, I'm not faulting your suggestion... just playing devil's advocate a bit. Until we get llRezzerKey(), at least there's a feasible alternative.

I'm still not sure I see what benefit llRezzerKey() is going to give you.

The only example I've seen given in this thread was to get the name of the object that rezzed the prim.

If it is something you are scripting you can just have the parent send an llEmail to the child prim onRez with all the information you need.

Listen events are designed for agent/object -> object interaction. They are not inherently evil.

It's bad implementation of them that is evil.

Opening a listen, processing a data transfer, and closing the listen on a non-zero channel does not generate any appreciable lag.

Because LSL cannot be built to support every "good" ideal. It will rapidily become blotted and useless.

llRezzerKey() would definitely be nice, especially as Im not fond of "spewing" data out into the void using chat. The most elegant way I have found for passing on data is by packing your information as an integer, using various bit manipulation tricks, so that your receiving item can reliable get 32 bits of info, which the item is guaranteed to get, causes no real lag, and has no risk of security breaches if you needed that info to stay secure (for whatever reasons)

For larger pieces of data, having your rezzer script llEmail() the new object with the info (using a slave script to not suffer the 20 second sleep) is very useful. Your rezzed object can set a timer going when rezzed to check for this email (afterwards this timer can be disabled) which causes no more lag than the listen trick would (if using the email slave script responsibly) and provides multitudes of benefits that the listen cannot compete with, including security of data.

-Kokiri