Turbine engine speed-law tuning improvements in SU6

[Updated: July 17th, 2026, 12:15 UTC)

Hello everyone,

After reviewing several reports related to turbine-engine speed tuning, we identified common limitations affecting turbojet/turbofan and turboprop/turboshaft configurations.

To address this, new optional parameters have been added to engines.cfg.

They provide additional flexibility in defining commanded N, making turbine engine speed laws easier and more precise to tune.

These additions are opt-in: aircraft that do not use the new parameters retain the previous behavior, ensuring backward compatibility.

These changes will be introduced with SU6, starting with SU6 Beta 1.8.7.0.

While the SDK documentation is being prepared, here is a heads-up on the upcoming changes. This is a bit of a long read, but I hope it helps clarify the reasoning behind them.

Background

The “100% cap” issue exposed a more general limitation in how turbine commanded-speed targets were defined. The key point is which “N” the engine controller is actually commanding, and whether it is the right target for the intended engine-speed law.

Depending on the engine type, the commanded value may represent a different physical target:

  • For turbojet and turbofan engines, where the engine core is represented by the second spool, it makes sense for the fuel-flow controller to target corrected N2, with corrected N1 then derived through a CN2-to-CN1 relationship.
  • For turboprop and turboshaft engines, where corrected Ne represents corrected N1 / Ng, the equivalent corrected-speed target is commanded corrected N1.
  • However, in many real-world tuning cases, the intended target is instead the displayed, uncorrected N1.

The new parameters are intended not only to address the “100% cap” issue, but also to align the commanded-speed target with the desired behavior.

Legacy commanded-Ne control

The legacy corrected-Ne path in FSX was based on two Mach-specific .air tables:

  • AIR_70_MACH_0_CORRECTED_COMMANDED_NE
  • AIR_70_MACH_HI_CORRECTED_COMMANDED_NE

which were later exposed in MSFS through the following engines.cfg parameters:

  • mach_0_corrected_commanded_ne_table
  • mach_hi_corrected_commanded_ne_table

This commanded Ne represented:

  • corrected N2 for turbojet and turbofan engines;
  • corrected N1 for turboprop and turboshaft engines.

Each table was a 2D table using effective throttle and inverse pressure ratio as arguments. The final commanded Ne was then interpolated between the low-Mach and high-Mach tables.

This allowed corrected engine speed to be adjusted with altitude and Mach number, including values above 100%, or to maintain a constant uncorrected N across altitude and Mach changes where required.

However, the interface:

  • was limited to only two Mach reference points (using only two tables);
  • used effective throttle rather than raw throttle lever position, making tuning for the reverse indirect and limiting afterburner tuning;
  • expressed altitude dependency through inverse pressure ratio, which is engineering-oriented but not very user-friendly.

MSFS commanded-Ne control

To make turbine engine tuning easier, MSFS introduced a linear control law based on effective throttle:

  • For turbojet/turbofan engines, this became an additional path alongside the legacy corrected-Ne tables. In this mode, the controller commands uncorrected N1 directly.
  • For turboprop/turboshaft engines, however, this became the only native path and replaced the legacy corrected-Ne tables. In this case, the controller commands corrected N1, not actual N1.

In both cases, the upper target of the linear law remained hard-coded to 100%. This made it impossible to command N1 / Ng above 100% for either turbojet/turbofan or turboprop/turboshaft engines without extending the throttle beyond the normal range.

For turboprop/turboshaft engines, this also created an additional limitation: because the controlled target was corrected N1, maintaining constant displayed N1 / Ng across altitude and Mach changes became impossible with the throttle lever held fixed.

There were also some limitations in low-idle tuning for turboprop/turboshaft engines using the tp_high_idle_throttle_pos and tp_idle_range parameters. The additional low-to-high idle segment could only be defined within the positive throttle range, which constrained ground-idle and beta-range tuning. These parameters also indirectly affected commanded corrected N1 in reverse, making reverse N1 tuning less straightforward.

New commanded-Ne options

To address these cases, several optional commanded-Ne parameters have been added to the [TURBINEENGINEDATA] section of engines.cfg.

1) “full_throttle_commanded_n1”

Type: float
Default value: 100%

This parameter allows the simplified linear N1 law to command values above 100% without extending throttle beyond the normal range.

When specified, this parameter also overrides high_n1 for consistency, effectively replacing it as the single full-throttle commanded-N1 reference.

For turboprop/turboshaft engines, it also modifies the engine-speed control law so that it controls actual N1 instead of corrected N1. This makes the behavior consistent with the turbojet/turbofan N1 path, allowing displayed N1 / Ng to remain constant with altitude and Mach changes at a fixed throttle lever position.

When this parameter is omitted, the existing behavior is preserved, ensuring backward compatibility.

However, as mentioned above, the linear law still has some design limits: reverse behavior remains tied to effective throttle and low-to-high idle logic, and the additional low-to-high idle segment for turboprop/turboshaft engines can only be defined within the positive throttle range.

To address these remaining limitations and provide more flexible control, the next parameter has been added:

2) “corrected_commanded_Ne_table”

This multi-dimensional table allows corrected commanded Ne to be explicitly tuned for turbojet, turbofan, turboprop, and turboshaft engines as a function of:

  • arg.1: pressure altitude [ft] (negative values are supported);
  • arg.2: inlet Mach number;
  • arg.3: throttle lever position (negative values are supported).

Note: extrapolation of corrected commanded Ne outside the defined argument ranges is not supported (similar to all other tables).

With this parameter, corrected commanded Ne specifies:

  • target corrected N1 for turboprop and turboshaft engines;
  • target corrected N2 for turbojet and turbofan engines.

When this parameter is specified, it takes priority over all previous settings that determined corrected commanded Ne, including:

  • use_commanded_Ne_table
  • mach_0_corrected_commanded_ne_table
  • mach_hi_corrected_commanded_ne_table
  • low_idle_n2
  • low_idle_n1
  • high_idle_n1
  • min_throttle_limit
  • tp_high_idle_throttle_pos
  • tp_idle_range
  • afterburner_throttle_threshold
  • full_throttle_commanded_n1 (introduced in SU6)

CAUTION: Some of these parameters may still be used in other engine performance calculations, but they no longer affect corrected commanded Ne.

When this parameter is omitted, the existing behavior is preserved to ensure backward compatibility.

In short, this parameter follows the same corrected-Ne concept as the legacy FSX / MSFS tables, but replaces the two low- and high-Mach tables with a single table. This provides several advantages:

  • any required number of Mach reference points can be defined (more accuracy);
  • pressure dependency is expressed through pressure altitude instead of inverse pressure ratio (better clarity);
  • throttle is expressed through actual throttle lever position instead of effective throttle. This makes corrected-Ne control explicit across the full throttle range. For example, beta-range points can be placed directly where needed, or minimum- and full-afterburner corrected N2 can be tuned independently.

While this table provides a flexible and well-established engineering approach to turbine engine control-law tuning, working with corrected parameters can require additional efforts. The next option provides a more direct path for uncorrected N1:

3) “uncorrected_commanded_Ne_table”

This 1D table (in MD-format) defines the target uncorrected N1 for turbojet, turbofan, turboprop, and turboshaft engines as a function of throttle lever position.

When this parameter is specified, it takes the highest priority over all other settings that previously determined the commanded Ne, including:

  • corrected_commanded_Ne_table (introduced in SU6)
  • use_commanded_Ne_table
  • mach_0_corrected_commanded_ne_table
  • mach_hi_corrected_commanded_ne_table
  • low_idle_n2
  • low_idle_n1
  • high_idle_n1
  • min_throttle_limit
  • tp_high_idle_throttle_pos
  • tp_idle_range
  • afterburner_throttle_threshold
  • full_throttle_commanded_n1 (introduced in SU6)

CAUTION: Some of these parameters may still be used in other engine performance calculations, but they no longer affect commanded Ne.

When this parameter is omitted, the existing behavior is preserved to ensure backward compatibility.

In practice, this table replaces the simplified linear commanded-N1 law with a more flexible table-based definition. It allows commanded N1 to be defined directly at any throttle lever position, including reverse, ground idle, beta range, normal power, and afterburner. For example, the ground-idle segment can be placed in any required throttle range, and different N1 targets can be defined within the afterburner range.

However, when using either corrected_commanded_Ne_table or uncorrected_commanded_Ne_table, an additional mechanism is still needed to adjust the commanded target using a control other than throttle, similar to the low-/high-idle behaviour available in the existing linear law. This is the purpose of the fourth parameter:

4) “delta_commanded_Ne_table”

This multi-dimensional table is applicable only when either corrected_commanded_Ne_table or uncorrected_commanded_Ne_table is used. It defines a correction to corrected or uncorrected commanded Ne, respectively, as a function of:

  • arg.1: condition or mixture lever position (refer to delta_commanded_Ne_control)
  • arg.2: throttle lever position (negative values are supported).

It can be used across any throttle and condition or mixture lever range, including proportional corrections or discrete state changes.

The condition lever position is provided by the TURB_ENG_CONDITION_LEVER_POSITION SimVar.

The mixture lever position is provided by the GENERAL_ENG_MIXTURE_LEVER_POSITION SimVar.

5) “delta_commanded_Ne_control”

Type: integer
Default value: 0

This parameter is applicable only when delta_commanded_Ne_table is used.

It specifies whether the first argument of delta_commanded_Ne_table represents:

  • 0: condition lever position (default), or
  • 1: mixture lever position.

__________

Also, when either corrected_commanded_Ne_table or uncorrected_commanded_Ne_table is present, the output values of the TURB_ENG_COMMANDED N1 and TURB_ENG_THROTTLE COMMANDED_N1 SimVars become aligned with the target uncorrected N1.

Please note that these SimVars were not effectively writable and will therefore be marked as non-writable in the SDK as of SU6.

I hope you find these parameters and the explanation useful.

Please let me know if you have any questions.

Andrey / Asobo

Are the table formatting rules available in the new SDK docs? I have not been able to find them yet.

Hello Alex,

Yes, you can find the documentation covering multidimensional tables in the SDK:

Please refer to the following section:

CFG Files General Information → Data Types → nD Table

We introduced this new data format with FS 2024. All tables in flight_performance.cfg use this format, and we also plan to use it when adding new tables to flight_model.cfg.

Please let me know if you have any questions.

Best regards,
Andrey / Asobo

Can you provide an example for corrected_commanded_Ne_table and delta_commanded_Ne_table?

The problem is that we don’t know what goes first: altitude, condition lever or throttle.

Also, can the tables use GENERAL ENG MIXTURE LEVER POSITION too? As the condition lever only allows a Enum 0-1-2 value, having mixture will allow us to simulate fine condition lever states (King Air, Kodiak, C208 to name a few).

Hello Alex,

That is a good question regarding the argument order. It showed that the description in the original post was not clear enough, so thank you for pointing it out. I have updated it accordingly, and the change will also be reflected in the upcoming SDK documentation.

The SDK also provides an example of a 3D table in the CFG Files General Information → Data Types → nD Table section. We tried to make it as clear as possible by using different colors for arguments 1, 2, and 3 in both the CFG record and the corresponding visual table representation. Please let us know if it is still confusing, and we will consider how the description could be improved further.

Regarding the mixture lever:

You are correct that the condition lever SimVar provides only an enum value, which means proportional control was overlooked in the original design. I apologize for this oversight. Although this enum may technically accept values in the range [-2147483648, +2147483647], corresponding to the limits of the integer type (as can be verified using the Simvars Watcher), this behavior is undocumented and is not intended to be used in this way.

We internally considered several solutions for providing proportional control linked to the mixture lever. The best solution we found was to add a dedicated parameter delta_commanded_Ne_control that specifies whether the first argument of delta_commanded_Ne_table represents the condition lever position (0, by default) or the mixture lever position (1).

This approach preserves the concise name of delta_commanded_Ne_table while making the table more flexible by allowing different control inputs to be used for commanded Ne correction.

It also leaves room for supporting both control inputs (the condition lever and the mixture lever) simultaneously in the future, should this be required for a specific aircraft. In that case, the table could be extended from 2 to 3 dimensions when initialized.

Overall, we considered this the simplest, clearest, and most convenient solution among the options discussed.

I have added a description of this 5th parameter delta_commanded_Ne_control to the first post in this thread and updated the description of delta_commanded_Ne_table accordingly.

Please let me know whether this covers all needs in this area.

Best regards,

Andrey / Asobo