32bit Hash Question

I'll make it short.

http://wiki.secondlife.com/wiki/32bit_Hash

I noticed it simply cuts out the first 8 characters, so I'm wondering what the chances of overlap are if it's fed llGetOwner(). Will it be alright for generating a communications channel between different attachments?

If anyone has a better way to set that up, I would also appreciate the input.

UUIDs, IIRC, aren't really random but they're close enough to it that collisions should be pretty rare.

The listen event will tell you the key of who did the chat. As long as you check that the llGetOwner of that key is the same as your owner, I think you'll be fine.

I want to avoid making a Owner Key check because the intended use will likely have a number of people near each other. I'm hoping its somewhat less hard on the sim to set a avatar-specific filter (obviously not the avatar itself but their attachments) rather than checking everyone's keys all the time.

EDIT: The lag concern is that the main function is a Combat System actively updating a HUD attachment, which means messages will be flying out quite frequently as it is, so having to filter by checking Owner Key rather than channel adds up with many people within 10 meters.

EDIT 2: A feature request I'd love to see: llMessageAttached, basically working like MessageLinked but instead of messaging the object itself you can target all of the target agent's attachments or a specific attachment point... (Obviously it fires a new attachment_message event.)

I don't think doing an owner check would cause much lag - the sim certainly knows all that info already - but if you really don't want to do it, I wouldn't worry much about it.

If you're really curious, script up an attachment that scans avatars near you and keeps a list of their UUID and hash code. Any time you spot a new avatar, search the list to see if there's a matching hash in there. I'd bet that you'll run out of script memory before finding two avatars with the same first-32-bits..


Yep. And a version of llListen where you can tell it to only trigger on objects owned by a certain avatar..

Alright, thank you very much. =)
I'll use the Hash then.

Just because I'm tired of doing what I'm supposed to be doing (ie: work) I found one of the key2name databases on the web and downloaded it.

Whipped up a little C# to suck the whole thing in and look for duplicates on the first 32 bits of the UUIDs. Of the 3,054,168 UUIDs in there, a total of 1,095 had matching values on the start of their keys. So.. It is possible to get collisions if you just use the start of the key but it's not very likely.

You might be able to put the owner into the chat messages or something like that but the extra cost of doing that is probably a net loss vs checking the owner id.

Alright. Thank you again. =)

I'll probably add in an Owner Key check to messages matching the channel as a failsafe. Combining both (Channel generate at state_entry) should still be a gain over straight Owner Key checking all received messages on a shared channel right?

EDIT: In hindsight I probably *AM* over predicting the effort checking the keys (1 per second per av within 10m) is... Sorry to be a pain over something trivial.

Notice that Key2Integer return the first 8 bytes of the MD5 of the key, not of the key itself. I haven't done the maths, but I would expect there to almost no collisions at all.

But that may be irrelevant. I am actually quite confident that filtering llListen by key is just as efficient as filtering by channel.

You could, of course, filter by both (in the llListen call - not in the listen event)

Heh.. I didn't spend more than a few seconds looking at the OPs wiki link - I just assumed it was yanking off the first 8 characters of the owner key.

Er.. Ignore everything I said in the previous posts.

Well, its not filtering by Avatar, it needs to receive messages from that Avatar's Attachments, so I can't use a direct key filter.

Which is why I'm looking at generating a communications channel based on the Owner's UUID so that the listen event doesn't have to check the speaking object's owner against it's owner for every message received.

But as I mentioned before that's probably far less work than I think it is, even with alot of messages flying around to each person's HUD on a shared channel.

Note that MD5 (and any other cryptographic hash algorithm for that matter) is designed so that even a 1-bit (small) change in the input SHOULD produce significant changes in the output (i.e. even the most significant bits of the result should be affected). So it SHOULD be reasonable to use any subset of the result.

Often I use an XOR of each 32-bit subset myself just for peace of mind though. A couple extra string and arithmetic operations aren't likely to hurt much, especially if the computation is performed infrequently. For example (thrown together without compilation; consider it pseudo-code):

integer hashStringToInteger(string str)
{
   string hash = llMD5String(str, 0);
   integer n1 = (integer)("0x"+llGetSubString(hash, 0, 7));
   integer n2 = (integer)("0x"+llGetSubString(hash, 8, 15));
   integer n3 = (integer)("0x"+llGetSubString(hash, 16, 23));
   integer n4 = (integer)("0x"+llGetSubString(hash, 24, 31));
   return n1^n2^n3^n4;
}

Ah, that idea there had not occurred to me. Thank you very much Hewee.

And thank you Sindy/Ben for your input. Question answered.