[Opensim-users] Animating NPCs without osNpcPlayAnimation

[Dr Ramesh Ramloll]

Justin, Thanks so much for the clarification.

On Mon, Jun 3, 2013 at 6:32 PM, Justin Clark-Casey
<jjustincc at googlemail.com> wrote:
> On 03/06/13 22:19, Dr Ramesh Ramloll wrote:
>>
>> Hello
>> I was a surprised to see that I could animate an NPC without using the
>> osNpcPlayAnimation OSSL command.
>> For e.g. if you create a prim and set it to animate an avatar who sits
>> on it, then you could use something like
>>
>>      run_time_permissions(integer perm)
>>      {
>>          if (perm & PERMISSION_TRIGGER_ANIMATION)
>>          {
>>                  animation=llGetInventoryName(INVENTORY_ANIMATION,0);
>>                  llStartAnimation(animation);
>>          }
>>      }
>>
>> that gets triggered when sitting is detected.
>>
>> However, if you get an NPC to sit on the same prim, you would not
>> expect it to animate as well because the osNpcPlayAnimation command is
>> not there. It's not that I do not like it, it's just that I do not
>> understand it. And I am wondering if this is a bug. if this is fixed,
>> then I may have to debug my scripts for all my seats at a later stage.
>> 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.
>
>
> The effective interpretation of llStartAnimation() is that it applies to all
> avatars, which includes both client controlled avatars and NPCs.
> osNpcPlayAnimation() does have overlapping functionality but is more general
> since you can play animations given an NPC id, not just those which have
> granted PERMISSION_TRIGGER_ANIMATION.
>
>
>>
>> on a side note, how does one efficiently update scripts for many
>> objects that use them at once. It would be great if each script
>> element in every prim is actually a pointer to some script in
>> inventory, so that when we change the script in the inventory, then
>> all scripts would know about the change. Is this something way too
>> hard to implement?
>
>
> I think this is a hard thing to do since the system just isn't designed to
> treat separate objects as clones of a master object.  The two solutions that
> come to mind are
>
> 1) Have a manual script controlled system that can llDie() all the clones on
> command and reinstantiate them with the next script from a master object (a
> complex and approach).  I think this is what commands such as
> llRemoteLoadScriptPin() may be for but I haven't done that sufficient script
> work to know.
>
> 2) Directly edit the script asset in the database to incorporate the
> changes.  This will only work if you want to change all instances and you
> know for sure that all objects are using the same script asset (which is
> hard to guarantee if a de-duplicating asset database isn't used).  You would
> also need to clear the simulator's asset cache after this is done (a complex
> and fragile approach).
>
>>
>> Ramesh
>>
>>
>>
>> --
>> '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
>> 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
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de
> 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