Question about Experience (attaching HUD) - logic question

[Xander Lopez]

I have been doing some researches on implementing EXPERIENCE to let visitors wear HUD automatically, and detach HUD upon leaving my sim. (assuming that they grant experience permission) I am trying to get the logic written down first so I know where I am heading toward to...

should I be constantly scanning the entire sim to see who is arriving to the sim so I can get their uuid and request the m to attach HUD? or is there better way to achieve this? how would you approach this concept?

[Qie Niangao]

1 hour ago, Xander Lopez said:

should I be constantly scanning the entire sim to see who is arriving to the sim so I can get their uuid and request the m to attach HUD? 

I've certainly done it that way, using llGetAgentList() for the whole region or for a specific parcel or a landowner's parcels. I try to keep that timer loop fairly loose, like 15 seconds or more, and keep list-handling code as efficient as possible because the script must do so much of it. Might be nice to have one canonical example of this kind of code that gets reviewed as an easy starting point.

If you're really only interested in those who arrive at a very specific location (or if the land has everybody teleport-routed through a particular location) then I'd replace that timer-triggered scan with avatar collision_start events from an object with llVolumeDetect() set.

[Xiija]

Logic flow would be something like...

1. dispenser checks the sim for new arrivals with a timer.

2. dispenser uses the llRrezObject event, and passes the newly arrived Avatar's   ID to the rezz'd item as a start parameter.

3. rezzed item gets the new avatar's id from it's on_rez event.

4. rezzed item asks for  llRequestExperiencePermissions  to the avatar,  and uses attachToAvatarTemp... and on detach it dies?

 

Edited November 23, 2020 by Xiija

[Qie Niangao]

21 hours ago, Xiija said:

2. dispenser uses the llRrezObject event, and passes the newly arrived Avatar's   ID to the rezz'd item as a start parameter.

It's gonna be a little more complicated than that, right? A start parameter is an integer and an agent's UUID is a lot bigger than that. Most scripts probably pass a channel number on which to send the agent UUID to a listener in the rezzed object, but sometimes I instead simply hash the UUID down to an integer for passing in that start parameter, realizing there's some (extremely remote) possibility of hash collision.

(I think doing it with a listener needs two-way chat because freshly rezzed objects sometimes take a while to collect their wits after the rezzer gets its object_rez message, especially recently.)

[Wulfie Reanimator]

14 minutes ago, Qie Niangao said:

It's gonna be a little more complicated than that, right? A start parameter is an integer and an agent's UUID is a lot bigger than that. Most scripts probably pass a channel number on which to send the agent UUID to a listener in the rezzed object, but sometimes I instead simply hash the UUID down to an integer for passing in that start parameter, realizing there's some (extremely remote) possibility of hash collision.

(I think doing it with a listener needs two-way chat because freshly rezzed objects sometimes take a while to collect their wits after the rezzer gets its object_rez message, especially recently.)

In almost all cases (I would say all, but there can technically be exceptions), the first part (8 characters, equal to 32-bit integer) of a UUID is unique enough to identify any avatar in the region. What you can do is include that first part of the target avatar's key as the start parameter, then the rezzed object uses llGetAgentList to look for an avatar whose key matches the start parameter. Easy enough.

integer param = (integer)("0x" + (string)llGetOwner());

My key (779e1d56-5500-4e22-940a-cd7b5adddbe0) produces 2006850902.

Edited November 24, 2020 by Wulfie Reanimator

[Xiija]

Both good points, ty

( i also use a channel as the start param )

[Mollymews]

adding to the conversation

with 32 bit integer we can extend the collision window out to 62 bits by using 31 bits as the identifier and the 32nd bit as a flag

bit flag = 0 = use first 31 bits of agent uuid
bit flag = 1 = if first 31 bits are already used then use last 32-1 bits of agent uuid

example

string agent_uuid = (string)llGetOwner();
 
integer encoded_is_already_used = TRUE;  // toggle this TRUE|FALSE to see that we are good on both flags for agent owner
                                         // this would be the result of a look up function
             
// encode
integer encoded = (integer)("0x" + agent_uuid) & 0xFFFFFFFE; // sets the low bit flag to 0
if (encoded_is_already_used)
   encoded = ((integer)("0x" + llGetSubString(agent_uuid, -8, -1)) & 0xFFFFFFFE) | 1;  // set the low bit flag to 1

// ... llRezObject(..., encoded) ...;

// decode
string owner_uuid = (string)llGetOwner();
integer decoded;
integer flag = encoded & 1;  // get flag bit value
if (flag) // last 32-1 bits of agent uuid
   decoded = ((integer)("0x" + llGetSubString(owner_uuid, -8, -1)) & 0xFFFFFFFE) | 1;    
else // high 31 bits of agent uuid
   decoded = (integer)("0x" + owner_uuid) & 0xFFFFFFFE;

// check
if (decoded == encoded)
  llOwnerSay("we are good: " + (string)decoded);        
else
  llOwnerSay("we are not good.");

is probably over kill in this particular use case, however is a method that can be useful sometimes. It can be extended also. Like a 2 bit flag gives 4 * 30 bits = 120 bit collision window. 3 bit flag gives 8 * 29 bits = 232 bit collision window