Proposal to support individual control surfaces for flight model

Support multiple instances of control surfaces Right now, it is hard to
impossible to properly simulate individual control surfaces in MSFS. In a real
airplane often control surfaces are not controlled by one hydraulic system and
therefore individual surfaces can be jammed or can lose hydraulic pressure.
The simulation of these situations is right now always depending on putting a
system in between that knows what pitch or roll rates can be achieved when
this happens and then moving existing surfaces as such that these rates are
achieved. The animation part is then faked so that it looks like control
surfaces really being jammed. To lift this on a completely new level, I
suggest the following. The most important control surfaces of an airplane are:

  • Aileron
  • Elevator
  • Rudder
  • Spoilers
  • Slats
  • Flaps

Right now, the sim supports the following:

  • 2 Aileron with 1 sim-var to control them
  • 1 Elevator with 1 sim-var to control it
  • 1 Rudder with 1 sim-var to control it
  • 1 Spoilers with 1 sim-var to control it
  • Multiple Flaps/Slats with 1 sim-var to control it

This idea is about adding an indexed sim-variable for all surfaces and
allowing to set them individually if requested. Example with Ailerons The
following three variables are interesting:


The first is the variable to control the ailerons. My suggestion is to allow
the following:


This would need, that distinct surfaced need to be definable in
flight_model.cfg and they are assigned to the left or right side. The
variables know right now map to index 0. In that case writing to AILERON
which equals AILERON POSITION:0 that old behavior is active,
meaning setting position of all left and right in their opposite direction.
That means the :0 index for the deflections contains the overall left or
right deflection (could be the for example the average). When a developer
wants to use more surfaces, he needs to define the new surfaces. I would
suggest in that case the default surfaces are disabled by removing any
aerodynamic effect. New surfaces are then assigned to indexes starting with 1.
When for example the variable AILERON POSITION:1 is written, it means this
surface is deflected which can be seen on variable AILERON DEFLECTION:1. An
approach for the value in variable AILERON DEFLECTION:0 could be either to
output 0 as long as the position index 0 variable is not written or it outputs
the average of all others assigned to left or right. It has of course a bit
more impact due to this left/right assignment, example is here:

  • AILERON POSITION:1 = left aileron 1
  • AILERON POSITION:2 = left aileron 2
  • AILERON POSITION:3 = left aileron 3
  • AILERON POSITION:4 = right aileron 1
  • AILERON POSITION:5 = right aileron 2
  • AILERON POSITION:6 = right aileron 3

This would map to the following variables:


Conclusion In the same approach this can be and should be applied to
Elevator, Rudder, and Spoilers. In case of spoilers a separation from the
handle position would be desirable as well. Overall, I guess it would be
better to have more clear variables that do not distinct between left and
right, but this would be also an even broader break in the system. From my
point of view the described approach would be a good trade-off between
backwards compatibility and fulfilling the requirement I raised. Remark on
I’d like to mention here that right now the spoilers do not
create a roll-effect and it would be great to get this as well, because in
case of Airbus, spoilers are used for roll when ailerons are no longer
available. Remark on flaps/slats: I’ve seen just now that for flaps
there is now:


so at least it looks like you can individually control them. Would be
interesting if they can be already used for what I propose here. Is there
further documentation available how to use them, can the be operated
independent from the flaps index?

A very descriptive suggestion, hope it finds an implementation in the
simulator soon

Any reaction?

A great idea! I believe this shall be further expanded by making the airplane
geometry more flexible> multiple wings and empennages shall be definable.
Examples, twin rudders, biplanes, canards, … You then can assign control
surfaces to each fixed surface. You can link the surfaces to A: variables, L:
Variables … hence you can define your custom FCS, link to hydraulic systems,
etc … this way you can now define flaperons, elevons, … Assigning control
surfaces to inputs manually is nothing new, FlightGear has been doing this for

Hello, We agree that this would be a great addition to the sim, but we don’t
have time in our roadmap for that yet.

That’s actually sad news tbh because it will need third-party developers to
create “workaround” solutions if they want to simulate hydraulics and single
surfaces being jammed. This is especially true because no external flight
models are supported and are also not on the roadmap. Clearly I would be in
favor of the sim flight model to support this and not having the need for
“other” solutions. I do not understand / I’m shocked why it’s directly put in
the trash (my interpretation of Completed that is also put to other ideas you
commented about not doing it at all). Thank you for a response and
acknowledgement at least.

If you agree that it would be a great addition, but you don’t have time yet,
why is this marked as completed?

I have to admit, I’m a little dismayed that such a good idea and well thought
out post can be dismissed like this. The fact that this is marked as
‘completed’ suggests that the decision on this is final, that it’s not open
for consideration in the future. Which really defeats the purpose of writing
up suggestions like this in the first place.

Hello, The “COMPLETED” tag is a bit misleading, we’re currently changing this.
And we actually don’t have bandwith even for great ideas. It may come at some
point, I hope so, even more if we feel that we still need this kind of feature
in 6, 9, 12 months. But for now, we can’t work on that, and I think it’s
preferable to let you know this fact rather than leaving the idea

The idea should be considered within the wider context of the flight model
API; variables for control surfaces like this is only enough for 10% of the
many types of aircraft geometry we need to input to the flight model. See
this: [/articles/4798/an-incomplete-list-of-planes-you-cant-

Agreed, that list shows just how limited the current flight model and flight
model API really is. For a product whose goal is to be a flight
simulator , one would assume that the development of an accurate and
extensible flight model would simply be the #1 priority. I understand that
there are other items on the roadmap, but it seems like the core sim
functionality is only improved when it is needed for a paid DLC update (e.g.
terrain/weather API required for ATR-72 as noted by Hans, better propeller
physics introduced for helicopters DLC, thermals for glider DLC, supersonic
improvements for F/A-18 and Top Gun, etc.) These are obviously needed to
continue funding development for the sim, but one must also realize that
investing in the core simulator mechanics, especially flight model and
aircraft API’s, would greatly encourage other developers to migrate to MSFS
and release aircraft on the marketplace, which for a ~30% cut, would still
prove profitable. I hope that the stance on prioritizing key improvmenets such
as this is reconsidered on a broad spectrum within management - it’s a shame
to see key missing functionality well over a year and a half into the
simulator which should have been present on launch. It seems it may be more
beneficial to post a wishlist thread on the main forums and get votes on it
rather than posting here…

My idea/suggestion was intended to be a doable in a shorter time frame and
also with limited impact/workload for the third party developers. Overall I
agree that even more systems might be interesting, taking into account the
system of flight surfaces Sebastian was showcasing (and that is currently used
for the propellers), you could even model the whole plane with them. But it’s
clear that this will also have impact on how to develop a plane, because
defining hundreds if not thousands of surfaces is a lot of work. So maybe you
want a system that generates them for you based on some more high level info,
but still having the possibility to fine time them later on. Taking that into
account it’s also clear that using such a system is also increasing the need
for more and better data of the original airplane that should be simulated. In
many cases it’s not easy to get it and also with increase of realism, the need
for high class engineering in terms of flight controls (i.e. fly-by-wire) or
Autopilot also increases. So I think such a system should be kept optional or
at least should be able to generate a similar configuration like we have now.

I’m not sure I understand why worrying about right or left side matters? It
doesn’t really even need to know its an aileron or an elevator or whatever
(except slats it’s possible this might need a distinction, and fowler flaps
which have air passing between the wing and the flap). So, don’t you just need
surface and its definition, their position on the airplane, their orientation
with respect to the airplane at any given moment (and airflow, but I think
that’s just calculated from the first and the CFD) controlled between limits
of orientation? Ailerons could be independently controlled, so there’s nothing
special about them (and you can link them with an equation obviously). Point
being, I’m wondering why right and left side matters, that’s just a
consequence of its position and is therefore implicit. It seems to me making a
right and left side distinction is superfluous, and limits potential
applications. I’m thinking for instance of the NASA X-plane that created a
variable sweep wing by rotating the wing about the center, making one wing go
forward and the other rearward. Or perhaps some asymmetrical designs for
surfaces that extend into the airstream.