Applying Unique "Serial Numbers" to a Product

Hi all,

I am scripting a custom vendor to distribute products and one of the things that I need to do is "apply" a serial number to each product sold. (An external database is used to generate and record serial numbers - they are used for sales tracking and customer-service/technical-support down the road.)

So somebody buys a product called "Object1" which is in the contents of the Vendor. The vendor then contacts the external database to determine the unique serial number. Now I need to get a copy of "Object1" to the buyer with that unique serial number "applied" to it.

I've thought of a couple of different ways that it might be done, but I'm not overly happy about any of my ways to do it - I can see potential down sides to all the different processes. I do think that the best way to apply the serial number is to put it in the Description Field of the object (but I may be wrong on that - maybe rewriting a NoteCard contained in "Object1" would be better?) And the serial number really does need to be a string (meaning that using the integer parameter passed in an on_rez event won't really work for me - which would have been golden!)

I'm hoping that some of you may have fresh ideas as to a good way to do this. So how would you solve this problem:

"Vendor" has "Object1" in it's contents,
"Vendor" has "Serial Number" stored as a string in it's script,
"Vendor" needs to give a copy of "Object1" that is "stamped" with the "Serial Number" to a "User"

I appreciate any and all advice!

storing in the description field would amke it visible to anyone, and editiable by the owner if the object is mod.

You cannot write a note card using LSL so taht is a non starter.

You can still use the integer passed by on rez to set up a communications channel between the object and the vendor and then pass the serial number into it that way. The problem would be if the script in the object is reset it will loose its serial number.

Seems to me you could have the product negotiate with the vendor on-rez via email for the serial #, and store it in the description of the object.. and as for script resetting and any other possible reasons a new serial might be generated, just ship the product with "Unregistered" stored in the description.. and check for that in your script.

on rez
{
...if llGetObjectDesc() == "Unregistered"
......email conversation with vendor that gets unique serial
......llSetObjectDesc(myUniqueSerial)
......email vendor that serial is accepted and stored
}

As Newgate points out, the object would need to be no-mod for this to be reliable. You have precious few options for persistent storage in lsl, to be sure. Oh, and be sure to build in some sort of confirmation that the product has accepted and stored the new serial, the off-world server shouldn't just assume that just because one was asked for, it was used.

Just a rough idea, after only one cup of coffee

taking this one-step further, if you use an encrypted key of some sort for your serial number in the description field, you can have your script automatically check to see if the listed key is valid; if it's not valid, the script could then retrieve the correct serial number for that user from the data-base

Thanks for the feedback everyone. A few points:

- the object is no-mod/no-copy, so I don't think storing it in the name or description field should be too worrysome. They shouldn't be able to edit it from there, and having them be able to just "see" it isn't that big of a deal.

- how reliable are communications that need to be done quickly? for example, how can I be sure that, after rezzing the object, the Vendor-to-Object communication is completed and the serial number stored before the purchaser takes the object into their inventory. I don't want the object to go out without that serial number

- the idea of having a confirmation back to the server that the serial number has been accepted is fantastic - thanks for that Zaphod!

- the use of an encryted key is also a great idea - thanks Senuka!

For the most part, chat communications between objects is very fast (no hard numbers, but I'd guestimate it at about 0.2 seconds). But, if there's a lag spike in the sim when these communications are occuring, there can be delays as long as 15 seconds. For something as important as a serial number, I would have the object communicate with the owner when it's finished recieving it's serial number so that they will know when it's safe to take the object back.

You could hard code the object to not work without the serial number. If it somehow gets away without one it will just give a message "please return to place of purchase for Serial Number assignation" or something like that.

This is one of the options that I thought of and am considering. One of the difficulties I foresee though is then automating the process of obtaining the correct serial number from the database. It may be just as difficult a process as trying to ensure the object doesn't get created without a serial number in the first place.

But it may still be the best option.

This is the biggest problem that I foresee with using any type of chat communication between the two.

Just thought of another idea right now - anyone think this might have merit and is worth exploring?

It seems that one object can give another object out of it's inventory to a third object, which then takes that into it's inventory.

What do you think about creating a "Serial Number Applicator" machine that sits right beside the "Vendor" (or is possibly connected as a linked child prim?) Then once the item is purchased, the "Vendor" gives a copy of the "Object" to the "Serial Number Applicator" machine. The "Serial Number Applicator" just sits there waiting for an "Object" to be added to it's inventory.

Using the "changed" event, the "Serial Number Applicator" jumps to life, recognizes the new "Object" it has been handed, contacts the external database to generate the serial number, records that serial number in the "Object" description field, then gives the actual "Object" (not a copy of it) to the purchaser.

This seems like it may be a more linear process that can't be interrupted as easily (like the chat communications can be by sim lag) and it has the added bonus of giving the item directly to the purchaser, so it goes directly to their inventory with the serial number already on it, avoiding the need to rez the object and rely on any on_rez or object_rez events and communications.

Good idea? Bad idea? Any input of what concerns might arise in a process like this?

Sounds like a good solution to me. I don't have any experience with such a process so I cannot think of any problems that might arise from this kind of method.

Wont work. There is nothing the "applicator" machine can do which the vendor object cannot do itself (and vice versa.) It just "moves" the problem from one object to another without actually solving anything.

-peekay

Yeah, after a couple of hours of trying to figure it out, I came to that same conclusion! Oh well!

You could always set the object as no copy, and have a script in it to assign a serial # (using something like the object's ID on that first rez might be ok or you can use another identifier).

The 'serial number' could be applied as the description, and then the script could communicate to your server with the name, etc, whatever it is you're wanting to keep track of in the database. Then the script could just delete itself from inventory.

You could have it set so that they are informed that they will need to rez the object to in a sense 'register' it prior to use.