data severs

Hello everyone, I am trying to make a update script so I can update the guns that I have made, that people have bought, I have gone though Wiki and I think I thought of a way to do it can you guys tell me if this will work or is possible? If I combine the data server function and llGetInventoryName to get the name of an object and then use llGiveInventory to give the person the new object, thanks for the help in advance.

I'm actually working on an update server system at the moment. Your demands can vary based on what your object permissions are and how widespread your distribution is.

If you've got transferrable items, for example, you need either a) a data-storing solution to ensure people don't update twice, or b) (and this is simpler) a system to deactivate the item you're updating before issuing an update. This is to keep people from exploiting updates by giving away old copies.

If you've got copiable items, however, you don't need these precautions.

Also, the stability of your land situation plays a role in this. Do you have somewhere you can reliably set and lock down a server? Because if you put update scripts in your items pointing to an email-based "server", and that server gets de-rezzed for any reason, your update scripts will be useless from then on, as they will point to an object key that no longer exists.

An update server is something that is going to be very particular to your needs. I'd start by asking the following questions:
1) Are my objects copiable? Do I need to include measures to ensure only one upgrade per version number?
2) How often will I update?
3) Do I want clients to come to the shop, or be able to update from anywhere?
4) Do I want this process to be automated, or do I wish users to trigger it?
5) How important is security to me?

Give some of this info, and I can help you work out a solution that's good for you.

What I do for my clients is put a listening pseudo-server on my property, and ask them to come there to update. My products have an update command, and the product shouts on a high random private channel a string consisting of its version number, its name, and its owner key. The server then gives them an auto-installer that overwrites the relevant scripts in their existing product. But that's very specific to my needs.

Overall, I think you're going to want to study up on scripts that read notecards and the email system in SL; these, combined with data storage ideas, are going to be your best server friends.

ok let me give you the info
1) Are my objects copiable? Do I need to include measures to ensure only one upgrade per version number? they are no mod/no transfer
2) How often will I update? not that often like once a month
3) Do I want clients to come to the shop, or be able to update from anywhere?anywhere
4) Do I want this process to be automated, or do I wish users to trigger it? as soon and they attach the gun i want it to check for an update
this is from a server in my office on my groups land

For something that is no trans and rezzed when used, like a car or your gun, have it send an email with info when rezzed. (you can use timestamp to compare dates and limit the request to once a day or other methods to keep the request low.)

A safe way is to send the email outside of SL to a stable address then just forward it back into SL to your parsing system, so if you have to rerez your parser you can just change the forward addy.

The info that the object sends should contain; the object name, the object version number. the owners key.

Send the string something like: ||super gun||1.8||ownersKeyHere

Turn the recieved email into a list. The first item on the list will be the (useless)email header junk that you can ignore.

Then it's just a matter of checking the requesting objects version to the current version, if it's been updated send the new object to the owners key.

That's more or less how i do it anyway

Jesus, mate... it never friggin' occured to me to send the email off-world. Seriously, never. All this agonizing over how to deal with the great fear of derezzed servers, and the solution all along was right in front of my pixellated face.

Do remember, however, not to simply add the llEmail line to the on_rez event of your existing gun's code. The llEmail function delays the script for 20 seconds, so if you do that, the gun will be non-functional on rez for a few moments. It's best to include a separate script somewhere in the the gun that will email either on rez or on attach.

I'd have to say you're better off putting it in the attach state, as you mentioned, and not in the on_rez state. The on_rez state is triggered, if I recall, by teleports and logins and what-not, so you're likely to get fewer requests sent with attach.

Les is right, though. Even if you plan to do the update check as an attach event, you're going to want to use a timestamp to limit the number of requests (depending, of course, on how popular your gun is); otherwise, your server is going to be running functions every time someone attaches a weapon.

Since you're doing this as a hidden function (in this case, I mean that the user doesn't actively trigger the ), you can space out your email checking timer events quite a bit. Checking email is not a huge server draw, but cutting lag is always a good thing, particularly when you're talking about something that is a constant feature on your land.

To keep from editing the update script with every new update, you could put the current version number in the description of your object, so that your list would look something like ||super gun||llGetObjectDesc()||llGetOwner() . Then you can just put the 1.8 in the description field, and never have to open up that update script again. It's also helpful when providing support to be able to tell a customer to check the description and let you know what version they're using (if you don't stick the version number in the title, that is). But maybe I'm just lazy. Do remember to convert that part of the listed string to a float however, or you'll tear entire clumps of hair out wondering why your server isn't picking up on the current/new version number comparison before figuring out what you've done.