I keep holding off on buying 2024 due to all the reported bugs and I'm still sad to hear it hasn't been fixed.

X-Plane is a good alternative.

https://www.x-plane.com/

Unless you want realistic scenery or an up to date g1000 implementation (I love X-Plane really but because of these two points I keep going back to MSFS - maybe there are some add-ons I haven’t tried?)

When did you last try it? The scenery and GPS/FMC has come a long way in the last 20 years I've been an X-Plane casual, but not so sure how much of that was in the last few.

I’m comparing X-Plane 12 to MSFS 24. MSFS 24 is a great aid and near picture perfect when preflying real world routes, with 3D buildings and everything, and the latest G1000 implementation is pretty complete too. But X-Plane still wins on physics realism and systems fidelity. I’d be happy if there was a way to combine the strengths of the two in one simulator somehow..

I don’t know much about MSFS plugin system so I don’t know if this is possible but you can easily extract data from X-Plane and then send over to MSFS. So that you use XP as physic and model engine, only MSFS as out-the-window view.

Basic things like latitude/longitude/altitude/heading should be straightforward. But then you might have problems with mismatch scenery, like missing airports/runway, different terrain heights, etc. And then the weather synchronization is another can of worms. Matching what you see with the physic model can be challenging.

I'm still waiting for the bugs in MSFS 2020 to be fixed.

Yeah ... by now 2020 reached a beta quality, still plenty of bugs left to squash but most of them are minor. 2024 on the other side ... is just transitioning from tech demo to alpha quality. It needs a few more years to reach beta and then by 2035 or so it might actually become a reliable product.

"WASM crash?" must be one of the top live chat comments on flight sim streams these days.

I wonder if they made the same silly mistake I did and just used the 'runtime/engine name' as title of their crash report window. E.g. all games that were based on the Nebula3 engine displayed smth like "Nebula3 Assertion" in the popup window which is opened when an assert is hit or on a general crash.

It didn't take long after release that every crash in the game was because of that damn "Nebula3 Engine!?!!1", even though almost none of those crashes happened down in the engine code, but somewhere up in the game logic :)

As far as I've seen, it's generally just the WASM modules that crash, and not a full sim crash to desktop (CTD). But considering the WASM modules are usually running all of the aircraft logic, systems, flight control computers, etc. then it tends to mean a complete flight loss since you can't... well... control the aircraft anymore. I'm not sure what kind of automatic restart logic exists for crashed WASM modules, if anything. It would be interesting to see if module crash recovery is possible.

Thx - any details as to why, tough?

For me most of the performance issues with MSFS24 are now being VRAM limited. When they went to MSFS 2024 they rewrote for DX12 and while doing that upgraded a few things to look nicer. The texture management still seems to need some work.

This means that my 9800x3D/3080Ti 12GB sort of runs out of VRAM and pages when used in VR or 4K desktop. I'm in the position where the same visuals (scenery/aircraft etc) for MSFS2020 (using DX11) when compared to the newer MSFS2024 is just generally worse and a lower framerate. In VR a bad framerate makes things unplayable. For desktop use you have DLSS which helps a lot, but in VR that blurry movement really impacts clarity.

DLSS also blurs the cockpit displays quite badly when there's anything moving on them (airspeed/altitude tape, etc.). It looks like temporal blur, which is interesting because the same blur doesn't happen with their TAA (*temporal* anti-aliasing) implementation.

Yeah, DLSS looks great outside the window and for people enjoying GA and VFR it's all good. For airliners with digital displays it is harder to use, as like you said it blurs. They did talk about using some form of stencil/exclusion around cockpit displays but I think that didn't go anywhere as yet.

As a team they have a pretty tough job because the audience is all of the place for a title like that, as in people with 'I can see my house!' being made happy vs 'My pressurization gauge cross-bleed reading is below the Boeing B738 manual official figure, unplayable'.

Yep, that's the flight sim community in a nutshell.

> They did talk about using some form of stencil/exclusion around cockpit displays but I think that didn't go anywhere as yet.

They've been talking about that since the launch of msfs2020 and there's not been any movement on it as far as I know.

I found DLSS4 Preset J much much improved, I prefer it to K.

That describes what I've seen. When I first compared 2020 and 2024 in as apples-to-apples a way as I could, it seemed like 2024's frame rate was about a third lower than 2020's. This was on a 7900 XTX with 24 gigs of VRAM.

I'm waiting for SU4 before I get back into it...

VR situation was much worse. On the hardware where 2020 was OKish, 2024 was unplayable.

> gamer perception

Is there evidence to support that it's the WASM Mod format that's the issue? Based on that page it's not like MSFS2024 is even running WASM, it's simply using WASM as an IL that is precompiled into a DLL on application startup.

I wonder how much slower it is than C/C++ compiled dlls?

My experience is now a few years old, but WASM binary we had ran less than 10% slower than C++ Clang compiled native binary from the same source. And that was for rendering code which is rather CPU intensive and benefits from optimisation.

WASM is surprisingly fast.

It basically adds a bitmask to every memory access, which sounds about right for a 10% slowdown.

It likely requires major updates, no? In that case many addons are probably poorly updated and having bugs due to being rushed and haphazardly ported.

It crashes when a developer writes code that crashes, which is not uncommon; its C++.

But but WebAssembly, the sandbox, security, best of all bytecode formats ever created and all that jazz.

So it actually does crash and gets memory corrupted, when using the wrong languages, like in a regular process.

In a "memory safe" programming language you would get a panic for an attempted out-of-range access. For the user it doesn't make a difference, it's a "crash" all the same.

Already a quick look to "Known Issues and Limitations" is quite off putting to anyone thinking about doing mods.

I dunno, those look quite realistic and even a good thing for a plugin system that needs to run in a sandbox:

- The Windows API is not supported => potential security nightmare if allowed

- C++ exceptions are not supported => not surprising, game code usually forbids exceptions anyway, along with RTTI

- C++ threads are not supported => really shouldn't be needed in a plugin system,

- The GDI+ wrapper is very incomplete => surprising that they even attempt to wrap GDI+

- The WebAssembly module must be compiled in Debug mode for C/C++ code for symbols to be visible while debugging => need to compile in debug mode in order to debug, doh.

its also considered total dogshit in any serious sim and training circle too!