Zooming in and out changes the power output.
Can we have a āforced manifold pressureā system just like the āprop forced betaā system?
for both games.
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.
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
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
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.
