Während immer mehr Entwickler ihre Produkte in den MSFS24 portieren, Updates anbieten und neue Features einbauen oder zum Aufpreis anbieten, mühen sich die Entwickler bei PMDG weiterhin ab ein lauffähiges Flugzeug im MSFS24 anbieten zu können.
Im Entwicklerpost von Robert schildert er, dass es weiterhin kleine Fortschritte aber auch große Probleme gibt.
„Diese Woche gab es einige gute Nachrichten zur Plattform 2024, auf die sofort eine weitere Enttäuschung folgte.
Mit dem Plattform-Update, das Microsoft am 10DEC24 veröffentlicht hat, sind wir in der Lage, Code und Debugging in MSFS 2024 mit denselben Tools auszuführen, die wir in MSFS 2020 verwendet haben. Während das PMDG-Entwicklungsteam darüber sehr erfreut ist, haben wir schnell festgestellt, dass der Speicherzuweisungsfehler, den wir Asobo vor einigen Monaten in MSFS 2020 gemeldet haben, auch in MSFS 2024 weiter besteht und die Entwicklungsarbeit vollständig zum Erliegen bringt, da C++-Wasm-Projekte, die sich auf fortschrittliche Speicherzuweisungstechniken moderner C++-Compiler verlassen, fast sofort zum Scheitern der Codeausführung führen.
Das bedeutet, dass wir immer noch nicht in der Lage sind, Code auf der neuen Plattform auszuführen/zu erstellen/zu testen, und dass wir weiterhin auf Plattformkorrekturen warten müssen.
In der Entwickler-Community haben einige andere Entwickler Asobo bereits auf dieses Problem aufmerksam gemacht, und wir haben uns dem Chor angeschlossen, in der Hoffnung, dass es endlich behoben wird. Als das letzte MSFS 2020 SDK veröffentlicht wurde, hat es unseren Fortschritt auf dem 777F dezimiert. Wir brauchten zwei Monate Forschung und Entwicklung unserer eigenen Tools, um das Problem zu identifizieren und es auf einen bestimmten malloc()-Funktionsaufruf im SDK zu beschränken, der, obwohl von Asobo dokumentiert, offensichtlich nicht funktioniert.“
Zusammengefasst:
Der auf C++/WASM basierende Code läuft im MSFS24 nicht und PMDG ist auf Updates von Asobo angewiesen.
Allerdings gab es auch gute Neuigkeiten in Form eines Patches für die 777 Reihe im MSFS2020!
So wurde z.B. in der 777-300ER die störende Cargo Dorr Meldung eliminiert zusammen mit vielen anderen Kleinigkeiten.
PMDG 777 for MSFS v.2.00.0060 Change Log:
=================================
15013: [Systems – Wheels & Brakes] Autobrakes rotates from RTO to OFF on egnine start (rsrandazzo)
15033: [Virtual Cockpit – Geometry/Textures] Voice Recorder Switch Missing (vscimone)
15029: [Systems – Ice & Rain Protection] Icing animation not appearing on 777F (jbrown)
14998: [Virtual Cockpit – Geometry/Textures] 777F L PACK writing is distorted (vscimone)
15018: [Virtual Cockpit – Geometry/Textures] Gap between lower forward panels and padding (vscimone)
15027: [Virtual Cockpit – Geometry/Textures] Black Screw below chronometer is placed too far to the outboard side of the panel (vscimone)
15016: [Virtual Cockpit – Functionality/Click-Spots] Voice recorder switch Auto/ON missing from 77F (vscimone)
15022: [Virtual Cockpit – Geometry/Textures] 77F Different shades on MCP/EFIS Panels (vscimone)
15030: [Systems – Lighting – VC/2D] Cockpit light sources do not not illuminate when turned on (vscimone)
15015: [Virtual Cockpit – Functionality/Click-Spots] Cockpit Flood light bulbs do not not illuminate when turned on (vscimone)
15032: [External Model – Geometry] Tailcam view misplaced on 777F (jbrown)
15010: [External Model – Geometry] Cargo door panel on fwd area always bright even at night (jbrown)
15026: [External Model – Geometry] Cargo door support frame parts disappearing during door operation. (jbrown)
15008: [Virtual Cockpit – Geometry/Textures] Small gaps in the cockpit (vscimone)
15019: [External Model – Geometry] Cargo door trim gap not flush (jbrown)
15021: [External Model – Geometry] Cargo deck fuselage windows clipping cabin trim (jbrown)
15017: [External Model – Liveries] Pink texture on door L1/L2 girt clips (jbrown)
15012: [General – Unsure] Rain drops visible on glass of both cars inside 777F cargo hold. (jbrown)
14997: [Virtual Cockpit – Geometry/Textures] Mis-located cargo lock in random location on cargo main deck floor (jbrown)
15023: [Virtual Cockpit – Geometry/Textures] 777F Hole in cargo floor (jbrown)
Das Update könnt ihr über das PMDG Center installieren.
Viel Spaß und schönes Wochenende!
Hört ihr es auch? Ganz leise im Wald rufen? Ganz ganz aus der Tiefe: Das Update wird ein Vollpreisflieger. Denn anders kann PMDG nicht überleben.
Man kann es schon nicht mehr hören, immer das Gejammer von PMDG war schon im 2020 so, alle andere Entwickler Just Flight, TFDI, Leonardo Maddog ect. machen einfach, oder sind ruhig und veröffentlichen dann einfach.
Gibt es da Neuigkeiten von TFDi? Mein letzter Stand ist, dass sie auch noch am Evaluieren sind
https://support.tfdidesign.com/support/solutions/articles/62000232587-md-11-fs2024-compatibility
Die sollen erstmal ihr ILS System für den 2020 richtig auf die Kette bekommen 😶🌫️
Modern und C++ in einem Atemzug ist auch spannend.
Modern bedeutet aber auch nicht immer gleichzeitig betriebsbewährt, schnell und zuverlässig zur Laufzeit und gut les- und testbar während der Entwicklung zu sein.
Alles Attribute die man heute immernoch C/C++ zurecht zuschreibt, weswegen man es als Platzhirsch in praktisch allen Bereichen vorfindet, die eine Software-Zertifizierung erfordern wie Automotive, Medizintechnik, Bio, Pharma, Chem. etc.
Ein seriöser Softwarearchitekt/Projektmanager sollte viele Ansprüche haben, „Modern“ bei der Wahl der Toolchain zu sein, gehört aber sicher nicht dazu.
Noch was Allgemeines:
Ich kann verstehen, dass viele Leute gefrustet sind, weil die PMDG Produkte noch nicht für den 24er portiert wurden und auch weil sie befürchten neu zur Kasse gebeten zu werden. Soweit Okay.
Es nervt aber, dass hier Begriffe wie WASM, C++, JavaScript, Probleme der Speicherallokierung, etc. von einigen „Experten“ dazu verquirlt werden, uns Ihre vermeintliche „Expertise“ in Sachen Softwareentwicklung auf’s Auge zu drücken und PMDG zu sagen wie sie Ihre Arbeit machen sollen. Das fühlt sich so ähnlich an, wie bei einer Fussball WM, wo sich plötzlich jeder zum Bundestrainer erhebt.
Eine Software zu managen, zu entwickeln, zu testen, an potentiell Millionen von Kunden auszurollen, die gleichzeitig für PC (mit unterschiedlichen Betriebssystemständen und unterschiedlichsten Hardware Konfigurationen) und XBOX kompatibel sein soll und dabei MSFS2020 und MSFS2024 abdeckt und zudem noch auf eine API und ein SDK angewiesen ist auf die man keinen Einfluss hat, ist ein anderes Kaliber wie den Webshop vom Obst- und Gartenbauverein um die Ecke zu „programmieren“.
Ich weiß aus eigener, über 25 jähriger Erfahrung, dass ein solches Projekt die Hölle auf Erden ist und genau deswegen würde ich mir nicht die leiseste Spekulation darüber erlauben, was PMDG besser machen könnte.
Ist Robert also kein seriöser Softwarearchitekt/Projektmanager? Er hat schließlich das Wort „modern“ für seine PR-Mitteilung gewählt.
Bei aller, durchaus berechtigten, Kritik an seine Öffentlichkeitsarbeit habe ich bisher keinen Grund gesehen an seiner Arbeit hinter den Kulissen einen ähnlichen Eindruck zu erhalten.
Ich bezog mich mit „modern“ ja nicht auf die PR-Mitteilung, sondern auf den Foren-Eintrag, auf den ich geantwortet habe, der C++ und „modern“ als nicht vereinbar darstellt, wohingegen es in der PR-Mitteilung um einen völlig anderen Kontext geht, nämlich:
Moderne C++ Compiler vs. veraltete C++ Compiler. Da musst Du mich völlig missverstanden haben, denn ich habe ja in meinem Kommentar eher für PMDG Stellung bezogen und nicht gegen sie.
C++ ist zwar fummeliger, aber dafür ist die Performance auch sehr gut.
Ist ja alles schön und gut. Aber warum nörgeln die in aller Öffentlichkeit über Microsoft/Asobo ? Die sind 3rd Party und da hat man das gefälligst intern zu adressieren. Kein Wunder dass Microsoft die nicht näher an die Entwicklung ranlässt.
Stell dir vor Fenix macht ne 737, ups….
Sollte Fenix wirklich eine 737 Serie rausbringen, dann wäre ich dabei. Der Wechsel würde mir nicht schwerfallen.
…oder iFly vielleicht eine B747-400…
Oder Bluesky endlich eine B757/767…
Oder CSS eine 737 classic…
Es bleibt zwar abzuwarten, was Bluesky und CSS abliefern, aber wenn sie ein qualitativ hochwertiges Produkt hinstellen und sukzessive ihre Boeing-Flotte erweitern, wird für PMDG die Luft nicht nur sehr dünn sondern dann wird dieser Hersteller geradezu obsolet.
Vermissen würde ich ihn nicht…
Die 737max wurde PMDG bereits vor der Nase weggeschnappt und was iFly als Version 1.0 da abgeliefert hat, ist einfach nur top! Insbesondere hinsichtlich glaubwürdiger Flugphysik.
Und die iFly’s B38M wird mit den kommenden Updates sicher nicht schlechter.
Unerfreuliche Perspektive für PMDG.
Doch wie heißt es so schön: Hochmut kommt vor dem Fall…
(…) Doch wie heißt es so schön: Hochmut kommt vor dem Fall…(…)
Das hört man jetzt seit 3 Simulatoren Generation (FSX, P3D und nun FS2020), also beinahe 20 Jahre…
Und, PMDG gibt es immer noch und der Absatz Ihrer Produkte hat her noch zugelegt.
Diese ganzen Konkurrenzprodukte gab es früher auch schon genau so (zB. iFly 737/747).
Es ist halt seit geraumer Zeit dämlich immer und immer wieder die gleichen Substanzlosen PMDG Untergangsszenarien lesen und hören zu müssen.
PMDG verschwindet erst, wenn RR den Sack zu macht.
Und nein, die „Anderen“ packen es halt auch nicht, mal ebenso Ihre Produkte 100% hin zu bekommen. Besonders nicht in Bezug auf Performance und Stabilität,
insbesondere der Super Fenix glänzt in der Disziplin nämlich ganz und gar nicht.
Das ist gar nicht mal so abwegig, denn Prosim, die Software hinter dem A320, gibt es auch für die 737.
Da Fenix bereits eine hohe Erfahrungskurve hat, die Software an den MSFS anzubinden, würde es bei der 737 vielleicht noch ein bisschen schneller gehen.
Der Fehler besteht im MSFS2020 auch und da funktioniert es trotzdem? Hä? 😅
So wie’s RSR schreibt, ergibt das für mich als Software-Entwickler auch recht wenig Sinn. Ich kann’s mir nur so erklären, dass man eine ältere SDK-Version für MSFS 2020 nutzt, mit der der Fehler bei malloc() Calls nicht auftritt und für MSFS 2024 diese Option nicht mehr besteht.
Sofern WASM/C++ im MSFS SDK wirklich so problematisch ist, wie es PMDG nun schon über Jahre beschreibt und es immer wieder zu solch dämlichen Bugs kommt, wäre ich anstelle von PMDG schon lange dabei, die Reißleine zu ziehen und die Projekte auf eine neue Basis zu stellen. Ich würde auf einen externen Ansatz übergehen, wie’s Fenix und A2A machen. Ggf. würde sogar eine Art Bridge via Sim Connect möglich sein, um einen Großteil der bestehende Codebase in einem separaten Programm weiterverwenden zu können.
JS/TS wäre auch eine Möglichkeit, aber dann müsste man alles neu schreiben und dank der dynamischen sowie schwachen Typisierung von JS, holt man sich noch ganz andere Probleme ins Haus. TS kann das nur bedingt beheben und auch nur auf Compiler-Ebene. Zur Laufzeit können weiterhin lustige Probleme auftreten, die TS nicht abfangen kann und teils sogar erst auslöst (es suggeriert Typ-Sicherheit, die teilweise nicht da ist). Das ist schon in der Web-Entwicklung lästig genug, aber um damit eine komplexe Simulation zu bauen? Uff, nein, danke. Wobei ich in der Hinsicht auf C++ auch nicht scharf wäre. Die Sprache wird immer mehr zu einem Problem. Microsoft hat nicht umsonst C++ weitgehend aus dem Windows Kernel geschmissen und große Teile in Rust neu geschrieben (kam mit 24H2, daher auch die vielen Probleme. Es ist effektiv ein neuer Kernel.).
Es geht um die Xbox, deshalb nix externes.
Hmpf, ich vergesse die armen Xbox-Leute immer. :/
Ich frage mich aber, wie viele Leute, die einen systemtiefen Airliner a la PMDG fliegen wollen, dies tatsächlich auf der XBOX tun.
Deine Vermutung ist sogar korrekt. Das SDK was im Rahmen des SU15 ausgeliefert wurde ist scheinbar in manchen Aspekten komplett kaputt. PMDG hat sich da ja schon mit der 777 wochenlang dran die Zähne ausgebissen und am Ende doch die Flieger mit einer älteren Version gebaut, welche im 2020 noch funktioniert. Aber nun scheinbar im 2024er nicht mehr unterstüzt wird.
Und vielleicht ist PMDG hier sehr lautstark, aber sie sind bei weitem nicht die einzigen die Probleme haben mit dem Memory Management mit diesem SDK. Man hört ja auch immer wieder von Addons die einfach freezen oder sich nach einer Weile anfangen komische zu verhalten, das scheint alles im Endeffekt auf ein Problem im Speichermanagement des Sims zurück zugehen für WASM Addons.
Ich zitiere mal Hans Hartmann:
Weil man im FS2020 mit dem SU14 statt dem SU15 SDK compilieren und damit den Fehler umgehen kann. RSR erzählt da keinen Mist. Die Problematik exisiert wirklich so, wie er sie beschreibt.
Komm hier nicht mit Fakten. Der PMDG-Hate muss doch weiter befeuert werden. Böses PMDG. /s
10/10 Kommentar.
Das war mMn eine berechtigte Frage, woher soll jemand der sich nicht aktiv mit der SDK beschäftigt so etwas wissen?
Wenn dem so ist und es bisher nicht behoben ist, stell ich mir die Frage, ob Asobo/MS nicht will. Was wenn sie diese externen Entwicklungen schlicht nicht mehr „supporten“? Wer ist mächtiger? PMDG und die betroffenen Entwickler und ihre paar tausend Fans oder Asobo? Ich will die Frage einfach mal in den Raum stellen. Ist so etwas vorstellbar? Wie abhängig ist ein Entwickler wie PMDG eigentlich noch vom Flight Simulator?
Der Witz ist doch, dass viele die jetzt schon wieder maulen und lästern genau vor 7 Tagen bei PMDG die 77F gekauft haben. Dann ein Wochenende lang die Maschine von A nach Z bewegt haben und jetzt schon wieder damit durch sind und somit Zeit zum nörgeln haben…
Also die 777 muss bei mir ackern wie ein alter Gaul. Bin mega froh das sie die noch für den 20er herausgebracht haben.
Sehr interessant wie viele hier scheinbar mehr Einblick in die Entwicklung haben… Wenn das Upgrade was kosten sollte zwingt euch wer genau es zu kaufen? Richtig niemand.
Wenn hier wirklich großer Aufwand dahinter ist ist es halt irgendwo legitim sich für seine Arbeit bezahlen zu lassen, jeder der hier kommentiert und arbeitstätig ist würde denke ich auch keinen Tag gratis arbeiten gehen.
Im vorhinein ist es halt nie zu 100% möglich zu sagen wie es werden wird, also einfach mal abwarten und Tee trinken.
Kommt Zeit, kommt Rat
Wie war das doch gleich. Herr Neumann-wir hören auf die Community. Na dann Aktion Herr Neumann. Auch wir Power Simmer sind ein Teil davon.
Der Untergang für PMDG. Andere Anbieter bekommen es doch auch hin und zwar sehr sehr schnell ihr Produkt auf dem Markt zu bringen….Lächerlich PMDG
Ich wäre mit der Untergangstheorie ein wenig vorsichtiger. Alle andern Entwickler bekommen es nicht hin. Wie schon oben in anderen Kommentaren erwähnt ist der PMDG Ansatz ja nicht nur für den PC sondern auch für die XBox zu Entwickeln. Dadurch sind sie nun mal an das SDK gebunden. Und wie schon beschrieben wurde funktionieren viele der Funktionen im SDK des SU15 einfach nicht mehr. Die CRJ plagt das gleiche Schicksal und auch hier kann die funktionierende Version auf dem SDK SU14 nicht in den MSFS24 gebracht werden.
Ein paar Beispiele:
Fenix ist rein extern und funktioniert nur auf dem PC. Kein WASM, kein Problem.
Maddog ebenfalls nur auf dem PC.
iniBuilds funktioniert nativ auch auf den Konsolen allerdings sind die keine 3rd Party Entwickler mehr wie PMDG sondern direkt mit Asobo im Geschäft und haben natürlich Support und Zugang zu Dingen welche andere einfach nicht haben.
Der Frust über PMDG ist natürlich verständlich aber man muss tatsächlich erstmal darüber nachdenken warum das nicht geht und warum PMDG nicht alleine mit runter gelassener Hose da steht. Warum die ihre Flugzeuge nicht umstellen und komplett auf MSFS eigene Dinge anpassen liegt auch auf der Hand…es würde ewig dauern und richtig viel Geld kosten. Da hat es ini Builds z.B. seit Jahren einfacher mit ihrem direkten Engagement mit Asobo.
Ich denke, dass Asobo sich schnell dem annehmen sollte. Viele sehen es ja trotzdem (zu kurz gedacht) als PMDG Problem. Was wenn PMDG irgendwann dann doch auch keine Lust mehr darauf haben und sich nicht mehr auf Store compatibility einlassen. Dann wäre der Asobo Ansatz, dass MSFS am besten auf der XBOX wie auf dem PC laufen soll, gescheitert. Es gäbe dann, die PC Version mit tollen (externen) Addons und dann die XBOX Version mit Klassikern der Systemtiefe wie Captain Sim. Mit der iFly hat PMDG ja schon auch Druck bekommen.
Ich liebe meine pmdg 737_800
Wenn Sie das nicht hinbekommen kehre ich zum 2020 zurück der mit GTX und weatherforce genau so schön ist und ich meinen bravo throttle benutzen kann teilweise sogar mit Led ,was genau so ein Witz ist das man es nicht hinbekommen hat für ein400 Euro Eingabe Gerät einen ordentlichen Treiber zu programmieren.
Marketing ist, wenn ihr was macht, dass ihr sicher nie machen werden und es trotzdem macht
sprich, wenn PMDG ein Update auf den 2024er für 15€ anbietet und ihr, trotz hier rumgeschreibe von PMDG seid vor dem Untergang, ihr es trotzdem kauft, nur dass ihr schreiben könnt, warum ihr es nie mehr macht…
Wie öfter mitgeteilt das Gauge-drawing mit Javascript oder C++ über Wasm ist ein großer Einschnitt.
Ohne PMDG hätte es jahrelang im Bereich Boeing im Sim nix gegeben. Da bin ich über die Jahre froh wo ich das nutzen konnte. Die 777F macht da keine Ausnahme. Mit Airbussen wird man im Moment überhäuft…
Frag mich aber schon, wenn man sich darauf verlässt das ein altes SDK immer verfügbar bleibt, MS weiterhin offen ist für Addons, dann ist das halt strategisch schlecht. Man hätte sich überlegen müssen, mit einer externen runtime wie z.B Fenix zu arbeiten, Maddog macht das auch so glaube ich.
Nebenbei hat Just Flight die RJ in den 2024 portiert, und die läuft da wunderbar wenn der Sim denn mitmacht. Die wird da wohl vorerst mal mein Standard Airliner, die ganzen gesteeamten Flieger, das muss alles erst mal besser werden. Ich bin ganz froh das wir für den 2020 noch gute Flieger bekommen.
Ich frage mich da auch, ob nicht die Store und Xbox Kompatibilität etwas überbewertet wird. Ich kenne natürlich keine prozentualen Verkaufszahlen, aber die Kernzielgruppe scheint es nicht zu sein. Scheinbar haben die Entwickler welche ihr Flugzeug über externe Programme laufen lassen nicht nur weniger Probleme sondern auch mehr Kontrolle über die Interaktion mit dem Sim. Der Punkt mit dem nicht gefixten SDK wirkt jedenfalls nicht beruhigend. Da fragt man sich echt ob nicht durch irgendeinen Bug selbst beim MSFS2020 sogar das Risiko besteht das irgendwann nichts mehr geht. Wenn man dann noch an die desaströsen Durchlaufteiten von Updates über den marketplace denkt, scheint der Xbox Bereich wie ein 5. Wagenrad zu sein, welches unglaublich viel Zeit und Ressourcen verbraucht.
Die Xbox simmer generieren auf dem Markplatz aber auch unglaubliche Umsätze für Microsoft. Das sollte man nicht vergessen. Dadurch wurde überhaupt erst die Entwicklung des msfs 2024 ermöglicht. Der msfs 2024 wurde ja speziell für die Konsolen Kunden entworfen. Das merkt man überall auch am Design und Karriere Modus hat ein gigantisches Potenzial für die Zukunft.
malloc() kenne ich noch aus dem Studium, wo wir ein C-Praktikum hatten. Die Funktion reserviert einfach eine bestimmte Menge an Arbeitsspeicher und gibt einen Zeiger auf den Anfang des Bereichs zurück. Mit dem Speicher kann man machen was man will, z.B. alles mit „Robert ist der Beste!“ vollschreiben. Ja, es ist Fummelkram und da können schnell mal seltsame Zustände entstehen. Kann durchaus sein, dass es stimmt, was RSR da sagt. LIegt natürlich daran, dass PMDG C++ benutzt, andere Devs laufen gar nicht erst in das Problem.