Justin, Thanks so much for the clarification. On Mon, Jun 3, 2013 at 6:32 PM, Justin Clark-Casey <[email protected]> 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 >> [email protected] >> 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 > [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
