Update Scripts Remotely

I was wondering if someone, anyone could help me out. I am looking for a way to update scripts in my items remotely. Most of my items so far have been copyable items, so just writing an update script that drops a new version copy to the end user has been sufficient. Recently though I've made some things that I'd love to be able to update the scripts in.

To summarize what I've found so far, I've really found 2 ways to do updates:

1. Have the script contact a static object UUID or call a remote PHP script that connects to a SQL database that stores object UUIDs/names. If the update is newer, have the object send an updated item to the user. (What I'm currently doing, works great for copyable items).
2. Do the same as above, but deliver an object that on rez uses llRemoteLoadScriptPin to update the scripts in your no-copy item. The problem with this, is it requires the user to rez an object.

I know there are several objects in world right now, that are wearable objects. You rez them, they check for updates. If there are updates, they update and that's it. No inventory offers, and works in any SIM. 2 examples are Lola's teleport rezzer, and MysticTool. Could anyone give me any insight? I've looked through LSL wiki for days, and searched for a week .

Very much appreciated. <3 you guys out there in the SL community. Happy Holidays to all of you !

1 yes you can
2 yes you can

which is up to you, keeping a website up as long as a uuid is actually trickier than one might think but keeping log data in a prim is impossible after a point

either way once you determine the upgrade auth method you need llGiveInventory or maby llGiveInventoryList

and either a trigger in the existing script to turn on the new script and delete the old

or

a pin number to do all that from the giver object (server)

http://cheesefactory.us/lslwm/inventory.htm

Thanks for the reply Osgeld. I really appreciate you taking your time to write that . I wanted to raise a few points though.

The end result of what I'd want to do is update script remotely, without being on the same SIM, without delivering a new copy of the object, and without having to rez an object to update it.

So you are saying deliver the updated scripts using llGiveInventory or llGiveInventoryList, but doesn't those require the destination to be in the same SIM (for objects)? I'm just going by LSL Wiki, but if they don't, then that'd be perfect. .

Thanks again for your post !!

I do this on a regular basis by replacing the whole object, not just the script. That way the owner doesn't have to install script.
The script has a model number.
A "warehouse" object in SL has the latest model (script + object) in inventory.
This "warehouse" is the only place you have to update with changes.
You need a website with data storage and processing ability.

The object to be updated checks in with a central data base by http access, as often as necessary for your application, and submits its model number, and the Key of the current owner. If that number is less than the current model number, two things happen.

1. The central data base issues a command to the warehouse in SL by XML-RPC to GiveInventory to the Key. This is not restricted by location of the warehouse or recipient.

2. The central data base responds to the old object letting it know that it is now out of date. That causes it to tell the owner that it has expired and will be replaced by a new one being delivered to their inventory. It then does an llDie() (complete with a nice particle and audio explosion in my case).

If it is copyable and they have another copy in inventory, using that one will only repeat the process or it could be ignored if your central data base keeps renewal records.

The interesting trick with llRemoteLoadScriptPin comes when you realise that:

- If object A recieves an object via llGiveInventory, the script arrives in stopped condition, but it can load the script into another object B via llRemoteLoadScriptPin, and the script will run.
- In the above case, it is entirely legal for Object A and Object B to be members of the same linkset.

This enables a "silent update" but only within the same sim, which would work as follows:

1) A child prim of the object does an llRegionSay announcing the current version number.
2) If the server in the sim detects that the version number is too low, it says there's an update ready.
3) Finding out that there is an update ready, the child prim turns on llAllowInventoryDrop.
4) The server gives the script to the child prim via llGiveInventory. This is permitted by the llAllowInventoryDrop and because it is an object to object transfer, no dialog is presented for the user. The script will not start running within the child prim but that is intended.
5) The child prim turns off llAllowInventoryDrop and loads the scripts into the root prim with llRemoteLoadScriptPin. Since the child and root prim have the same owner there is no probem doing this.

The only issue with this is that llGiveInventory only works between objects if they are in the same sim. I do not know how objects get around this. My guesses would be:

a) They have a central server which rezzes an updater object and flies it out to you via a hyperteleport script - there are still hyperteleport scripts available open source so this is probably easier than it sounds. However it would make it impossible for the updates to work on private islands.

b) The makers of these products have sufficient influence that they can arrange for an update server to be "hidden" on every sim, or at least most sims. The only problem with this theory is that updating the _servers_ would be a nightmare.

c) It's being done using bots. Under normal circumstances in SL it is impossible for an avatar to give something to an object in another sim, but this is only a limit imposed by the user interface (you have to click on the object), and therefore one that might be breakable by a bot that does not have to use the user interface. The problem is that I do not know for sure that this is the case.

If you mean Mystitool, that's not true. Mystitool sends you a new version of the tool. You need to back up your current one, wear the new one, and restore it from the backup object.

Doesn't this create a security hole? Someone else could give a malicious script, with the same name, which would be accepted. There would be a 50/50 chance that the wrong script would get the intended name and be activated. Granted, it's a very small window of opportunity, but the potential damage by a malicious script is so great that any window is unacceptable.

You would need to check the scripts with llGetInventoryCreator() or other security techniques first, of course.

which still isn't 100% protection, if you've ever written a script that was open mod, since even completely edited to insert entirely different code, it still lists you as the creator...

you could include an abort if it detects more or different scripts than it expects... for example if it detects 'script' and 'script 1', rather than guess which is which it aborts with a warning... it could also incorporate an e-mail to know which scripts names to expect, but would need to included authentication in the e-mail to be assured it's getting the list from the update server and not from another source