Script updating

Hi I was just wondering how people tend to go about updating scripts and objects? Although not being able to find any threads on this in search my presumption is that you have a designated prim UUID that you send messages too when people want to update then kill the old object and send the user a new one. This is how I presume you do it for trans/no mod/no copy objects. Is there a better way? I'm just interested to hear about other peoples ideas as the possibility of not sending a new object or not killing are all too likely within SL (although you could add some checking before sending).

Thanks in advance.

Yes it has been covered once or twice. Try a search for auto update or any combination like that.

The auto update example is where I started, so I can't really add any more advice except something I ran into yesterday:

I'm not sure if this is the way it's supposed to be since I never used it before this weekend, but if you drag-copy a prim, it looses its PIN, but when you take a copy and rez that, it still has its PIN set.

Might save you a little headache .

Auto-update can be solved in a number of way on the models of well known network protocols. I use a llSensor-based nodes discovery. This one works only in a 96m radius. As we are limited to 16 results, I divide the network in zones, naming the nodes 'XYZNetwork realm1', 'XYZNetwork realm2', and so on. The results of llSensor are stored in a nodelist.

When a new client script is released, the server walks the list and executes llRemoteLoadScriptPin. PIN is initially stamped on the nodes by a bootstrap present in the prototype. Then the server send it's key to the nodes, allowing them to open a bi-directional data channel. Alternatively, a node may register the network by sending a 'REGISTER key' request to the server. In this case, it has to know the server key and is not limited to 96m (in fact, grid-wide).

Once the netwotk setup, you can begin exchanging requests such as 'GIVE INVENTORY_CATEGORY name to node key'. By designing the protocol carefully, you may cover a large range of applications. I subclass the client/serveur objet by putting the instance methods in separate scripts exchanging llMessageLinked with the network scripts. More to come

I'm confused as to what you are suggesting here.

Are you saying you are going to set up a grid-wide network of sensors for locating eligible objects for updating? I don't think that idea will work too well. Beyond the obvious "grey goo" factor of setting up a grid-wide network of sensors, it still can't detect objects that are in Inventory (ie, not rezzed), as well as having problems with attachments, or ineligible objects with the same name, or those eligible ones which have had their name changed.

Some parts of what you are saying make sense, and are already in use in other updater projects.

First, as a newcomer, i'm experimenting with LSL to understand exactly what i can do and what i can't. Secondly, communication is SL in a pain and i really need, for my game, a server-based network to feed my notecards and landmarks givers. It will be region-wide in a first time, but it may evolve to a grid-wide network, similar to Pathfinder Linden's networked kiosks. The sensor-based discovery is just the first working algorithm i had implemented.

I don't see the grey-goo problem since no objet is self-replicating. I see security problems, of course. To prevent jamming in by ineligible objects, we can rely on the very low probability that another player had choosen the name 'Server-h8i6f8b6s9n5c7" or anything you may imagine to make name collision as unlikely as possible. Even then, an ineligible object will not load the client scripts because of PIN.

The server can't detect objects that are in Inventory, of course. But the client can, and client and server can talk. Once you cant talk, you can do any transaction you want like 'SENDME this' or 'UPDATE that'. As example, a kiosk may periodically delete an inventory item and query the server for the current one. A more sophisticated protocol could be the server broadcasting 'IHAVE this', some clients deleting this and issuing a 'SENDME this'.

Compared to the 96m sensor range, "The Grid" is very very very very large and growing rapidly. The Grid is perhaps approaching 350 million square meters now.

It would not be possible to setup sensors grid-wide, nor would it be possible to maintain them with the present growth rate.

-peekay

Do we use broadcast on the Internet? No. llSense is good for a local area network. My land is 3000m2. I have givers, i have also small prims acting as spatialized sound sources containing a script "under development" i don't want to copy/paste in each ball at each update.

A day will come i will need to share data with other residents on the grid. Of course i won't use node discovery for *that*. Rather some sort of registering mechanism via email or web. SL needs routeurs, and a real object-to-objet data transport layer. Email is a joke, but that's all we have. Communication engineering in SL is primitive. This has to change if we want SL to enter the information age.

I would think the communications limitations as they exist now are there not because LL doesn't want to join the "information age" but because any kind of prim to prim communication has a bandwidth cost associated with it. And since those prims are on the grid, it's LL bandwidth. We all want a way to communicate directly from one prim to another, grid wide, but the reality is that the cost in doing so would be disastrous, without the throttling effect of the current email method.

It's an issue very similar to the 'persistent storage' problem we all wish could be solved without sending data out of world, or stuffing it into ObectName or ObjectDescription.

It boils down to there being a finite resource budget, and an unpredictable range of applications - from inexperienced script authors inadvertantly saturating the network or asset store, to griefers doing something similar, intentionally. The latter is the unfortunate 'control' factor here that simply cannot be ignored.

zk

That frood Zaphod really knows where his towel's at.

LSL seems to take pains to give us good reasons to avoid doing some of the things we should avoid. (Unfortunately, there's no algorithm to detect sloppy work!)