I would need to see a screenshot of that but I’m 99% sure that’s correct behaviour.
When the FLT ALT is above 37000ft the AUTO system will set ΔP to 8.35 PSI.
8.35PSID is in the amber range (Red starts at 8.9 and the FCOM limitation is 9.1) so there’s no need to take it to manual. Manual mode is dangerous and uncomfortable for the eardrums and should only be used when directed by the QRH.
Interesting. I didn’t see an amber range on the gauge, only red.
What is confusing is the chart at the base of the pressurization panel shows FL and cabin altitudes. It shows a range of 8000’ at FL400, so the cabin pressure I saw of 5000’ seemed significantly out of that range.
Is it at all possible that the gauge value(s) would be different on the BDSF vs. the passenger variant(s)?
It’s 03:45, so it’s a bit early for me to get up and do a visual check in the sim, but I will look later when the day is underway.
The chart is a rough guidance for controlling the pressurization system manually, not the auto schedule programmed in the controller, which is much more detailed and sophisticated.
Manually controlling the pressurization is a difficult task and can be very uncomfortable for your ears, something you don’t feel in msfs IRL requires a lot of practice to stay in the comfort zone.
Okay, so I just loaded into the 737 and, wow, the “amber” on that gauge looks red to me when viewing from a “normal” distance. I had to zoom in really close to see that it is not red!
I’m still hanging on MSFS2020, will move to MSFS2024 later but from the first responses it looks like the 737 doesn’t work in 24 yet. The same goes with the 777.
They pretty much said they didn’t expect full functionality of the 2020-dropped-into-2024 community folder the other day. I’m waiting for the compatibility patch in ops center before I try it. Messing around with career mode and the aircraft from aviators edition will keep me busy til then.
It seems to work by simply moving over the PMDG folders from the packages folders within LocalState and LocalCache folders. Admittedly, I haven’t had much time to fully test it, but here’s some screenshots showing it seems to be working. Will test more and report back.
Within the LocalCache > Packages > Community folder, copy these folders:
Within the LocalState > packages (need to create this folder in MSFS24), copy this folder:
These are the issues I found so far just on the initial load:
Map on the EFB flashes rapidly (basically unusable)
Displays and MCP numbers seem too dim against the sun (but fine at night)
I managed to crash FS2024 three times in a row trying to use my external keyboard to enter my Simbrief ID into the EFB. Complete crash requiring me to End Task via the Task Manager. The fourth time, I enabled the on-screen keyboard in the EFB and was able to enter my Simbrief ID. I was even able to update the Navdata. However, sometime between doing that and downloading a flight from Simbrief into the tablet, the aircraft had a WASM crash and became entirely unresponsive.
A few more in-flight screenshots for those interested. It seems to handle fine and flies the same. Positive experience so far minus the few issues noted above.
That’s still up in the air. Whether there will be any upgrade fee isn’t even mentioned in Robert’s post unless I miss it. More fundamentally, it seems to me they are at Microsoft’s/Asobo’s mercy in figuring out what has changed in how FS2024 handles the communications channels between WASM modules (the aircraft itself) and the HTML/Javascript modules used in the tablet.
If PMDG can change its code to comply with FS2024 such that the same code works in both platforms, it might lessen the level of work required and reduce the incentive to charge a fee. However, if they have to leverage some new coding technique that only works in ‘24, they would thus have to maintain two separate versions of each aircraft: that’s 4 variants of the 737 alone, plus one existing and at least one (likely two) 777 variants expected in the near term.
Remember, code compatibility between sim platforms was what MS/Asobo promised for almost 16 months before dropping an unfinished SDK into every developers’ laps a few weeks ago.
Besides a few issues noted above, the 737 works remarkably well if you accept the current limitations of the EFB. By that metric, I’d say Asobo did a good job of ensuring compatibility if you can simply drag and drop the folder and vast majority of the PMDG 737 is working as intended. It seems like most of the issues are centered around the EFB and it’s backend connection.
Some, probably 50€ per addon…
Beside that, we will need to wait months to get those aircraft available in 2024, or need to have installed 2020 and 2024.