Flight Model SDK

It’s nice to see the additional flexibility provided by the new flight model
parameters in SU10 and the improved documentation for some of the existing
parameters, but I hope there will be additional improvements coming in terms
of clarity and explanations for how to use these parameters (e.g., why they
exist).

Some examples: 1) The new clcd normalization parameters – ok, we can now
adjust the aoa limits for adjustments to the “theory curve,” but why would we
want to do this and exactly what effects would this have? What happens outside
those limits?

  1. The static friction scalars – First of all, it may be helpful to explain
    better which friction component is being addressed here. I assume it is the
    side or lateral friction only. Especially since static friction is no longer
    relevant in the direction of motion; i.e., there would not be a low speed or
    high speed static friction. Secondly, the sentence for the high speed one,
    “Reducing this value tends to make wheels less sticky and feel like they are
    “on rails” at higher speeds,” is confusing to me.

For example, the “and” doesn’t appear to be used correctly; it implies that
reducing the value would make the wheels feel like they are “on rails” at
higher speeds, which I think is the opposite of what is meant. Also,
“stickiness” implies that reducing the parameter’s value will also reduce the
rolling friction of the wheel (it should be the tire) in the longitudinal
direction as well. Is this what is intended? If so, it’s not a static
friction.

How and why is this meant be to be used? Is it to help customize side forces
on the tires from crosswinds during takeoff and landing, and/or is to to help
customize rolling or braking friction?

  1. Many of the new parameters have no description and only tell what the
    default value is. (I assume this is a work in progress.)

  2. Not new, but for the Reference Speeds section, are these parameters only
    for the developers use during flight model development and tuning, or are
    these parameters actually used in some way to affect how the sim airplane
    flies?

Thanks,

Don

For point number (3)… the only parameter descriptions that didn’t make it
into the documentation (that I am aware of) for the flighting are in the
[Flight_Tuning] section of the flight model. They will be documented in the
full public version of SU10 and I’m sorry they didn’t make it into the
flighting docs. However, for reference, here is the information on them:

There was also this one missing
from the [Reference_Speeds] section:
And talking of reference speeds,
I can answer point (4) for you too: The reference speeds are used in different
systems across the simulation, like the Flight Assistant, the Aircraft
Selection UI, sim notifications, and overspeed triggers. They don’t impact the
flight model directly , however. For example:

  • full_flaps_stall_speed = 40 ; Used in the Flight Assistant
  • flaps_up_stall_speed = 45 ; Used in the Flight Assistant
  • cruise_speed = 124 ; Used in aircraft selection UI
  • max_mach = 0.6 ; Used for overspeed trigger
  • max_indicated_speed = 163 ; Used for overspeed trigger

I’ll see about explaining these things more clearly in the documentation!

Hello @donstim 1) The new normalization parameters is the result of this
discussion: https://devsupport.flightsimulator.com/t/3963 There’s a mistake
on our part though, these new parameters and debug info will be available with
SU11, not SU10. 2) Yes, those descriptions were draft but we fixed them in the
meantime. Of course, reducing those scalars reduces friction so the aircraft
is more likely to slide. Only the lateral forces are impacted by those scalars
so rolling friction and braking when your aircraft is rolling straight will
not be influenced. ( @Nocturne Probably something we want to add in the doc as
well ) Regards, Sylvain

Thanks for the explanations. I hope there will be more information on exactly
how the parameters in 1) should be used. It isn’t obvious to me even after
reading the discussion in the post you linked.

Ok, those were only a few examples I gave, not meant to be an exhaustive list.
I hope you all will take a step back when writing these descriptions to make
them as meaningful as possible to someone not intimately familiar with the
reasons for introducing the new parameters. It’s good, for example, to provide
flexibility I guess by use of different scalars for wing and fuselage for MOI
predictions, but I don’t see what the basis would be for actually choosing
them. One more example of an SDK documentation issue is the description for
the aileron effectiveness. It says it is for scaling the elevator lift
coefficient in the [AERODYNAMICS] section. Regards, Don

The normalization process used to consider two hardcoded reference AOA (0° and
12°) to have a match between theory and computed FM. Depending on your FM
configuration specifics (in the example of boufogre, a very high drag scalar),
this led to inefficient normalization. The 2 new parameters allow you to chose
which reference AOA you want to consider to maximize the theory/computational
match as this picture shows:

Thanks @FlyingRaccoon for the explanations. I appreciate the possibility
offered by these new parameters, however I am surprised that these two AOAs
were hard-coded and not interpreted from the other defined parameters. When
setting the lift_coef_at_drag_zero , what we are really doing is setting
the AOA for minimum drag since CL is defined in relationship with the
AOA in the lift_coef_aoa_table. That same minimum drag is defined
by setting the drag_coef_zero_lift in the file, and it should NOT be
possible to get a lower drag coefficient than this exact value, as defined in
the configuration file. I have yet to play with the new parameters, and I will
report my conclusions. Thinking about it, it would make sense to have the
curve normalized between 3 AOAs:

  • the maximum negative AOA before stall (when flying inverted),
  • the AOA for minimum drag,
  • the stall AOA (the normal one, for positive lift, normal flight).

Thanks again.

For 2) Did you identify what is considered a “high speed” for this parameter?
Can it be set by the developer?