MLPV2 and Pose Sychronization

hello, was wondering if anyone had an opinion on the following. I found some great, legal full-perm anims for couples, pricey but worth every Linden, and was just about to start buying a whack of them when it suddently occured to me -- these couple anims, currently in poseballs with synch scripts, prolly have the synch scripts for a reason......I can't recall anything about timing being dealt with in MLPV2 re making one pose pause for a second or two before starting to get them synched... does anyone else recall any kind of provision?

Doesn't seem like it:

/54/2a/240761/2.html#post1915209

And I can confirm that the official MLP v1.2 ran "freewheeling", that is both animations received the command to start at the same time but from there on they are just left to loop with no resyncing available.

It probably wouldn't be too difficult to add a sync command to the MLP, but there's a problem. The basic idea of syncing is, once the animations are both downloaded and playing, you stop them briefly and restart them together. But when you stop the animations you need to temporarily play a suitable "pause" anim, if only for a fraction of a second, or else the avatars will revert to sitting or the awkward rubbery flailing that avatars do when they don't have any animation at all to play. So generally you play the static "waiting" pose that virtually all syncing poseball sets contain for a moment. In something like the MLP, though, you'd need the script to keep track of which static pose goes with which animation (if one is even available), and it would require changing the whole data format, organizing the notecards differently with additional parameters, all kinds of ugly stuff.

I don't think there's an easy way to do it, and for now the best way to resync animations that get out of whack may be to briefly change to another animation then change back to start them up in sync again.

You could ask Lear Cale what he thinks, he's clearly dug into the code more than most of us, but I suspect it would be a big pain.

NO, not planning to add that, but if I think of a trivial way, which doesn't reduce memory in ~menu, I might.

Meanwhile, there's a trivial workaround: just select the pose. That resynchronizes (starts both anims at the same time). Such a simple workaround is one reason why I'm not thinking too hard about this.

Anti, you mention that it's necessary to play a different animation to get the resync to work. That may be true for robustness, or it may have been true earlier, but it *seems* that it's not necessary at least most of the time. I did test this with MLPV2, and simply restarting the animation did appear to start all anims from the beginning again.

I can confirm that sometime by uploading an animation with an obvious lead-in (e.g., looping in last frame only) and verify that clicking on the same pose again does work.

Thanks for adding your thoughts on this, Lear. I was working from assumptions based on development of my own syncing poseballs some time ago, in which I found it desirable to do something like this:

llStopAnimation(main-anim);
llSleep(0.5);
llStartAnimation(main-anim);

The problem here is, having previously done llStopAnimation for "sit" and other system animations, often avatars were left running no animations at all which seemed to cause some very odd visual effects for that half-second. So I needed to do this:

llStopAnimation(main-anim);
llStartAnimation(static-pose);
llSleep(0.5);
llStopAnimation(static-pose);
llStartAnimation(main-anim);

Seems like I assumed too much without having looked again at the way MLP handles menu clicks; it must be doing something different, or SL is handling these things differently these days. Thanks for taking the time and setting the record straight

When you click the same pose again, MLP essentially does this:

llStopAnimation(anim)
llStartAnimation(anim)

As I said above, that *seemed* to do the trick when I tried it, but I might have been lucky. Or perhaps SL changed since you worked on your synchronization code. I'm sure your method is more robust; mine depends on behavior that isn't guaranteed.

Yeah, I would have expected that as well, so I bought a licenced one as a test (I'm not an animator, just a scripter.) I must have been unlucky on my very first go, because the two poses were out of synch. (I can drop them on you in world, if you want.)

But anyhoo was certainly not meaning to propose any extra work for anyone, was just wanting to confirm that a synch mechanism hadn't been included.

Hmmm, yes please feel free to drop the anims on me and I'll check it out.

Duly passed to you.

So I guess we amend our theory to say that switching back and forth will *often* synch an animation, and if it doesn't, decide if the animation makes no sense unsynched, and if it doesn't rip it out and don't use it.

Chaz, when I switch poses, the new pose starts all anims at the beginning, synchronizing them reasonably (assuming there's not much script lag). The example you dropped on me seems to work fine.

Earlier I had guessed that simply restarting the current pose would do the job, but it doesn't. Evidently, if you start an anim, stop it, and start it again, it resumes from where it was -- but if you start another anim in the meantime it restarts. Either that or you need to wait a bit.

If I could think of a good way in MLP script to make selecting the current pose have the same synchronizing effect as changing poses, I'd consider adding it. But I suspect I'd run into the same problem that you mention above: the interim pose is necessary, and would look odd.

I'm at a loss to explain why you don't see the poses resynchronizing when you change poses. Perhaps it's just bad lag where you're working?

BTW, MLPV2 stops all running animations. If I stop the current animation and pause (llSleep()), I see the av freeze in the animation. I suspect it's the last frame in the anim, but I'm not certain. It *should* be, since when we stop an animation its out-phase should be run (any frames between the end of the loop and the end of the animation). My anims are all fully looped.

Something you might investigate to simplify your synchronized anims would be to loop all but the last frame, and see if (now) the last frame sticks and you don't need the static animation. Or just retest with a fully looped anim to see if you get what I see.

Figures that it works for you, it's always the way isn't it, LOL! We're in a Prime Sims Estate sim, and in fact have a private sim to ourselves, so very lag free. I'll have another go in a day or two.

On a different MLPv2 matter, if there isn't already, or if no one is doing it already, I'd like to volunteer to write both builder documentation for it, and end-user help that can be passed out to customers. In SL, I've done the documentation for Builder's Buddy, and rewritten the manuals for the JEVN line of products.

Do you know if there is any such documentation already in the works?

Please see

http://wiki.secondlife.com/wiki/In-World_Maker_Tools

and please feel free to improve it, as well as add entries for other tools as appropriate.