llSetKeyramedMotion Pros, Cons and Gotchas

[Monica Balut]

I just used llSetKeyframedMotion to control floats in a Mardi Gras parade.

 It really did make programming the path A LOT easier over the LlSetLinkPrimitiveParamsFast way of doing it.  It worked decently and fairly smoothly.  I didn't bother to calculate times in multiples of 1/45 and didn't have any real issues.  That path basically navigated one loop around a city block so minor changes to the path were not a problem.

 Although I didn't have any real problems with the vehicle getting nudged off path, the incremental way of moving the vehicle along got me to thinking that an absolute way of entering a series of postions would probably allow the vehicle to stay on path if nudged.  See SVC-7475.

 Probably the biggest gotcha was the fact that any random avatar attiempting to sit on the float while it was moving caused the float to stop.  The only way to get it moving again was for someone with edit privileges to go quickly in and out of edit mode.  The wiki talks about the fact that selecting the moving object causes it to stop, but it was not obvious to me that sitting would also cause the same thing.  I filed a JIRA on that SVC-7700.

 The other gotcha, was the fact that issuing a KFM_CMD_STOP did not seem to reset the object as described in the wiki.  Issuing a KFM_CMD_PLAY right afterward (via a listen command) caused the float to start off on an unpredictable path.  I would have thought that a PLAY after a STOP would do nothing.  I filed SVC-7698 about that.

 Finally we got caught by the 64 PE limit of obejcts using this function.  It wasn't clear to me at first in the wiki that they were talking about the PE of the whole linkset.  There are actually 2 problems here.  First is the totally weird way that PE is calculated.  I you happen to use a single sculpty prim, it's PE gets doubled when you link it to the convex hull root prim.  This makes no sense to me.  The second is the 64 PE limit itself.  I think that's rather limiting.  I filed SVC-7699 about that.

 Since parade floats are pretty complex objects with lots of sculpty prims, we ran into to the 64 PE limit rather quickly.  Luckily a friend of the builder came up with an ingenious work around.  We had a "driver" sit on a pose ball linked to a simple base float in a static pose.  We then had the avatar wear the top part of the float as an attachment.  So we successfully had our parade with very elaborate floats.  The only downside to this work around was if the driver would have crashed.  Luckily this didn't happen and if it did we had alternate drivers who could quickly step in.

 

[Dora Gustafson]

---

Monica Balut wrote:

 The other gotcha, was the fact that issuing a KFM_CMD_STOP did not seem to reset the object as described in the wiki.  Issuing a KFM_CMD_PLAY right afterward (via a listen command) caused the float to start off on an unpredictable path.  I would have thought that a PLAY after a STOP would do nothing.  I filed SVC-7698 about that.

 

---

A KFM call with empty lists works better than the STOP in my opinion: llSetKeyframedMotion([], []);

 

[Jenni Darkwatch]

I've not messed with the function, so take this with a grain of salt: _Physics_ PE cannot be above 64. Just set the physics shape for most prims to "None" and you're set. If all fails, set a simple box as the root prim and leave that as the only physics-shape and set all others to none.

[Rufus Darkfold]

There was a change some time last month to round the time down to the next lower 1/45 of a second, so you don't have to.  (One gotcha is that if you use .1 second, the documented minimumm, or anything less than 5/45 second,  it fails)

KFM_CMD_PLAY after KFM_CMD_STOP should restart the animation sequence from the beginning.   I have not seen random behavior as you describe, but I have always invoked those functions from a UI, so there was a delay between the stop and the play.   Maybe you need a delay between the two.

KFM_CMD_PLAY after KFM_CMD_PAUSE should continue from where it was paused.

 

[Monica Balut]

So you're saying that "reset" as it's desceibed in the wiki means resetting the current path to its start position, and not "erase the current path" to [] as I had interpreted it to mean.  As I remember the behavior, the float took off immediately to the right after the PLAY, instead of proceeding forward as ti would have if it were starting from the beginning.

[Monica Balut]

As I commented in SVC-7700, the problem of the float stopping when an avatar attemtps to sit on it while moving only seems to happen when there is an avatar already sitting and another one attempts to sit.  A single avatar attempting to sit wiil cause the object to stop but then it reliably restarts once the avatar is sitting as described in the wiki.  Since we always had multiple avatars already sitting, we always got the results I originally described.

[Talarus Luan]

Note that sim restarts can cause translation (movement, not rotation) to stop functioning. So, if you have any persistent objects using this function, sim restarts (for any reason, including sim software rollouts) can break it. This issue is being investigated atm.

https://jira.secondlife.com/browse/SVC-7556