Unique Addresses

[agentronin]

There will be several attached objects to an avatar, each with one identical script, and communicating to one HUD. To communicate between HUD and the other attachments on only one channel, I need to come up with a scheme of automatically created addresses, such that each script will act only on messages it sees is addressed to itself. I am exploring the use of using the UUID of the object the script resides in to create a script's. I would like not to use the entire UUID for it is very long. What minimum amount of characters from the UUID would mean zero chance of more than one script having the same address? My interest is not in negligible chance, rather, it is in no chance.

[Lucia Nightfire]

Each attachment already has their own UUID.

Why not use that?

[KT Kingsley]

Maybe have a look at Mollymews's UUID pack/unpack functions in the LSL Library forum. It packs a UUID into a nine character string.

 

[KT Kingsley]

Note that even UUIDs don't have an absolute zero chance of duplication; just a very, very negligible one. For a true zero chance you may have to look at the HUD generating an incrementing number that it passes to each new object when it's attached.

[bobsknief Orsini]

4 hours ago, agentronin said:

There will be several attached objects to an avatar, each with one identical script, and communicating to one HUD. To communicate between HUD and the other attachments on only one channel, I need to come up with a scheme of automatically created addresses, such that each script will act only on messages it sees is addressed to itself. I am exploring the use of using the UUID of the object the script resides in to create a script's. I would like not to use the entire UUID for it is very long. What minimum amount of characters from the UUID would mean zero chance of more than one script having the same address? My interest is not in negligible chance, rather, it is in no chance.

Its a little unclear on what you are trying to do. You could for example use a timestamp.

[Mollymews]

8 hours ago, agentronin said:

My interest is not in negligible chance, rather, it is in no chance.

when objects are rezzed inworld then they acquire a new uuid. So is best not to rely on the uuid value for this purpose

is a number of ways to do this

one way is validating the sender with OBJECT_OWNER + OBJECT_CREATOR

and further include a unique application token in the message

example:

string APP_TOKEN = "@";

listen(integer channel, string name, key id, string message)
{

   list sender = llGetObjectDetails(id, [OBJECT_OWNER, OBJECT_CREATOR]);

   integer check = (
    (llList2Key(sender, 0) == llGetOwner()) &
    (llList2Key(sender, 1) == llGetCreator()) &
        (llChar(message, 0) == APP_TOKEN)
   );

   if (check)
   {
      ... here we can parse the message down further ...
      ... for example the second llChar of message could be the object token
      ...   identifying it uniquely from other app objects


   }
}

another way is when app object are no-modify. We can use unique object names rather than encoding message tokens

 

[Innula Zenovka]

You can identify particular object meshes (rather than instances of them) with llList2String(llGetObjectDetails(id,[OBJECT_CREATION_TIME]),0).     So something like this might be helpful

string strMcGuffinCreationTime;
integer iMcGuffinChannel;
default
{
	state_entry()
	{


	}

	listen(integer channel, string name, key id, string message){
		string strTimestamp = llList2String(llGetObjectDetails(id,[OBJECT_CREATION_TIME]),0);
		if(llList2String(llGetObjectDetails(id,[OBJECT_CREATION_TIME]),0)==strMcGuffinCreationTime){
			//then the message is from a McGuffin of some sort
			if(llGetOwnerKey(id) == llGetOwner()){
					//then it's from a McGuffin belonging to my owner.
			}
		}
	}
}

Also, since any object you're wearing (or sitting on), and only those objects, will receive messages sent via llRegionSayTo, you can be pretty sure that llRegionSayTo(id, McGuffinChannel, message) will reach only the McGuffin that id is wearing, and no one else's.     

 

[agentronin]

How are UUIDs created? What are they used for? What potential consequence would there be to a user if it just so happened that two attachments end up with the same UUID?

[Quistess Alpha]

8 minutes ago, agentronin said:

How are UUIDs created? What are they used for? What potential consequence would there be to a user if it just so happened that two attachments end up with the same UUID?

http://wiki.secondlife.com/wiki/UUID

• Random number generator,
• a lot of different and somewhat unrelated things,
• It's statistically impossible for that to happen, but if it did, I expect either one object would turn into the other object, or perhaps SL would be smart enough to detect the collision at object creation and just assign the new one a different UUID.

[Mollymews]

i have no idea how Linden actually create UUIDs but I think they probably use a non-collision method. Like some kind of feistel network to convert a value drawn from a sequential sequence to a 'random' looking  value

pcode example:
 

uint128 i;

key id = feistel(i);
++i;
if (i == power(2, 128))
   i = 0;

wikipedia link for feistel network here:   https://en.wikipedia.org/wiki/Feistel_cipher

is pretty interesting when apply this method to a sequence, as is reversible.  for example:
 

for (i = 0 to 9)
{
    // feistel(value, magnitude)
    u = feistel(i, 100);
    n = unfeistel(u, 100);

    // u == unique value in range [0..99]
    // n == i;
}

/*

i = 0. u = 57. n = 0
i = 1. u = 82. n = 1
i = 2. u = 14. n = 2
and so on

so given some 'random' number in [0..99] we can know if this could have been generated by our program

*/

if (unfeistel(u, 100) >= i) then 'u' isn't in our current range