Some animations losing their orientation in MLP

Question: how much is the rotation of an animation dependent upon the rotation of a previous animation?

Background: This may not be the correct forum to ask in. But I'm curious to know if animators feel that an issue I've encountered might be owing to the nature of the animations used.

I have some (proper, fully-licenced) animations that I'm using in some MLP 2.0 products.

The animations will be fine when one or two other animations have been chosen first, but for the most part, when any other animation has been chosen from the MLP menu before them, they completely lose their rotation.

Now, I know that storing rotation is in this situation MLP's job, and has nothing to do with the animations themselves. But that's just it: the rotation is definitely, decidedly 100% stored, and the product rebooted and duly given the hula-grass skirt around it. The rotation, as I said, will come out fine if you happen to choose say "Meditation" first, but otherwise, people sitting on the ball come out skewwhiffy -- and not even in a consistent way, randomly skewwhiffy each time.

The animation will still function exactly as it should; it's just a matter, it seems, of a rotation that can't be applied to it.

With that background, my question is, how much is the rotation of an animation dependent upon the rotation of a previous animation? Can one influence the other?

I realize for deeper answers I need to go to an MLP forum, but wanted to check the above question here first with the experts.

(To be absolutely clear, not asking for MLP help here: just checking some facts first to get my ducks lined up.)

Update: a few other people have confirmed the same thing to me.

And Nathalie Niven is reporting problems with sex balls in SL: http://www.slinworldtoday.com/2008/07/faulty-sl-sex-balls-rumour-is.html

How does MLPv2 move the balls around when switching animation sets (what function)? Is this new with the 1.23 server?

Since I haven't noticed any products that used to work breaking, I suspect this is a new bug in MLPV2 (hopefully, just in MPLV2.1) rather than an SL bug.

Please try putting a debug message in the listen event handler in ~pos, and see if it gets a different message from ~memory in the working versus nonworking case.

If the output is the same for working versus nonworking cases, put a debug message in ~pos where it sends the positions and rotations to the balls.

If the output is still the same for both cases, try a debug message in ~ball just before the calls to llSetPos() and llSetRot().

By "debug message", I simply mean a call to llSay() or whatever you prefer.

I'm doing this from memory, so don't be too concerned if things don't quite match what I say. I'll check ingame as soon as feasible.

Hey Lear, I did all that and passed the debugging output to Learjeff already, on Monday I think it was. He has it just ask him for it.

But there's always the possibility that something bigger is afoot, as evinced here:
http://www.slinworldtoday.com/2008/07/faulty-sl-sex-balls-rumour-is.html

KK issue resolved: According to Learjeff, the problem is animations that have their hip position the same in T frame and first animation frame. SL ignores that. For MLP, you want every joint in the anim to have been moved (except head, if you want it to be able to move with the mouse.)

Posting here in case anyone has this issue in the future.

Not sure what this other issue is about:
http://www.slinworldtoday.com/2008/07/faulty-sl-sex-balls-rumour-is.html

[/url]

I'm glad you have confirmed that. I have suspected it.

However, I have had some cases in which the orientation of the hip changed between the T-frame and first animation frame. It seems as if, when used in MLP 1.2, the hip rotation that starts in the first animation frame were used as if it were the t-frame rotation.

For example: I have an animation in which I want the hip to actually have rotations of 0 / 0 / 0 in the first animation frame. In the t-frame, I set the rotations to 1 / 1 / 1. I expect that when the animation starts, the hips will be at 0 / 0 / 0 on the first animation frame. However, the animation actually seems to start at 1 / 1 / 1 in the first animation frame, causing me to adjust the position in the MLP to rotate the ball to -1 / -1 / -1 to compensate.

As I said, I have noticed this in MLP 1.2. I haven't tried to replicate it in MLP V2 (though that might be a project for me soon).

Amity, you only have to change one of the 3 axes, and by less than a degree for it to be considered by SL to be a controlled joint in the animation. Also, you can change the position rather than the angle. Any change to the 6 coordinates will do the trick, if the change isn't too small. I'm not sure what the minimum is, but bvhacker does that. See bvhacker thread in animation tips forum.

There will be no difference between MLP and MLPV2 in this respect, or XPOSE SexGen or poseballs or any other animation system. It has nothing to do with the scripts. It's how SL interprets animations.

I know you are examining the SL animation optimization code. I'd love for you to be able to divulge, in English, what the rules are for whether SL "optimizes" a frame or not based on minimum joint movement.

I never looked at bvhacker (assumed it was just some sort of program for viewing the .bvh file; that would make my head spin). I wasn't aware it had some tweaking tools. I'll take a look at it now.