Hello dz, since objects need to be rezzed before they can listen and then get updated, I am wondering whether your approach based on llRemoteLoadScriptPin also allows update of objects contained in prims before they are actually rezzed. This will be helpful for my particular case partly because I am functioning close to the max. number listeners allowed per region. I have no control on that number because I am using a hosted opensim solution. R
On Tue, Jun 4, 2013 at 1:49 PM, dz <[email protected]> wrote: > > On 4 June 2013 06:19, Dr Ramesh Ramloll <[email protected]> wrote: > >> Hello > >>Since my application deals with hundreds of such situations, that >> would be hard work in the future ... because as we well know updating >> code for complex stuff in opensim is so inefficient because there are >> no way to propagate changes for scripts that are used often in >> different objects. > > Propagating scripts to objects is accomplished the same way in OpenSim as it > is in Second Life, > described in llRemoteLoadScriptPin. For objects that need regular updates, > I just assign a unique > Script Pin to each type of object and include a listen on a unique channel > in the scripts that need to be updated. > Processing the update then is as easy as dropping a master object with all > the new inventory items, and an update script. > The master object does a regionsay on the assigned channel, and every object > that responds gets the inventory updated with the current contents of the > master object including the new scripts. Once the basic script is in place > you can update it to provide lists of region objects, or an update history > you can compare to find objects that have gone "off". > > Eventually you will probably discover that it is easier to break the update > functions out of the item scripts and use a generic update script in > addition to the objects functional script... 2 scripts per object 1 for > update comms and the other to be updated... > > The other use case you need to make exceptions for is attached objects. You > cannot update someones else object with this process while the object is > attached. For HUD devices one rarely wants to update them all while being > worn anyway. The obvious solution is to have folks enter a location where > an updater is , place the attached object in the ground/table and run an > update with commands "whispered" to limit the effective distance of the > broadcast... ( i.e. only update the objects sitting on the "update" table) > > This design has been working for me over 2 years now and I regularly do > updates to objects with 10-150 copies in the current region with a very very > small error rate. I also use the update option to re-install and re-start > objects that get shut down/confused when regions fail in odd ways... Its > way easier to click an update button than to find and manually script reset > dozens or hundreds of items > > d > > > _______________________________________________ > Opensim-users mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-users -- 'Consider how the lilies grow. They do not labor or spin.' Rameshsharma Ramloll PhD, CEO CTO DeepSemaphore LLC, Affiliate Research Associate Professor, Idaho State University, Pocatello, ID 83209 Tel: 208-240-0040 Blog, LinkedIn, DeepSemaphore LLC, Google+ profile _______________________________________________ Opensim-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-users
