key llGenerateUUID()

I have one project I'm actively working on, and a couple of others planned, where it would be extremely useful for me to be able to generate UUID's that aren't tied to specific in-world objects/textures/avs/etc.

I realize that I can use llFloor(llFrand(2000000000)) for similar transactional identity generation, but that is two function calls, (plus an addition operation if I want to guarantee 10 digits). It also has a higher possibility of generating duplicate id's, although highly unlikely.

duplicates are duplicates. even a low chance of them leaves the risk of retrieving the wrong data and making possibly a very costly mistake.

it would be very useful to have a function that would generate an absolutely guaranteed unique key value.

Is that an endorsement?

yes, now how does it go, i fully endorse and highly recommend this most excellent feature suggestion forthwith.

How would they guarantee that the keys are unique? Right now, they know they are unique because each one generated exists in a database. They would have to keep and access every single key someone generates with that function.

(Or else someone could write a unending loop with that call in it and eventually use up all the keys... Many copies of the script would help.)

If there were limitations on how long they were guaranteed unique, it might work. Say, one week or so.

Personally, I'd love to have a hash function that takes a list of data items and returns a non-unique, but repeatable, integer for them. One can be made in LSL, but it would be much slower and CPU-intensive than a similar function in the server C code.

integer llHash( integer lowend, interger highend, list data )

For any given list of items, returns the same hash index integer between lowend and highend, inclusive.

(Or call it llCornedBeef )

This has the possibility of someone flooding the DB (because, for it to be random, it would also need to make sure that no one ever created an object in the FUTURE with that ID, so it'd have to be stored in a DB). Anyway, unless there's some kind of major dampening on this, it sounds like it may be used as a greifing tool (Bad Thing).

You guys do realize that the whole point to a UUID is that there are 3.4028236692093846346337460743177e+38 possible values, right?

For those who don't read scientific notation, thats more than three followed by 38 zeros!

340282366920938463463374607431770000000 possible UUIDs. Give or take a few million.

Somehow I'm fairly confident that the odds of someone deliberately "using them all up" is infinitesimal.

Oh, and to answer Tiger's question:

UUIDs are normally generated based on a) the MAC address of the NIC in the computer that generates the UUID, b) the number of ticks (milliseconds) from a specific point in time until the time that the UUID is generated, and c) a minor sequential or randomly generated portion that the generation engine uses to ensure that two UUIDs generated at exactly the same time on the same machine aren't identical.

Not only do UUIDs not need to be stored in a database to guarantee uniqueness, major database applications actually require the use of UUIDs to guarantee that otherwise identical rows on two separate databases have at least one piece of information that can be used to uniquely identify the row.

It's not "using them all up" that bothers me. That's pretty much out of the question. It's the tremendous database "hit" that would make if someone wanted to greif.

So don't store them in the database. My point was that there's no need to do so. Just have the function set up so that the sim that it executes in is responsible for generating the requested UUID, and let the UUID generation methodology handle the uniqueness problem.

The MAC address portion of the algorithm ensures that no two sims can/will generate identical numbers, and the ticks portion makes it pointless to worry about possible conflict between two that are generated as much as 100 milliseconds apart.

The only way there could possibly be the least risk is if two scripts request UUIDs during the same 100 millisecond time interval. Which is why the sequential/random portion of the UUID exists. (Hint, if all of the possible sequential numbers were used within a particular time block, delay the script 0.1 seconds until you're in a new time block.

There's no more risk of this methodology being abused to bring down a sim than there is with listeners/scanners/rezzers/etc

Ah, ok. Fair enough then