Unable to set manifold pressure in SU4

Zooming in and out changes the power output.

1 Like

Can we have a ā€œforced manifold pressureā€ system just like the ā€œprop forced betaā€ system?

for both games.

1 Like

Any updates? What is different with SU4?

I have customers unable to use the plane and worried that their purchase will be bricked in a month.

1 Like

It has been over a week and no response.

In SU4 we had to change the way certain things were calculated, which caused an unintended side effect.

Discussions are ongoing, and I will keep you informed as soon as I can share more details about this.

Regards,
Boris

1 Like

Can it be garenteed that this will be fixed before SU4 goes public?

Hello,

Unfortunately this will not be fixed for SU4.

Regards,
Boris

Hi @EPellissier any particular reason this could not be fixed? this is quite a problem, basically when SU4 goes live, lots of planes with custom simulation on many systems done via model behaviours will not work correctly and erratically.

Is quite a problem also if these are MSFS 2020 planes working in compatibility mode, since we cannot push a dedicated patch for these to make them work under MSFS 2024.

Is there any work around we can put in place? or anything to prevent the carnage this is going to cause? what if, you guys leave the 2020 planes working as they were at least? or some sort of solution?

Anything that we can do from our side?

All the best,
Raul

2 Likes

The issue is rather complex: part of the optimizations we made during SU4 is that the aircraft sim now runs on a separate thread. At the same time, we realized that we were executing Input Events on each iteration of the sim, which was never intended (even if some aircraft rely on this) and could both take quite some time and create instability (because key events must be done on the main thread for now). Hence we delayed the handling of Input Events after the sim calculations, and deferred key events on the main thread - which is causing the issues that have been reported here.

We are still trying to find a good way to mitigate/fix this issue, but this requires time to be done safely and unfortunately we might be running out of time for SU4.

Do you have a list of your products that are affected by this issue? This may help us finding the best way to implement a fix.

Best regards,

Eric / Asobo

In my case FSR500, when you are on ground, performing reverse operations and Beta range taxi operations.

@MrTommymxr has a largest base of products affected.. worth checking with him.

R.

@EPellissier
I will not publicly disclose the sales numbers, but you should have access to the Marketplace numbers. Multiply those by 3 to get the total sales with Orbx sales.

COWS DA42 Series
COWS DA40 Series
Skyward Simulations DA50-RG
1 Marketplace exclusive project under NDA (Projected to sell more than all 3 above combined)

Additionally 3 other free projects with over 250000 downloads and still getting over 500 downloads a month.

We also use InputEvents to create custom control systems (beta range, yaw damper, engine and other system behaviours). This could affect our top-seller planes.

Im not even using input events in fs24. Im using a 100hz rpn loop.

When providing screenshots of your aircraft on both FS20 and FS24 above, were you running the same version of the package or were you running the sim-specific version on each one? We assumed the FS20 version was used for both because comparing different packages introduces a lot more potential reasons for differences in the simulation.

Best regards,

Eric / Asobo

yes its the same plane. The plane defects which game it is in.

In fs20 it uses input events

In fs24 it uses a 100hz loop

May I ask why you switched from IE to a 100Hz loop between the two sims? This alone will lead to different results in the sim, won’t it?

Best regards,

Eric / Asobo

Using a 1000hz loops improves it, but its still not as stable as before

Because input events are slower in fs24

and RPN loops work better in FS24

in su3 the 100hz loop works fine, because the in game engine simulation runs at 100hz. Any lower or higher would cause desync.

Input Events cannot really be ā€œslowerā€ or ā€œfasterā€ since they are not designed to work at a specific frequency/speed. It just happens that we previously evaluated them more often than we do now - on every sub-iteration of the sim while it is now done only once per iteration.

I am not saying this change is not causing trouble on your (and others) end - just explaining what happened while we are looking into the issue.

This puzzles me (and my colleagues) - those RPN loops are run after the sim itself, whether in SU3 or SU4 (this hasn’t changed). We are trying to understand why you are seeing these differences.

Are you 100% sure your FS24 detection is working as expected? On this topic, I’d like to state once again that we do not officially support FS2020 packages that try to detect FS2024 and behave differently (or even use 2024 specific features) - even though the issue we are discussing here highlights why some developers are doing so.

Best regards,

Eric / Asobo

Yes the fs24 detection works. An lvar called 'ā€œL:FIX_FS24ā€ is set and toggles some behaviours. Not only engine behaviours but autopilot and lighting fixes.

The plane is not using any fs24 features.

I thought the point of input events were to react instantaneously. WatchVars are defined to trigger the code. Every time manifold pressure changes it would be set.