Update scripts on objects gridwide?
|
|
Zolen Giano
Free the Shmeats!
Join date: 31 Dec 2007
Posts: 146
|
05-15-2008 00:16
I made this wonderful system to update all the scripts in my objects...it works like this:
1. You rez an object and registers itself with the database with its version number. 2. an update server polls the DB looking for objects with a version number lower than its current version. 3. if it finds one, it gets this object's key and sends an updater object to it with llGiveInventory() 4. the updater object rezzes as soon as it arrives in the other object's inventory. 5. the updater object does it's remote load script into the original object, then dies.
This works great and I thought I had all my problems solved....until I sadly found out that llGiveInventory() ONLY works in the same sim if it's an object to object transfer.
So, looks like its back to the drawing board.
My question is....is there any way to make this happen without actually having to send a av-bot to that region to give the updater object?
Thanks in advance to anyone who replies!
- zg
P.S. I have a funny feeling that the short answer is going to be 'no'.
|
|
Eazel Allen
EA-design™
Join date: 11 Feb 2007
Posts: 123
|
05-15-2008 01:00
I would also like a way to do this ive been workin on a system too I have already made it keyless using my own webserver but the only way I can make it work gridwide is to have the update server send an update bot to the owner of the item needing updating. This is ok but means the owner has to manually rezz his update bot would be nice if I could send the bot directly to items inv and have it autorezz.But sadly I dont think it is possible yet 
_____________________
http://secondlife://cub/235/190/465/
http://www.slexchange.com/modules.php?name=Marketplace&MerchantID=48444
|
|
Dora Gustafson
Registered User
Join date: 13 Mar 2007
Posts: 779
|
05-15-2008 01:31
Consider the note by DirtyMcLean on http://www.lslwiki.net/lslwiki/wakka.php?wakka=llRemoteLoadScriptPinI don't know if it helps but it is along the same alley I guess
_____________________
From Studio Dora
|
|
Zolen Giano
Free the Shmeats!
Join date: 31 Dec 2007
Posts: 146
|
05-15-2008 01:36
@ Dora: Thanks for the link...but that's the problem I started with...llRemoteLoadScriptPin() only works in the same sim you're in. (srry..didnt read the whole comment)...the other thing is..I'm the owner of the objects I want to update....I could send the updater object to myself.  But I'm trying to avoid going to all my terminal locations to update them. Here's an idea...make the updater object physical and have it fly there? lol...I thought of that as a joke....but if you're working on the mainland...could that work?
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
05-15-2008 08:52
Maybe. But flying objects along complex paths through off-world gridpoints and around parcels with object entry turned off is not trivial.
How about this. Have a system where objects that need an update queue themselves up, and you have a HUD or other attachment that dequeues the next one. When you dequeue an update request, the HUD gives you a llMapDestination() or the object IMs you with an SLURL. Then you could even build your HUD to automatically llRemoteLoadScriptPin() when you are close enough. That turns updating all your systems into a large number of clicks and such, but the actual work will be minimal; just a set of clicks.
|
|
Ollj Oh
Registered User
Join date: 28 Aug 2007
Posts: 522
|
05-15-2008 09:05
haa haa. script updating is limited to the same region.
now make a pharser that compiles heard words into script commands and make it say those words.
There is one, but its code is huge and bloated.
|
|
Dora Gustafson
Registered User
Join date: 13 Mar 2007
Posts: 779
|
05-15-2008 09:13
From: Ollj Oh haa haa. script updating is limited to the same region. Interesting! Please explain it in more depth... it might be useful
_____________________
From Studio Dora
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
05-15-2008 10:10
Sounds like a reference to the fact that llRemoteLoadScriptPin() and llGiveInventory() (with an object destination) only work on prims in the same region, but the rest of the post is completely off-topic, so who knows. http://www.lslwiki.net/lslwiki/wakka.php?wakka=llRemoteLoadScriptPinhttp://www.lslwiki.net/lslwiki/wakka.php?wakka=llGiveInventory
|
|
Shadow Subagja
Registered User
Join date: 29 Apr 2007
Posts: 354
|
05-15-2008 11:21
With libSL, and so many bot management tools out there, why not script a bot to do the go-to/rez updater. There is a lot of information client side about the environment/objects/avatars that scripts simply can't get at, also many things an avatar can do in-world that a scripted object cannot (like teleport, own a prim, etc).
|
|
Ordinal Malaprop
really very ordinary
Join date: 9 Sep 2005
Posts: 4,607
|
05-15-2008 15:00
From: Zolen Giano Here's an idea...make the updater object physical and have it fly there? lol...I thought of that as a joke....but if you're working on the mainland...could that work? It isn't such an odd idea at all - if they are all in the same contiguous region, that could certainly work (though I would not use physical movement, rather nonphysical/warppos). In fact it was what I originally thought of when seeing the first post here.
_____________________
http://ordinalmalaprop.com/forum/ - visit Ordinal's Scripting Colloquium for scripting discussion with actual working BBCode!
http://ordinalmalaprop.com/engine/ - An Engine Fit For My Proceeding, my Aethernet Journal
http://www.flickr.com/groups/slgriefbuild/ - Second Life Griefbuild Digest, pictures of horrible ad griefing and land spam, and the naming of names
|
|
Zolen Giano
Free the Shmeats!
Join date: 31 Dec 2007
Posts: 146
|
05-15-2008 15:25
From: Hewee Zetkin How about this. Have a system where objects that need an update queue themselves up, and you have a HUD or other attachment that dequeues the next one. When you dequeue an update request, the HUD gives you a llMapDestination() or the object IMs you with an SLURL. Then you could even build your HUD to automatically llRemoteLoadScriptPin() when you are close enough. That turns updating all your systems into a large number of clicks and such, but the actual work will be minimal; just a set of clicks. Yup..thats where I'm going with this. I'm just going to make my update server an attachment. My database already keeps track of Region, Pos of the objects so it would be trivial to make a list or private webpage of slurls of objects that need updating. Once I get the attachment to work proper, I'll look into using slib to create a simple bot that only needs to wear the attchment and TP to a list of places it's given.
|
|
Ollj Oh
Registered User
Join date: 28 Aug 2007
Posts: 522
|
05-15-2008 16:35
haa haa script updates only work with modify permissions on the object, meaning they may barely work from one persons prim to another persons prim. for the bot-way to work they must buy each others objects without permission loss. Or use allowinventorydrop and I indrude some nice code into your bots objects.
Ah well, you go and have your update-bot with full permissions on your other AVs.
Once again, a compiled script can translate/interpret a string into script code to execute it, change that string, and spread it further. The procedures for that will not be worth it within the 16k limit but it already exists to execute uncompiled text from notecards or chat. The strings can be stored and transmitted in many ways.
|
|
Malachi Petunia
Gentle Miscreant
Join date: 21 Sep 2003
Posts: 3,414
|
05-15-2008 18:04
There was a long and not-so-glorious history of people using autonomous swarming objects to collect data of use to the swarm owner. These worked by flood filling the main grid with temp-on-rez invisible objects that flew to four points in a sim from which you could detect anything in the sim. By being temp-on-rez and flying at altitude they could skirt the permissions restrictions that would otherwise keep the bots from self-replicating. These bots would take excursions into adjacent sims and spawn another self-replicating swarm until eventually the main grid was completely infected. There were probably some sort of limiters on them that prevented them from rezzing too many offspring, and if you are using this system for version updates, they may have to have a way to kill last week's model. Also, you have to be very careful with this type of scripting in order that you not crash the entire grid. To the best of my recollection, LL said something to the effect that such bot-swarms flood filling the grid was not against the rules, but that may have been because the bot maker was a friend of a Linden; I don't think this was ever figured out, and for all I know, years later they may still be up there swarming still. Good luck; this could be a feasible system for the mainland global upgrades, or it could get you banned, who knows?
|