[Opensim-users] Animating NPCs without osNpcPlayAnimation

[Justin Clark-Casey]

This is not possible, again because unrezzed objects are serializations in assets and they are immutable (except in 
restricted cases where you can break the rules if you're very careful).

On 04/06/13 19:14, Dr Ramesh Ramloll wrote:
> 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 <dz at bitzend.net> wrote:
>>
>> On 4 June 2013 06:19, Dr Ramesh Ramloll <r.ramloll at gmail.com> 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
>> Opensim-users at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-users
>
>
>


-- 
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc