Unable to set manifold pressure in SU4

[MrTommymxr]

3 years ago I asked for a system to control manifold pressure and other engine parameters, but I was ignored, so I had to make a work around.

[IDEA] FORCED PROP BETA system for Throttle, Pitch (RPM) and Mixture

This is not a new idea, but after seeing what has been done with the “PROP BETA FORCED” system, it would be great if we could have the same with the Throttle, RPM and Mixture (condition) levers. This means we dont have to use the CPU intensive, slow, and awkward .WASM simconnect modules that just like to break things. Operation would be the same. A Key event will enable the “FORCED” key events for the Thottle, RPM and mixture (condition) levers. The user will have no idea that their inputs…

Other than that I have been constantly asking for piston engine and propeller improvements.

Request: More engine table points

Hi, The 8 data point limit for the engine_mechanical_efficiency_table and engine_friction_table are not enough to make an accurate engine. 2 points are needed for the 0 rpm range and another for overspending, leaving only 5. Going down the normal rpm points (2700, 2400, 2200, 2000, 1800) already use up the remaining 5. Ideally another 3 are needed for a low idle, high idle and intermediate rpm. (600, 1000, 1400) Hope some more can be added.

Option to remove manifold pressure in external camera

Can we have the option to not show Manifold pressure in the external camera? If you use input events it jumps around alot. Thanks -Tommy

SimVar to control piston engine power globally?

Hi all, I’m looking for a SimVar that would allow me to control piston engine power globally—specifically something like engine mechanical efficiency or engine friction. I’ve gone through all available piston engine-related parameters and SimVars but couldn’t find anything that seems to fit. The goal is to simulate engine power loss when the A/C compressor is turned on in a piston-engine aircraft. Has anyone come across a way to achieve this? Thanks in advance!

Note: Turns out this was about pressure and not temperature.

Piston engine model vs temperature

Greets, After comparing the piston engine model to real world data, ive noticed that the model is around 0.3% weaker per degree celsius colder. This adds up as you climb and as it gets colder. At sea level the power settings work perfectly. However eg. at 14k feet (-11°C) setting 45% based on MaP and RPM im only getting 40%. Can we have a temperature to Mechanical efficiency table?

Why is feathering so slow?

As the title. Setting a prop to feather is extremely slow. Setting a target rpm of 0 gets the job done way faster. Here in the short video both engines are shutoff. The left engine prop lever is set to -100 and the right is first set to 0 and then -100 to finish the feather. i tried using the force beta system, but the behaviour is identical to setting -100. Can we set A:PROP BETA? it would solve the problem and allow us to make my own prop governors. relevant engine config pro…

How do we define the front (reverse side) on the new Propmodel

Greetings, As the title says, how do we define the front side of the propeller? I tested a non twisted propeller and found identical thrust in forward and reverse. This doesn’t only affect reverse thrust, but also a windmilling propeller. Drag values are left to the model to calculate and cant really be changed without affecting everything else. I tried different power absorbed, aspect ratio, drag, lift, stall values, but then normal thrust is effected in ways that just bring me back to th…

Modern propmodel broken findings

findings below

Prop twist is reversed?

Greets, I’ve noticed that the “prop_mod_aoa_twist_delta_deg” variable is reversed. When increasing the twist, the tips provide more thrust. We all know the twist that props require to provide good thrust and efficiency blah blah blah.[image] More twist would (should) mean that the outer part should have less AOA and less thrust on the tips, as that is how props are twisted. They don’t twist the other way I made some tests here below. Here with the standard +6° of twist. Tip AoA 12.7° [ima…

[SimbolFSReborn]

Hi @EPellissier ,

In my case, with FSR500, I am just running some updates loops at 120hz to write simvars while the pilot is on reverse mode and beta range on ground, the package is msfs 2020, pushed to msfs 2024 via the normal workflow.

With SU4, I see the variables jumping suddenly (as if, they stop updating for a bit, then continues), is this expected based on your understanding of what has changed?

Just trying to help you understand what we doing as 3rd party devs, lots of developers are using these loops to run their custom simulations, such as, inject custom fuel flows, custom turbo NG, ITT, and many other engine conditions using the “writeable” simvars available in MSFS.

I mostly do this via WASM, however during reverse / beta ranges on turboprops I found the core sim fighting my updates so hard, that I was forced to move to RPN at high frequency loops, this is working great in MSFS 2020, and up to SU3 in MSFS 2024.

Hope this give you guys more context.

Best,
Raul

[MrTommymxr]

We are not given the tools, so we have to make the tools ourselves.

[EPellissier]

@MrTommymxr

I thought the point of input events were to react instantaneously.

The documentation states: The added bonus is that input events are only executed when they are needed, so it’s far cheaper to get an animation value using the cached value inside the input event rather than recalculating it every frame in the animation code. which is a bit different to what you wrote.

@MrTommymxr

I was ignored, so I had to make a work around.

@MrTommymxr

I have been constantly asking

@MrTommymxr

We are not given the tools, so we have to make the tools ourselves.

As you know we don’t have infinite resources that we can dedicate to your requests - priorities have to be set.

Best regards,

Eric / Asobo

[EPellissier]

@SimbolFSReborn

With SU4, I see the variables jumping suddenly (as if, they stop updating for a bit, then continues), is this expected based on your understanding of what has changed?

Would you be able to provide me with a list of those SimVars that you see jumping? We have an idea to fix @MrTommymxr’s issue regarding the manifold pressure, and the mechanism could potentially be applied to other SimVars.

Best regards,

Eric / Asobo

[EPellissier]

@SWS-AlexVletsas

This could affect our top-seller planes.

Unfortunately we cannot really act on such assumptions - have you had reports of some of your aircraft not working as expected in SU4?

Best regards,

Eric / Asobo

[SWS-AlexVletsas]

I’m working on it!

[SimbolFSReborn]

I am sending you my XML code via Private Content

Best,
Raul

[MrTommymxr]

I know, and every developer has their own unique problems and solutions as well as different priority levels.

The thing with input events in FS24 is that they are not executed when they are needed. Hence why they are running slow. You can see in the example that they run at around 0.5-0.3x the normal speed. This then breaks their functionality for animations.

I used Input events for my gear simulation and sequencing, but in FS24 I had to move them to GT_ANIMs because they were moving slow and inconsistent.

[quote=“EPellissier, post:46, topic:16696”]

have an idea to fix @MrTommymxr’s issue regarding the manifold pressure,

[/quote]

If you are making a forced manifold pressure system, may I request that there be absolutely no filtering or smoothing of the set manifold pressure. The game has a smoothing system built in which disturbs the functionality of my engines. I tried using input events to control the throttle separate from the user, just like the working title FADECs. But this caused the engine to stall as the manifold pressure increased too slow. Manually setting the Avar like i do has no smoothing.

[MrTommymxr]

Disregard, i was not using su4.

This is still su3. I will check in a few hours

[MrTommymxr]

Nope the 1000hz fix doesn’t work.

[MrTommymxr]

Just tested 1.6.31
It’s better but still 7% low.

[MrTommymxr]

I reverse engineered the Engine model so I know that for X torque I need Y manifold pressure.

So, one thing I do is that I check the manifold pressure Avar and compare it to the value I want. Then use a simple Integral calculation to create a correction factor.

In FS20 this would always hover around 4-8%, depending on framerate and other factors. In FS24 Su3 it hovers around 8-12%. After this update, the correction factor is 0%.

In Simvar Watcher I get 3 different behaviours depending on the game. Eg:

FS20:

• Set and read Manifold pressure var match.
• Correction value 6%.
• Engine performance matches.

FS24 Su3:

• Set and read Manifold pressure var do not match. Read value is 8% higher than set.
• Correction value 8%.
• Engine performance matches.

FS24 Su4:

• Set and read Manifold pressure var match.
• Correction value 0%.
• Engine performance does not match.

In Su4, If I force 6% correction factor I get the correct engine performance, so that’s better than Su3 where 8%+ is needed.

If I may speculate:

FS20:

• Avar is set
• Game processes
• Avar is read by plane and Simvar watcher

FS24 Su3:

• Avar is set
• Avar is read by Simvar watcher
• Game processes
• Avar is read by plane

FS24 Su4:

• Avar is set
• Avar is read by plane and Simvar watcher
• Game processes

[FlyingRaccoon]

Hello @MrTommymxr

The deployed fix addresses the regression introduced specifically with SU4.

I have plotted manifold pressure, torque and rpms on your Da42-VI in SU3 and SU4 and couldn’t see any noticeable difference.

So my understanding is that any difference left comes from the difference of implementation between MSFS 2020 and 2024, which we discussed here:
Input events slow - [MSFS 2024] Bug Reports - MSFS DevSupport

Regards,
Sylvain

[MrTommymxr]

As said in my previous post, there appears to be a difference in the way the vars are read. The plane (xml) and engine model see different vars in SU4. In FS20 and SU3, the plane and engine model saw the same manifold pressure. If these don’t match, then the correction loop doesn’t work and the engine performance doesn’t match.

This will now be proven by the screenshot below

Fs20:

• Set: 2.551
• Correction: 6%
• Plane reads: 2.592
• Simvarwatcher reads: 2.591

Result: Correct engine performance.

Fs24 SU3:

• Set: 2.552
• Correction: 8%
• read: 2.559
• Simvarwatcher reads: 2.764 (2.552*1.083 = 2.763)

Result: Correct engine performance.

Fs24 SU4:

• Set: 2.552
• Correction: 0%
• read: 2.552
• Simvarwatcher reads: 2.552

Result: Incorrect engine performance.

If the engine model is not getting the correct manifold pressure, then the performance doesn’t match.

In your screenshots there is still a measurable difference from ~216 to ~209.

Here is the correction loop + read value.

(L:FADEC_SET_MAP_FIX:1) (L:FADEC_SET_MAP:1) (A:RECIP ENG MANIFOLD PRESSURE:1, bar) - 0.01 * + 1 max 1.15 min (>L:FADEC_SET_MAP_FIX:1)

(A:RECIP ENG MANIFOLD PRESSURE:1, bar) (>L:FADEC_SET_MAP_READ:1)

[MrTommymxr]

For testing I am locking the correction factor to 6%

However the zoom and menu issues still exist

Also at lower settings, less correction factor is needed, disrupting the engine tuning.

[FlyingRaccoon]

@MrTommymxr

If I may speculate

I see what you mean here. So it’s a bit more complicated than what you suggest but there’s a bit of truth in there.

There is more than one source to the issue here:

• Your implementation in MSFS 2020 already is framerate dependent. Your fix lvar varies from 6 to 9%, depending on my graphics settings (so torque varying between 300 and 308 Nm)

• You introduced some specific lvars for MSFS 2024, but the detection does not always work. For example if you restart a flight, your FIX_FS24 lvar is not reset to 1. Your writing of manifold pressure in a component update then no longer occurs.

• The manifold pressure simvar you write fights with the sim own evaluation:

  • If you don’t write it for a lapse of time, the value will converge back towards the sim computed one. Your configuration of engines.cfg is such that the sim will output a very low manifold pressure, so this can cause big fluctuations in the simvar value.
  • If you write it more often than the sim does, your fix is evaluated with your own output value rather than the one from the sim

• The reading, fix evaluation and writing of the manifold pressure simvar are in separate components, in different xml files. With the changes made in SU4, in regard of parallelization, this means the sequence in which those are evaluated is subject to changes.

So, you have:

• a 30Hz update component that reads the manifold pressure simvar
• an input event that writes the manifold pressure simvar corrected with your fix
• a 100Hz update component that also writes the manifold pressure simvar corrected with your fix

What happens is that you are writing the simvar more often than the sim, especially your 100Hz component. So you end up “poisoning” your own 30Hz fix evaluation with the value you wrote yourself instead of the output of the sim.

We don’t really have a way to handle such designs with a feedback loop at the moment, where we could guarantee a consistent sequence between reading, writing and updating the sim.
However, there are several ways to mitigate this to get closer to the behavior you are expecting:

• Read the manifold pressure, evalute your fix and write the simvar in the same update component.
  For example, if you move everything to your 100Hz component, you’ll notice the behavior is a little bit more consistent, although it still suffers from being framerate dependant (low framerate means low simulation update, means the value you write plays a bigger role than the sim)

• Move this in a ASOBO_GT_Anim_Code component. This will be updated with a frequency that roughly matches the simulation update. You will therefore more consistently read the output from the sim, rather than the value you wrote yourself the precedent cycle.

• As mentionned above, the value oscillates between what you write and what the sim outputs, which in your case is a very low manifold pressure. Configure your engines.cfg so that it outputs a manifold pressure that is a bit less aberrant, and this will reduce the gap your fix needs to fill.

Regards,
Sylvain

[SWS-AlexVletsas]

@FlyingRaccoon we do the same using an Update to read the variable and feed it to an interim L:var. Then the Lvar is fed to an Avar through an InputEvent to match the sim rate.

This approach worked in 2020 and 2024SU3. I will re-test it in SU4, but do you see any reason for us to switch to 100Hz updates or Anim_Code_Template?

[MrTommymxr]

@FlyingRaccoon

Your implementation in MSFS 2020 already is framerate dependent. Your fix lvar varies from 6 to 9%, depending on my graphics settings (so torque varying between 300 and 308 Nm)

In Fs20, Input events run faster than the native frame rate. The event updates when the manifold pressure updates. I can achieve ~3-4x the native framerate with input events.

@FlyingRaccoon

You introduced some specific lvars for MSFS 2024, but the detection does not always work. For example if you restart a flight, your FIX_FS24 lvar is not reset to 1. Your writing of manifold pressure in a component update then no longer occurs.

I never experienced this. Additionally this value is now statesaved.

@FlyingRaccoon

Move this in a ASOBO_GT_Anim_Code component. This will be updated with a frequency that roughly matches the simulation update. You will therefore more consistently read the output from the sim, rather than the value you wrote yourself the precedent cycle.

In Fs24 the component frequency is now stable, with the in game calculations running at 100hz. Setting the map at 100hz was the most stable.

@FlyingRaccoon

Read the manifold pressure, evalute your fix and write the simvar in the same update component.

This no longer works in Su4, because the plane now reads the manifold pressure before it is processed by the game, as shown by my screenshots.

@FlyingRaccoon

Configure your engines.cfg so that it outputs a manifold pressure that is a bit less aberrant, and this will reduce the gap your fix needs to fill.

I cant do that because idle and low power settings will now be inaccurate.

None of these suggestions fix the camera or menu issue either.

Also a 1% difference in manifold pressure causes 2-3% power change. Aircraft engine/props are certified within 3% of eachother. This update equivalently removes the airworthiness certificate on my aircraft.

[MrTommymxr]

As this is now “by_design”, does this mean we get and official method to perform these actions?