Dressler1110

I completely agree with keeping things civil and on-topic. While I understand that MSFS/Asobo have their own inherent quirks with the WASM environment it is difficult to accept that this is purely a simulator-level issue. The reality is that the A350 suffer from WASM crashes and freezes at a significantly higher rate. Technically speaking, since MSFS WASM modules are compiled from the developer's source code (e.g C++), the sim's environment is only executing what it's given. If there is a memory leak or an unhandled exception in the source code, it will inevitably manifest in the compiled .WASM. . It is very telling that your specific WASM CTDs/freezes typically occur after several hours into a long-haul flight (ghost WASM ctd). . When I've experienced CTDs with other developers' aircraft, they usually happen during specific logic triggers (e.g., executing a complex SID/STAR, or specific FMC inputs). A crash that happens predictably after X amount of hours is the textbook symptom of a memory leak in the aircraft's own code. If the root cause was entirely Asobo’s WASM implementation, your previous updates wouldn't have been able to successfully patch out many of the crashes and memory leaks that the A350 had at launch (horrible launch). Blaming the simulator’s WASM environment feels like a deflection from addressing underlying memory management issues or any other errors within the aircraft's own codebase. We all want the A350 to succeed, but transparency regarding these code-level issues would go a long way with the community. Thank you.