|
Apryl Beaumont
Registered User
Join date: 10 Apr 2007
Posts: 5
|
05-17-2007 13:38
Please pardon another likely-to-be simple question from a relative newcomer to both SL and this kind of scripting.
On a product I've been designing, I encountered a problem in that I needed an object to whisper something on a channel (not the main channel) when an avatar attaches or detaches it (so another non-linked object can adjust itself accordingly), but when I tried using the built-in functions for owner IDs, it only generated the correct ID whenever the item was attached; when it was detached it kept generating a different ID number every time, none of which called back to the owner when I tried an llKey2Name. The solution I developed was to append the owner's ID to the message being sent, and to llGetSubString both the original message and the ID.
This is all background, however, for the bigger question I have, which is whether or not avatar IDs are something that should be being broadcast like this, even in hidden-away channels. To my knowledge, anyone who wanted to get an avatar's ID could easily develop a scripted, worn prim that just used the collision-detection functions to get IDs and then run into people wearing the prim. However, I'm worried that by broadcasting IDs like this, I could be making it easier for someone to potentially steal avatar IDs for the purpose of developing malicious code.
Basically what I need to know is whether the solution I developed to the problem I detailed above is safe and considered acceptable, or if broadcasting an avatar ID in a hidden channel is too risky. Thanks!
Apryl
|
|
Talarus Luan
Ancient Archaean Dragon
Join date: 18 Mar 2006
Posts: 4,831
|
05-17-2007 14:09
Avatar UUIDs/keys are public knowledge, easily obtainable by any number of methods at will by anyone. There's nothing wrong or illegal about acquiring, possesing, or publishing them.
When you detach an attachment, the key that is passed is NULL_KEY, and cannot be converted to a name via llKey2Name(). However, since only the owner of an attachment can attach it, you can always safely assume that the person detaching it is the same one that llGetOwner() returns.
|
|
Apryl Beaumont
Registered User
Join date: 10 Apr 2007
Posts: 5
|
05-19-2007 18:14
Thank you, Talarus. My problem with using llGetOwner is that if both I and someone else are using/have on the same object, anything I do to my object seems to happen to the other person's object as well. There's probably an easier way around this problem, but for now I think I'm going to stick with what I've got.  Apryl
|
|
Talarus Luan
Ancient Archaean Dragon
Join date: 18 Mar 2006
Posts: 4,831
|
05-19-2007 18:17
Sounds like a bug in the design of the code, which sounds eminently fixable, but if you're happy with what you have, that's cool. 
|
|
Newgate Ludd
Out of Chesse Error
Join date: 8 Apr 2005
Posts: 2,103
|
05-20-2007 07:20
From: Apryl Beaumont Thank you, Talarus. My problem with using llGetOwner is that if both I and someone else are using/have on the same object, anything I do to my object seems to happen to the other person's object as well. There's probably an easier way around this problem, but for now I think I'm going to stick with what I've got.  Apryl The most likely casue is that you set up your listen in state_entry and then gave it to someone else. The state_entry event will fire when teh state is first entered, it is not fired on subsequent rezzes of teh object. Add an on_rez event like so :- on_rez(integer num) { llResetScript(); }
or look at the changed event.
_____________________
I'm back......
|