Distributed updates for a system - whats the most common approach???

How do people normally handle distributed updates for their systems to others (i.e. who have purchased and host teh system/game). For example (guessing here) do people create scripts/approach like:

1. package updated scripts (no mod) + script updater into an object + note_card with matrix of script-to-object_names (i.e. knowledge of which objects in the system which scripts reside in, perhaps in the case where there is a common script in an object with lots of linked prims [e.g. display] indicate this to use a different approach here?)
   
2. give object to system owner
   
3. they run the script updater which then:
   
4. - uses a SENSOR approach to find UUID for the rezzed system objects
   
5. - uses llRemoteLoadScriptPin to update scripts in the objects (or perhaps another approach for when a new script is required to be trickled through a large set of linked objects like an xytext display?)
   
6. - ensure scripts/system is restarted, using "llResetOtherScript" / "llSetScriptState". Ummm I'm not even sure what the best approach is here , may depend on nature of changes to system. Is having a system "full restart" function which the update script can trigger the best perhaps?
   

Regards
Greg



PS I've broken this out into a specific thread from /54/53/89964/1.html

Well, I'm currently busy writing a script that checks for updates daily.. I have multiple update servers with the keys hardcoded in the clients. When one update server goes offline (key changes) the script will automaticly try the next update server in the list..
I was planning on giving the script to the object if there's an update but I found that llGiveInventory only works when two objects are in the same sim, So I think I'm just gonna give the update to the owner.. The updated script will then check (when dropped in the prim) if there is an old version of the script (haven't decided how yet). And if so, delete that version and start running. If there is no older version it will refuse to run since it's an update, not the retail version.. This stops people from running this and the older version of the script, or from resetting the other script and receiving and using more then one update..

I believe the most common approach is to have the update script send an email to an update server (perhaps selected randomly from a list of different servers) every ~4 hours. The email contains some special code or password proving that it's a valid object, and the key of the owner. The update server then checks the email, and if it's all valid, it sends the updated version of the object to the specified user.

I think actually going through and updating the scripts is somewhat rare -- it's easier to just have them rez the newer copy of the object.

I'm actually interesting in leverages the approach to cover (a) script updates to a production system but perhaps even more useful (b) assist a developer distribute script updates as he is developing. This is noting that an individual script (e.g. comms) can be present present in multiple objects (and mulitple prims within an linked object - e.g. displays can many prims).

For example, just update/recompile all your scripts in a distributer object, then trigger the object to update your system under-development (which may be a llRemoteLoadScriptPin update to 1 or 30 prims depending on which one it is). Would be definitely a timesaver for me.

I'm here cause you asked me this question in another thread. In the past, especially for Settlers, my biggest project, my update method simply consisted of taking back the old board from my customer and giving them a new one. I tested the hell out of Settlers the first time around, and if I remember correctly, we only found one or two bugs after the initial release. I did a total of two subsequent upgrades, which added a ton of features everyone was clamoring for, and since hten, I haven't done an update at all. I consider Settlers stable and mature.

I've envisioned something like what you described for a recent project. I'm not sure if the last step is really necessary... llRemoteLoadScriptPin lets you set the running state, and the script is reset automatically (I think). I imagine it'd work fine that if the upgrade process doesn't work due to the moons being out of alignment or whatever, just have that customer trade you for the new version manually.

Can llRemoteLoadScriptPin be used on object you don't own? I've tried, even setting the item to modifyable and llAllowInventoryDrop(TRUE). It worked fine when I owned the object, but when I gave it to someone else I couldn't load anything into it anymore.

In my steps 1 & 2 I was envisioning that you would give the owner your update package as an object. They would then be the owner of the update object and could say touch the object to start the process. Make any sense?

I guess this would mean that they'd lose any persisted data though, e.g. if there was a high score script with data. This would also imply any any self-discovery of UUID's would have to be working quite well (i.e. as the objects would be rezzed each time you gave an update).

Why I say this is that the tricky thing I have to deal with is the fact I have multiple objects each needing to communicate to each other. Currently they listen on a channel number that is related to their UUID (i.e. unique, but once the other object knows/discovers the UUID it can work out the chat channel to use to send it a message). So at startup/reset there is a need for an object to "discover" the other objects it will be communicating with (I have a script which takes an object name and returns a UUID, via link/sensor, for this). I have been wondering whether I'm making life more difficult for myself then I need to

Yeah, I was thinking automated update of the scripts without the current owner doing anything. Maybe that's not possible.

How nessiary is it to store update server address in in a note card. I kind of wish sl would suply us with a server to managing script update.

Ah, yeah... in my case, none of that applied, because Settlers doesn't really have any kind of "high score"... it's 10 points and you win, and while it's POSSIBLE to get 11 points, it's not possible to get any more without winning first and ending the game. I don't even want to think of the mess that would have been involved in trying to make an updating system work. Fortunately, we were distributing the game as a transferable, non-copyable object, so we could just take it back and replace it with a new one for our customers. I know that won't always be the case.