'Collecting' objects from someone

I was thinking of having a game where players would be able to collect various objects, and would have to turn in a particular set of objects in order to win a prize. I've been trying to decide how best to handle validating and collecting the objects a player turns in. I initially thought of using llAllowInventoryDrop(), but the problem with this is that once a user turns in the objects, I have no way of validating the objects' identities. So, my second idea is to have the user set the objects on a scripted table, where the table uses llSay to send a challenge-response to the object to identify it. Once the 'table' has authenticated a set of objects, it could send a command to the objects that would cause the objects to self-destruct via llDie(). I have to get rid of the objects somehow, otherwise a player could claim the prize over and over again. Does this sound like a reasonable strategy? Is there another way that I am not thinking of? Are there problems with my idea that I am not thinking of?

Gunzour

Hmm. I wanted to try something like this too, months ago -- I wanted to build a sword-in-the-stone themed puzzle adventure in Natoma. I didn't get to the point where I wrote a single line of code, but my plan was SOMETHING like this:

Create the objects. Give each one a unique name. Disable the "Modify" and "Copy" permissions.

Once people have "picked up" these objects, they can't modify, forge, or copy them. They do have "Resell/Give away".

To authenticate them, the player rezzes the object near an "authentication machine". The authenticator detects the object name via a sensor and listens for hte object to say a specific string on a hidden chat channel. If it passes authentication, it sends a command that makes the object die, and gives the player the prize or whatever.

Unfortunately, back when I thought of this, I had no idea how to write scripts. I don't know if any of that would work. Are there scripts that listen on all chat channels that could detect the secret key string? It's a shame that the object's creator can't be retrieved using LSL. That would help immensely here.

Why don't you just create the objects and get their UUIDs? Hard code those in to a validation script that checks all the items on a table if they match.

Are UUIDs static? i.e. if I create an object, rez it, derez it, rez it again, put it in another object, sell it, move it to another sim, upgrade to a new version of SL, etc, etc, etc, will the UUID always be the same? (I see in the docs that UUIDs are unique, but haven't found anything definative to say they are static.)

No, UUIDs aren't even close to static. Every time an object is rezzed, the UUID changes. If it crosses a sim border, the UUID changes.

So if your system includes people taking the object into their inventory, then giving it back to you later on, then UUID's won't work.

Now, as far as a new version of SL goes, if the object is rezzed in-world, never deleted/re-rezzed, and never moves out of the sim it's in, then its UUID is (theoretically) permanent. It doesn't even change if the sim is rebooted.

Ok, then I am back to my original idea, which is very close to what Cubey Terra described. I'm not worried about another object eavesdropping on a conversation on a private channel -- I can use the md5 functions to encrypt it. But it would mean I'd have to store a secret value in the object, either embedded in a script or on a notecard. Can I be reasonably certain that there is no way for someone to read that script or notecard, even if they own the object?

Another possibility you might consider is that the script could record that the player had picked up the objects as soon as they took them. Would that be possible?

Sorry to burst your bubble. Linden Labs has decided to not allow us to write or record any data in SL. You are SOL unless you can afford your own dedicated server outside of SL, along with the ability to create dedicated programs to process and receive email or XML-RPC messages to record those values.

No amount of asking has ever gotten any response out of LL about persistent data storage, so you won't be able to store information in a notecard or script, without the possiblity of losing the data.

Seems like they could charge us L$x/KB/week for persistent data storage. That would encourage economical use of their server resources and help balance the economy by providing another way for money to leave SL.

Anyway, it sounds like it's going to come to having a secret key embedded in the object, which the authentication machine also knows. Using MD5 functions, the object's identity can be proven without having to send the actual secret key over any chat channel. This seems to be the most logical way to accomplish this.

Time for me to do some coding.

Gunzoar, I recently met someone who has done somthing about 95% similar to what you are planning.

I don't want to post his name on here incase he doesn't want to share his work, but if you IM me i'l gladly give you his name as I'm sure his scripts will save you alot of work.

No, Hank, in fact they've said on several occassions that llSetNotecardLine cannot be done due to the way notecards' UUIDs work, and the reason they can't create a new database inventory item is because it would be subject to the same limitations. These and the considerable issues with attempting to set up direct database access all contribute to why they decided instead to focus their energies on implementing XML-RPC and bidirectional email.

You're correct about persistent storage not being a priority, but the reason you're unlikely to hear anything "offical" about it is because they've already said it.

All things considered:

1) Enough people already complain that we can't export/import build definitions. Not being able to export/import our DATA would be even worse.

2) Considering recent events both in-world and in the forums, I'm significantly more confident in my own database management and development skills at the moment than I am in LL's. Being able to write a query in SQL does NOT make one a database developer, any more than writing a "Hello World" app makes one a C++ developer. It certainly doesn't qualify someone as a database designer/administrator.

3) Personally, I PREFER using external data via RPC, where I can put the data in my own database server, platform of my choice, not theirs, and I can write my own data manipulation, analysis, reporting, etc.