Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008908opensim[REGION] Script Functionspublic2021-07-08 17:572021-07-29 17:48
ReporterKayaker Magic 
Assigned To 
PlatformDel T1400Operating SystemUbuntuOperating System Version16.04
Product Version 
Target VersionFixed in Version 
Summary0008908: llStopObjectAnimation cannot stop animations unless they remain in inventory
DescriptionThe llStopObjectAnimation call has some strange dependency on animations in inventory. If you start an animation, then rename or delete the animation in inventory, llStopObjectAnimation can no longer stop it. llGetObjectAnimationNames continues to report that there is an animation running, but those names cannot be used to stop animations unless the animations are still in inventory with the same names. I've got prims stuck running animations I can never stop!
I tested this in SL and I do not see the problem there.
Steps To ReproduceI've included a simple turbine mesh DAE and an animation that makes it spin at 12RPM. These are a bit difficult to upload, so I am leaving a copy of the test setup in Dev Outreach. It is a gold turbine on a copper base, between two dancing animeshes. It is full-perm and for sale for $0. If you cannot get there, here is how to upload them:

Turbine.dae In the rigging tab (FS 6.4.13 or better) select "include skin weight" then select "include joint postions" before uploading the mesh. After rezzing it, select "animated mesh" in the features tab of the build dialog.

Turbine12.bvh (text of this file included below the script in the additional information section) Set the 'in frame' to 3 (18.75%) and the 'out frame' to 15 (93.75%). Other settings will work, but result in discontinuos motion. Put this animation in the inventory of the turbine.

Put the following script in the inventory of the turbine.

To test:
Touch the turbine (animesh requires that you right-click and select touch from the pie menu)
The first click will start the animation, the second click will stop it (note: this animation finishes one cycle before it stops, be patient).

To see the failure:
Right-Click-Touch the turbine until the animation is started.
Edit the turbine and rename the animation to some other name in inventory.
Click on the turbine to stop the animation IT WILL NOT BE ABLE TO STOP THE ANIMATION.
Additional Information//animesh test: Demonstrate strange animesh problems with stopping animations
    touch_start(integer num)
        list anims=llGetObjectAnimationNames( );
        if (llGetListLength(anims)<1)
            llOwnerSay("no animations to stop");
            integer i; //loop to stop all animations
            for (i=0;i<llGetListLength(anims);i++)
                llOwnerSay("stopping: "+llList2String(anims,i));
            anims=llGetObjectAnimationNames( );
            if (llGetListLength(anims)>0)
                llOwnerSay("ERROR! some animations remain: "+llList2CSV(llGetObjectAnimationNames( )));
                llOwnerSay("animations stopped successfully");
        if (llGetInventoryNumber(INVENTORY_ANIMATION)<1)
            llOwnerSay("no animations to start yet");
            llOwnerSay("starting animation: "+llGetInventoryName(INVENTORY_ANIMATION,0));

/**********************below this is the Turbine12.bvh file******************
ROOT mPelvis
    OFFSET 0 0 0
    CHANNELS 6 Xposition Yposition Zposition Zrotation Xrotation Yrotation
    JOINT mTail1
        OFFSET 0 0 1.2
        CHANNELS 3 Zrotation Xrotation Yrotation
        End Site
            OFFSET 0 0 1
Frames: 16
Frame Time: 0.4
0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 30
0 0 0 0 0 0 0 0 60
0 0 0 0 0 0 0 0 90
0 0 0 0 0 0 0 0 120
0 0 0 0 0 0 0 0 150
0 0 0 0 0 0 0 0 180
0 0 0 0 0 0 0 0 210
0 0 0 0 0 0 0 0 240
0 0 0 0 0 0 0 0 270
0 0 0 0 0 0 0 0 300
0 0 0 0 0 0 0 0 330
0 0 0 0 0 0 0 0 360
0 0 0 0 0 0 0 0 30
0 0 0 0 0 0 0 0 60
0 0 0 0 0 0 0 0 90
TagsNo tags attached.
Git Revision or version numbercf0b1b1840c6add78f4099788abca89e7635dc3c
Run Mode Grid (Multiple Regions per Sim)
Physics EngineubODE
Script EngineYEngine
EnvironmentMono / Linux64
Mono Version6.x
ViewerFireStorm 6.4.13
Attached Files? file icon Turbine.dae [^] (35,988 bytes) 2021-07-08 17:57

- Relationships

-  Notes
UbitUmarov (administrator)
2021-07-08 18:12

that is the spec.
if it is by name, it needs to be on the script prim inventory.
UbitUmarov (administrator)
2021-07-08 18:14

see [^]
for the stuck objects.
tampa (reporter)
2021-07-09 04:07

So what exactly would even the circumstance be for the animation to be deleted from the prim inventory while it is running? That doesn't exactly make much sense so I am not surprised the specification LL came up with for the function doesn't account for this and it makes little sense to add it, after all with the animation removed there is no way to start it again either, so the object in terms of animation becomes useless.

It's a host-dependent function as the notes on the wiki say as well, which means it looks for what it is in, not what links there are or any other scope and that too is by specification, so even if you were moving links around you still need to put animations into the objects you want to animate, you can't sideload them.

I can already hear the request come in for an os function for sideloading via asset uuid or something, but do we really want to do that. Already got enough functions accepting bad data just as well, wouldn't want to imagine what sideloading a bad animation asset would do or what nasty exploits that may bring. So don't even think about it djphil :)

The same "annoyance" actually happens with a few other functions iirc, sound, textures and such, because by spec these things are not just meant to do whatever. The idea is to respect content permission to the degree that not anyone can just apply things to their prims they don't have on inventory or permissions over. Think that's a pretty reasonable thing to want and OpenSim already throws that under the bus with a few functions of its own. For the LL functions the specification is meant to be one to one to make transition easier and not need to maintain a database of caveats. So even bugs are happily implemented which you can take however you like, but the concept of parity in terms of features and functionality makes it easier to write scripts if the reference can be trusted to work with OpenSim.
UbitUmarov (administrator)
2021-07-09 05:51

Note that because reasons, this animations MUST be on the scrip prim, and started by their name, not UUID. llStartObjectAnimation only takes names as arguments, not UUID.
llStopObjectAnimation will accept a uuid, but again the animation must be present on the prim.
llGetObjectAnimationNames() only keeps and returns a list of the names llStartObjectAnimation did use.

It is implicit guidance to keep animations and their scripts on the respective prim, But this means a huge mess of link messages to control a linkset, and that just increases lag and control latency, bc link messages travel as events the target script will run "one day"
Like a few other cases, it makes more sense to just put all on root and control from there mainly because, as is, the animated skeleton belongs to the entire link set, not parts.
This seems another flaw on scripting model coherence, we just inherit.

I did add osClearObjectAnimations, also per prim because it is easy to lose track of the animations running
melanie (administrator)
2021-07-09 07:44

LL did it to support commercial use - what use is it to make an animation "no copy" when you can start and then remove it? I would not be very surprised if, in SL, removing it also stops it. Always bear in mind that all LL does is commercially motivated.
Kayaker Magic (reporter)
2021-07-15 10:11

I got the poop from an old SL resident: Originally LL made the "must be in inventory" rule for Start and Stop, but it was used by griefers in the following way: Griefers would fool victims into starting a porn animation and then DELETE THE ANIMATION FROM INVENTORY so the victim could never stop it. After complaints about that, they changed llStopAnimation() to work even when not in inventory so scripts could clean these out. But they never updated the documentation for llStopAnimation(), and they copied that documented restriction into llStopObjectAnimation() years later.
So griefing is one way you can get an animation started that isn't in inventory. the way it happens to me is while debugging animesh animations: I'm starting animations, observing, stopping, editing, loading, rinse and repeat all day. Eventually I FORGET TO STOP ONE OF THEM before deleting it and then I'm stuck.
UbitUmarov (administrator)
2021-07-15 14:08

<cia-opensim> mantis 8908: use the prim idea of running animations, (by name or by key) on llStopObjectAnimation(), ignoring the prim inventory (unlike sl?)

can you please test?
Kayaker Magic (reporter)
2021-07-18 11:05

I tested this again in SL: If you start an animation, then delete it from inventory, llStopObjectAnimation can still stop it by name.
Kayaker Magic (reporter)
2021-07-18 11:13

And I saw a change log about this and built a new OpenSim from the 2021/07/18 Master sources, ran that on a region in OSGrid. Did the test again and IT BEHAVES THE SAME AS SL NOW!
Problem fixed! Thank you!

- Issue History
Date Modified Username Field Change
2021-07-08 17:57 Kayaker Magic New Issue
2021-07-08 17:57 Kayaker Magic File Added: Turbine.dae
2021-07-08 18:12 UbitUmarov Note Added: 0037849
2021-07-08 18:14 UbitUmarov Note Added: 0037850
2021-07-09 04:07 tampa Note Added: 0037851
2021-07-09 05:51 UbitUmarov Note Added: 0037852
2021-07-09 07:44 melanie Note Added: 0037853
2021-07-15 10:11 Kayaker Magic Note Added: 0037861
2021-07-15 14:08 UbitUmarov Note Added: 0037862
2021-07-18 11:05 Kayaker Magic Note Added: 0037868
2021-07-18 11:13 Kayaker Magic Note Added: 0037869
2021-07-29 17:48 Kayaker Magic Status new => resolved
2021-07-29 17:48 Kayaker Magic Resolution open => fixed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker