MSFS24 Blender animations offset in MSFS2024

[Robcap]

Hi all,

Busy to get my first MSFS plane done. Steep learning curve, after my last one in FSX ;-) However, I'm progressing.
Working on Milton Shupes de Havilland DH.80A Puss Moth, to port it to MSFS (with his permisson, ofcourse).
But I run into a strange problem:

I make the model in Blender. I model the animations as per SDK. (only rudder, elevator and ailerons for now)
In Blender all animations are OK. Proper neutral position and the extended positions.
Export with the 2024 blender pluging goes without problems, as does building the project in Devmode. No errors.

In game, after building the model, all animations are a few degrees off in neutral position.
The behaviour tool shows the animation input in the sim is indeed 50%, so neutral. But still I see the wrong position in the 3D model.
When I move the joystick to 100% the 3D animation goes to full right (as it should).
When I go to 0%, the 3D animation goes to neutral, where it should go to full left. When I go to say 10%, it does go to full left position in the 3D model.
Talking about the rudder here, but similar stuff happens wit aileron and elevator.
So full deflection to 0% sends the 3D model to the neutral position.

I use the DA62 sample exterior model XML, and editted it accordingly.
As you can see in below screenshot, all controll surfaces are a bit off in neutral position.
It's not joystick related, co-developer sees the same issue.

And below the behaviours in neutral position

And below a snip of the XML. I'm calling stock behaviours, so nothing I can change there...

Does anyone have an idea what can cause this, and how to fix it?

Thanks, Best, Rob

 

[Anthony31]

How are your keyframes mapped in Blender? With that code full left should be keyframe 0, centred is keyframe 50 and full right is keyframe 100.

Also make sure your keyframes end at 100. Don't have any stray keyframes above that. The code expects the animation length to be 100 and if it isn't it will try to scale the animations which can lead to things getting confusing real quick.

 

[Robcap]

OK, will try that. I first thought 0,1,2,3. Then tried 0,20,40,60. Will now try 0, 50 and 100.

 

[Anthony31]

OK, will try that. I first thought 0,1,2,3. Then tried 0,20,40,60. Will now try 0, 50 and 100.

Yeah, there's your problem. The keyframes in Blender should match the ANIM_LENGTH parameter which mostly defaults to 100.

Here's the deafult parameters for the elevator template:

<ANIM_NAME>HANDLING_Elevator</ANIM_NAME>
        <ANIM_SIMVAR_SCALE>0.5</ANIM_SIMVAR_SCALE>
        <ANIM_SIMVAR_BIAS>50</ANIM_SIMVAR_BIAS>
        <AILERON_DEFLECTION_SCALE>0.2</AILERON_DEFLECTION_SCALE>
        <ANIM_LENGTH>100</ANIM_LENGTH>

That's where the * by 0.5 and + 50 comes from.

Personally I use 0,10,110 and 210 keyframes.

0 is neutral, 10 is full left, 110 is neutral and 210 is full right. I do this so that keyframe 0 is always neutral. It's simply easier to work with when EVERYTHING is neutral at 0 keyframes.

To set those parameters I would use this code (if I used the ASOBO templates which I don't):

        <UseTemplate Name="ASOBO_HANDLING_Elevator_Template">
            <ANIM_SIMVAR_SCALE>1</ANIM_SIMVAR_SCALE>
            <ANIM_SIMVAR_BIAS>110</ANIM_SIMVAR_BIAS>
            <ANIM_LENGTH>210</ANIM_LENGTH>
        </UseTemplate>

 

[Robcap]

Thanks Anthony. This works!
At a later stage I might look at custom code, but that is not my strong point...

 

[=rk=]

the ANIM_LENGTH parameter which mostly defaults to 100.

Fyi, anim_length is only a numeric value on the xml side, on the mesh side it is a scalar value and either one can be pretty much any length that suits you. On the mesh side, I usually use 36 key animations, 12, 24, 36 and I do this for everything, gauge needles, tires, rotors, anything that can complete a full circle or less with reasonable fidelity, if I need more fidelity I add more keys. You can set your xml animation length to any value, if it is 2 and you are animating a switch that works out fine. If you're animating a gauge needle, you can still set your xml animation to 2, the problem with 2 keys in terms of the rpn xml is that there are only 2 whole numbers to work with, whereas if your animation length is defined to be 100, you get 98 more steps to calibrate that needle to. I actually don't believe the sim enforces any specific animation lengths. I used to believe so with suspension flex and rotor/wing deflection, but I have seen working examples that do not conform to what I've learned to be the standards.

I tested this length constraint, or lack of it extensively when I made a gauge that uses mechanical drums to display the frequency numbers. Every equation that algebraically aligned the frequency onto the animated drum would invariably be perfectly lined up at one end of the range, zero and displaced visibly by 9. I ended up setting up a system of Lvar registers to which each frequency solution pointed. Next I set the xml animation length to 400 and used the behaviors debug to manually advance the animation until each number was square in the window, then I recorded that number into the register.
The end result was that on a scale from 0 to 9, frequency number 5 would not have worked as xml animation key 50 in a hundred key animation, it ended up being key 214 of 400 to be exactly centered in the window.

Yep in the 1970s when this gauge was current, we were only using the decimal tenths of the frequency and I chose to reproduce that aspect since the tooltip will tell you the actual frequency anyway.