PMDG hat in einem neuen Video mehrere Produktupdates und Zeitpläne für Microsoft Flight Simulator 2024 vorgestellt. Robert S. Randazzo, CEO von PMDG, präsentierte darin Details zu den jüngsten Aktualisierungen der Boeing 777-200ER sowie zum weiteren Entwicklungsstand kommender Add-ons – und erklärt dabei, was WASM-Crashs mit Hirnsfrost zu tun haben.
Zwei Updates für die 777-200ER in einer Woche
Randazzo bestätigte, dass nach dem Release der 777-200ER am 1. Mai 2025 bereits zwei Updates veröffentlicht wurden. Das erste, bereits Mitte der Woche ausgelieferte Update konzentrierte sich laut Randazzo auf kleinere Korrekturen in Bereichen wie Texturen, Grafiken und Modellanpassungen, „die während des Testings durchgerutscht“ seien.
Ein zweites Update folgte unmittelbar mit Veröffentlichung des Videos, um vor dem Wochenende kritische Fehler zu beheben, die das Flugerlebnis wesentlich beeinträchtigen könnten. Nutzer werden aufgefordert, das Update über den PMDG Operations Center (OC3) zu installieren. Ein grünes Icon signalisiert dabei die Verfügbarkeit der neuen Version.
„WASM-Crash“ als Hauptproblem
Als schwerwiegendsten Fehler bezeichnet PMDG den sogenannten „WASM-Crash“, bei dem Microsoft Flight Simulator das WASM-Modul des Add-ons deaktiviert – mit dem Ergebnis, dass Bildschirme einfrieren, Schalter nicht mehr reagieren und der Flug unbrauchbar wird. Und Stichwort Einfrieren: Randazzo beschreibt das Problem als „eine Art Eiscreme-Kopfschmerz“ und führt es auf mögliche Speicheradressierungsfehler zwischen Add-on und Sim-Plattform zurück.
PMDG vermutet eine fehlerhafte Speicherzuweisung auf Seiten des Simulators. Als Metapher dient ein Bürohaus: Der Flieger wolle ein Büro nutzen, das es nicht gibt – woraufhin der „Vermieter“, also der Sim, das Flugzeug kurzerhand „vom Dach wirft“.
Die Ursache sei tief im Zusammenspiel zwischen Simulator und Add-on verwurzelt und daher nur schwer zu isolieren. Dennoch arbeitet das Team daran, kritische Codeabschnitte zu identifizieren und aufzuteilen, um den Speicherbedarf einzelner Operationen zu reduzieren. Randazzo bittet Nutzer, bei einem WASM-Crash möglichst genaue Informationen an den Support zu senden – einschließlich Flugroute, Zeitpunkt, Flugphase und konkreter Aktionen vor dem Absturz. Nur so ließe sich das Problem „triangulieren“ und gegebenenfalls beheben.
Zeitplan weiterer Releases
Randazzo stellte zudem einen aktualisierten Fahrplan weiterer PMDG-Produkte für MSFS 2020 und 2024 vor:
- 777F: Der Frachter befindet sich aktuell in Beta für MSFS 2020 und wird als neue Version für MSFS 2024 erscheinen. Der Release ist für die Woche um den 15. Mai geplant. Sollte es Verzögerungen geben, könnte sich das Datum um einen Tag nach vorne oder hinten verschieben – der 15. ist zugleich Randazzos Hochzeitstag. Glückwunsch!
- 777-300ER (77W): Der „Triple Seven Stretch“ soll voraussichtlich am Wochenende (10.–11. Mai) in die Beta für MSFS 2024 starten. Als Release-Zeitraum nennt PMDG aktuell 22. bis 26. Mai.
- 777-200LR: Die Long-Range-Variante soll noch im Mai in die Beta gehen. Die Veröffentlichung ist für Ende Juni vorgesehen.
- DC-6: Noch nicht beta-ready, da laut Randazzo „zwei Probleme“ bestehen, die voraussichtlich mit dem kommenden Sim Update 2 behoben werden. Falls das zutrifft, soll die Beta direkt danach starten. Die Testphase werde auf 7 bis 14 Tage geschätzt, danach sei ein Release für beide Simulatorversionen geplant.
- 737-Produktlinie: Die Aktualisierung des PMDG-Flaggschiffs für MSFS 2024 verzögert sich, da es sich um das älteste Produkt im Portfolio handelt. Randazzo spricht von 6.000 bis 8.000 Arbeitsstunden, die nötig seien, um die 737-Serie auf das aktuelle Niveau zu bringen. Der Prozess sei „zeitintensiv“ und laufe im Hintergrund weiter.
Persönliche Anekdote
Und natürlich geht es nicht ohne persönliche Anmerkungen: Am Rande der technischen Informationen geht Randazzo auch auf eine Zuschauerfrage ein: Im Hintergrund seines Büros seien mehrere Logbücher zu sehen. Diese dokumentieren laut Randazzo rund 40 Jahre seiner persönlichen Flugerfahrung, beginnend mit seiner ersten Flugstunde 1985 bei Executive Flyers in Hanscom Field, Massachusetts. Auch heute noch trage er seine Flüge handschriftlich ein – zusätzlich zu einer digitalen Aufzeichnung via ForeFlight.
Wer das Vide im Original sehen will:
Bei X-Plane gibt es diese ganzen WASM Probleme gar nicht, man kann sich das Leben auch selbst schwermachen
Ja, bei XPlane gibt es so vieles nicht, deshalb habe ich gewechselt….
Äpfel und Birnen … XP nutzt kein WASM. Außerdem ist WASM selbst nicht das Problem. Der Web Assembly-Standard definiert ein Bytecode-Format und Schnittstellen zwischen dem eigentlichen Programm und seiner Host-Umgebung. Grundsätzlich ist es eine gute Idee einen solchen offenen Standard für die Add-On-Entwicklung zu nutzen, nur leider scheint die Implementierung der Host-Umgebung innerhalb von MSFS alles andere als trivial zu sein. Wie Robert im Video schon sagte, ist wohl insbesondere das Thema Memory Management das größte Problem. Man kann sich offenbar nicht 100%-tig darauf verlassen, dass reservierte Speicher-Bereiche auch wirklich verfügbar sind. PMDG nutzt daher verschiedene Techniken, um die Probleme zu umgehen. Lösen kann sie nur Asobo selbst.
Oder man löst es wie Fenix und iFly: externe Applikationen und das WASM-Modul ist nur eine Bridge zum Simulator. Damit opfert man nur blöderweise den Zugang zum Marketplace und die Verfügbarkeit auf der Xbox. Der potenzielle Kundenkreis halbiert sich also. In dem Fall sind Asobo wohl die Hände gebunden, denn selbst wenn sie solche Add-Ons zulassen wollten, wird Microsoft selbst niemals das Ausführen fremder Software außerhalb des Xbox SDKs erlauben.
Das sind alles komplexe Probleme und es gibt keine einfachen Lösungen.
Starke Zusammenfassung und vielen Dank dafür 👍🏼 Hat mir viele Fragen beantwortet, die ich mir schon oft gestellt habe 😅
Das Zusammenspiel ist auch recht komplex und so richtig erklärt wird’s nirgends. WASM wurde eigentlich entwickelt, um z.B. in C oder C++ geschriebene Programme im Browser lauffähig zu machen. Normalerweise kompiliert man ja solchen Code direkt in ein Binärformat für die entsprechende Rechnerarchitketur bzw. das das Betriebssystem, also z.B. für unsere Rechner in x86-64 für Windows.
WASM definiert nun ’nen Standard für sog. Bytecode. Das ist eine Art Zwischenformat, das in einer speziellen Laufzeitumgebung unabhängig von Architektur und Betriebssystem ausgeführt werden kann. Es muss nur die Laufzeitumgebung für diese Kombination aus Architektur und OS existieren, das Programm selbst muss nicht angepasst werden. Diese Idee ist auch nicht neu. Java hat sie groß gemacht. WASM enthält außerdem Spezifikationen, wie die Programme mit der Laufzeitumgenung bzw. dem OS kommunizieren können.
Theoretisch kann man damit selbst hochperformante Anwendungen direkt im Browser ausführen. Ein Umweg über JavaScript ist nicht notwendig. Es wurde schon diverse Spiele damit direkt im Browser ohne größere Performance-Einbußen lauffähig gemacht. Die laufen aber dabei in ihrer eigenen Welt und können zwar über die Schnittstellen diverse Funktionen des Browsers steuern, u.a. auf die Objekte einer Website zugreifen und sie manipulieren, aber verglichen mit dem, was ein Flugsimulator braucht, ist das eher überschaubar bzw. ist die Komplexität in MSFS für WASM sicher um einiges höher.
Ich weiß nicht, wie Asobo das genau löst, aber trivial ist das sicher alles nicht. Ansonsten hätte man nach fünf Jahren MSFS sicher die Probleme schon viel besser im Griff. In MSFS 2020 ist es ja halbwegs stabil, wenn man von den Problemen mit dem SU 15 SDK absieht. Für MSFS 2024 wurden ja wohl große Teile der Engine neu geschrieben und ich vermute, dass daher auch der WASM-Teil leidet bzw. noch einige Dinge neu geschrieben werden müssen, die aber erstmal auf andere Komponenten warten müssen, bis alles besser funktionieren wird. Sowas dauert leider. Man sieht ja bei DCS, wie lange sie schon an ihrem Rewrite der Engine werkeln, um damit endlich Multi-Threading richtig genutzt werden kann oder Vulcan unterstützt wird.