Dynamic intake animation ( SOLVED )

[Deano1973]

Hi folks, I've got an animated air intake that is based upon Angle of Attack ( Incidence Alpha ). The animation all works as planned, but it "wobbles" rather than moving smoothly from the up position to the maximum deflection position of ten degrees when in high-alpha flight - there must be an element I'm missing in my code. Does anybody have an idea what I've done wrong?

ETA: The intake moves a total of ten degrees, one degree for each degree of angle of attack.

<PartInfo>
<Name>Intake_Auto</Name>
<AnimLength>100</AnimLength>
<Animation>
<Parameter>
           <Code>(A:INCIDENCE ALPHA,Degrees) (E:ABSOLUTE TIME, second) * 100 % 1.0 / </Code>
</Parameter>
</Animation>
</PartInfo>

 

[Essex]

'Lag' is good for slowing things down, see post 35 here;

P3D v2 - AI Ship Animations

OK so then my gauge should look like this: (A:EXIT OPEN, percent) 5 > if{ 100 (>L:door_0, number) } els{ 0 (>L:door_0, number) } Pretty sure this will not work, however, but we'll see.

www.fsdeveloper.com

 

[Roy Holmes]

AOA tends to be noisy so yes some form of damping would smooth things out.
Roy

 

[Deano1973]

@Essex @Roy Holmes Thanks guys, the Lag setting sorted things out and it's all moving much more nicely now

 

[Deano1973]

Hi folks,

I've been doing some more work on this and I've noticed that the timing part of the code is causing the intakes to raise up again instead of remaining down based on increasing Incidence Alpha - in essence, they're running through a cycle rather than responding to AOA.

<PartInfo>
<Name>Intake_Auto_F15</Name>
<AnimLength>100</AnimLength>
<Animation>
<Parameter>
           <Code>(L:Intake Ramp Switch, bool)
           if{ (A:INCIDENCE ALPHA, Radians) (A:AIRSPEED INDICATED,knots) 150 &gt; (E:ABSOLUTE TIME, second) * 100 % 1.0 /  }
           els{ 0 } </Code>
           <Lag>10</Lag>
</Parameter>
</Animation>
</PartInfo>

It also runs a bit slow, despite having the Lag entry set quite low. I suspect this is all something to do with the Absolute Time entry but I can't really get my head around it. Any pointers hugely appreciated

 

[Deleted member 1281]

Don't get the overall logic of the code but the principle of Lag is the lower the lag setting the slower the animation. You seem to have it the other way round?

 

[Deano1973]

Don't get the overall logic of the code but the principle of Lag is the lower the lag setting the slower the animation. You seem to have it the other way round?

Well, that sorted the speed of movement! Just the cycling of the animation to go. Gotta be something about the mathematical at the end of the code, but without something there the animation doesn't play at all, so I must be referencing something incorrectly. The animation does respond to Incidence Alpha, above 150 KIAS with the intake switch set to "AUTO", so the logic is generally okay otherwise.

 

[EduHir]

first order lag function

https://www.fsdeveloper.com/forum/threads/making-a-bitmap-element-slide-slowly.437777/

https://www.google.at/search?q=first+order+lag+formula&cad=h


my code

<!-- First Lag Order -->
      0.7 s8   <!-- factor K  lag setting  -->
      (L:XMLKeys_Rudder,percent)         l8 *            <!-- raw_sensor_value -->

      (L:XMLKeys_Rudder_PRV,percent)    1 l8 - *     <!-- 1 - k * --><!--  prv_filtered_value -->

      + d (&gt;L:CORE7X_Pedal_Pos_Axis,percent)    <!-- output value -->
            (&gt;L:XMLKeys_Rudder_PRV,percent)         <!-- new_filtered_value -->
<!-- First Lag Order -->

maybe try using degree. there is a greater change of the value

 

[Deano1973]

first order lag function

maybe try using degree. there is a greater change of the value

Degree didn't make much of a difference, although I agree that it should have done. I don't think that lag is the issue as that's already been sorted. It's the fact that the animation is cycling based on Absolute Time that's my issue. I think that I need a value for Incidence Alpha against the 100 keyframes to sort it, but I'm not entirely sure on the logic required as I thought that animating based on Incidence Alpha would automatically rotate the animation as AOA increased ( although I know that it's not quite the same in the sim as in real life ).

 

[EduHir]

 (A:INCIDENCE ALPHA, Radians) (A:AIRSPEED INDICATED,knots) 150 >

This gives you only 0 or 1.
I would recommend to write to testgauge to check your outputs.
and then of course you have to set your animation.

 

[Deano1973]

I've tried several different code types but this one still has me stuck. I tried another code variation to see if the intakes would take to three set positions;

<PartInfo>
<Name>Intake_Auto_F15</Name>
<AnimLength>100</AnimLength>
    <animation>
        <parameter>
            <code>(L:Intake Ramp Switch, bool) (A:AIRSPEED INDICATED, knots) 150 &gt; and
                              if{ (A:INCIDENCE ALPHA, Degrees) 5 &gt;
                                  if{ 100 } els{ 50 } }
                             els{ 0 }</code>
            <lag>100</lag>
        </parameter>
    </animation>
</PartInfo>

This one also failed to move. It's an oddity, as surely it shouldn't be too difficult to get something to move based on Incidence Alpha, whether radians or degrees?

 

[Heretic]

Check the capitalization of the code tags and unit. I remember FSX being rather pedantic about this.

 

[Deano1973]

Check the capitalization of the code tags and unit. I remember FSX being rather pedantic about this.

Good spot, Degrees should be degrees - will test it tomorrow, a bit burned out by this one at the moment so making mistakes I shouldn't.

 

[EduHir]

Did a test. Degrees works.
Did a testflight B727.
above 150 knots (A:INCIDENCE ALPHA, Degrees) was below 5.

Do you know what (E:ABSOLUTE TIME, second) means?

for AOA there is A:ANGLE OF ATTACK INDICATOR.

 

[Deano1973]

I'm beginning to suspect that there is something amiss with the model that's preventing the animation from running - it happens sometimes with visibility conditions. Going to check through before testing any further, and will report back.

The aircraft in question is the F-15 Eagle, which can obviously pull very high-G, high-alpha turns, so the intake movement through ten degrees should be easily visible, as well of course when landing and taking off.

 

[EduHir]

Here an excerpt from a very good F18 HUD. the original HUD by Scott Printz.

            //---- AOA BRACKET
            <Element>
                <Visible>(A:GEAR HANDLE POSITION,percent) 0 &gt;</Visible>
                <Clip Top="160" Left="68" Right="592" Bottom="790"/>   
                <Image Name="AoA_bracket_00FF00.bmp" Bright="Yes" ImageSizes="25,90">
                    </Image>                   
                <Shift>
                    <Delay PixelsPerSecond="120"/>
                    <Value Minimum="2.1" Maximum="14.1">(A:INCIDENCE ALPHA,Degrees)</Value>
                    <Nonlinearity>
                        <Item Value="-1.9" X="-19" Y="-310"/>
                        <Item Value="6.9" X="-19" Y="-46"/>
                        <Item Value="8.1" X="-19" Y="-10"/>
                        <Item Value="9.3" X="-19" Y="26"/>
                        <Item Value="18.1" X="-19" Y="290"/>
                    </Nonlinearity>
                </Shift>       
            </Element>

it uses value from 2.1 to 14.1
Shortly ago a saw a F15 youtube video where you can very good see the movement of this intake.

 

[Deano1973]

Here an excerpt from a very good F18 HUD. the original HUD by Scott Printz.

Yes, I have used similar code for the AOA indexer in my Super Hornets and the Eagles, and it works fine. However, using it as part of a physical animation is not working in the same way at all. The airplane's visibility codes are not blocking anything, so it must be something I'm doing wrong. If I animate the parts to elevator, for instance, they move perfectly. Try them with the incidence alpha variable, there is no motion at all. I'm not sure why.

 

[Heretic]

Good spot, Degrees should be degrees - will test it tomorrow, a bit burned out by this one at the moment so making mistakes I shouldn't.

Make sure to also check the tags themselves.

 

[kalong]

Yes, I have used similar code for the AOA indexer in my Super Hornets and the Eagles, and it works fine. However, using it as part of a physical animation is not working in the same way at all. The airplane's visibility codes are not blocking anything, so it must be something I'm doing wrong. If I animate the parts to elevator, for instance, they move perfectly. Try them with the incidence alpha variable, there is no motion at all. I'm not sure why.

Check your variable is there value changed. If it have changed, then go on animation.
If your code inside modeldef, make it as simple as possible.

Note: lag animation is not sync together between external and internal view.

 

[Deano1973]

I have tried pretty much every combination I can think of on this, in terms of code, but have had no success. I created a small dummy part and animated it in the same way, and it fails to respond to anything, which is very strange. But, if tagged with an existing rotation-based animation, such as elevator per cent, they all animate perfectly well. This leads me to believe that the issue is something to do with the relation between the number of keyframes and the degrees of rotation at play in the code. My experience thus far with XML doesn't provide enough knowledge to "see" through the problem, and despite much Googling I haven't been able to find comparable code to test that worked. Even stranger, I have created custom animated rotating / flipping switches until the cows come home and they all work just fine, so why a simple ten degree rotating AOA animation would prove so difficult is beyond me at the moment.

I shall keep plugging away and post the solution here when I figure one out.