Aktuell sorgen neue Namen in der Szene immer wieder für Aufmerksamkeit. Nachdem bereits das bislang kaum bekannte Team rund um Vector mit einer Boeing 787 auf sich aufmerksam gemacht hat, folgt nun das nächste Projekt eines neuen Entwicklers. Mit einem ersten Trailer zeigt Rhodiumcode seine Umsetzung des Airbus A350 und gibt damit einen ersten Einblick in den aktuellen Entwicklungsstand.
Der rund zweiminütige Trailer konzentriert sich dabei klar auf visuelle Eindrücke und erste Systemdarstellungen. Zu sehen sind unter anderem Aufnahmen des Außenmodells, das bereits in mehreren Perspektiven präsentiert wird. Auch das Cockpit rückt in den Fokus und wird in verschiedenen Detailansichten gezeigt, wodurch sich ein erster Eindruck der angestrebten Tiefe ergibt.
Darüber hinaus sind im Trailer bereits einzelne Systeme in Funktion zu erkennen. Dazu zählt unter anderem ein dargestelltes OANS, das auf eine entsprechende Systemsimulation hindeutet. Ergänzt wird das Ganze durch Szenen, in denen Animationen der Triebwerke zu sehen sind.
Konkrete Informationen zu einem möglichen Veröffentlichungszeitraum oder zum Preis nennt das Studio zum aktuellen Zeitpunkt nicht. Der Trailer dient somit in erster Linie als erster visueller Ausblick auf das Projekt und weniger als Ankündigung mit festen Eckdaten.
Falls er gut wird, dann ist doch super. Konkurrenz belebt bekanntlich das Geschäft. Da muss ich wenigstens dann Inibuilds nicht das Geld in den Rachen werden. 🤣
Die schaden sich doch selber mit dem Trailer, du hast einen Konkurrenten der jede Niete modelliert hat und zeigst einen A350 mit dem Außenmodell wo das Winglet 3 Ecken drin hat. Das ganze Video zeigt eigentlich nur das der Flieger noch locker 2-3 Jahre braucht um eventuell an Ini ranzukommen
Wenn man einen Flieger fliegen möchte, der jede Niete modelliert hat, sich aber fliegt wie Toaster und bei dem man immer beten muss, ob man denn diesmal ohne WASM Crash am Ziel ankommt, dann ist Ini definitiv der way to go. Ich hoffe zumindest, dass hier eine deutlich bessere Version des Fliegers kommt, denn Ini ist für mich viel Visuals und Marketing, aber leider kaum bis nichts dahinter.
Jede Wette, dass der Flieger auch WASM nutzt und entsprechend auch von den WASM Crashes betroffen sein kann.
Sicherlich wird er auch WASM nutzen, muss er sogar, wie jeder andere Flieger auch. Kann er daher auch von WASM Crashes betroffen sein? Sicherlich, werden wir dann ja sehen. Wie gesagt, WASM muss jeder Flieger im MSFS nutzen und ja, auch andere Flieger haben hier Probleme, man muss aber auch mal anerkennen, dass gerade Ini Flieger hier überproportional häufig von betroffen sind und das gerade bei einem A350 nach mittlerweile über 20 Updates über ein Jahr nach seinem Release! Und wir haben noch nicht über Unstimmigkeiten im Flightmodel etc. gesprochen, für mich halt einfach ein no go und daher freue ich mich hier über die Konkurrenz.
Man kann aber z.B. die WASM-Nutzung auf ein absolutes Minimum reduzieren, wenn man — wie z.B. Fenix und iFly — auf eine externe Lösung setzt. Leider halbiert man sich damit die potenzielle Kundschaft, weil Microsoft keine externen Anwendungen auf der Xbox zulässt.
WASM ist an sich ’ne feine Sache, aber für komplexe MSFS-Addons hat sich Asobo mit dieser Entscheidung ziemlich ins Knie geschossen. WASM/C++ kann kein Multi-Threading, Teile der STL (quasi die C++ Standard Library) fehlen oder sind eingeschränkt, Memory Allocations sind eingeschränkt (das dürfte die meisten Crashes auslösen), kein dynamisches Linking (man kann also Code nicht dynamisch nachladen, muss alles in einem großen Bundle sein) und ebenfalls sehr schmerzhaft: die MSFS WASM Runtime kann effektiv kein Exception Handling und das macht Fehler-Handling sehr eklig, als wäre man wieder in den 70ern oder 80ern angekommen.
Externe App geht dann meistens auch auf Linux nicht, da irgendwelche super-sonder-ufrufe zur Kommunkation genutzt werden, die Proton nicht abbildet.
WASM zu nutzen heißt nicht, dass es zwangsläufig Abstürze gibt. Es ist ja nicht die Technologie schuld, sondern schlecht geschriebener Code welcher Exceptions nicht behandelt, woraufhin die Ausführung einfach gestoppt wird. C++ ist nun einmal eine niedrigere Programmiersprache als JavaScript.
Ja, das Exception Handling ist ein großes Problem, aber anders als Du glaubst, weil die MSFS WASM/C++ Runtime effektiv kein Exception Handling beherrscht. WASM/C++ selbst hat AFAIK inzwischen eine eingeschränkte Exception-Unterstützung, aber die MSFS WASM Runtime unterstützt es bisher nicht. Wenn ich mir die GitHub Issues des WebAssembly-Projekts dazu so durchlese, ist das wohl auch keine triviale Änderung an der Runtime. Kann also dauern, bis Asobo die Runtime angepasst hat.
Ohne Exception Handling bleiben einem dann effektiv nur noch eigene Typen, Tuples oder gar Methoden-Aufrufe mit Seiteneffekten und Fehler-Codes als Rückgabewert. Das macht’s z.B. auch nahezu unmöglich externe Libraries zu nutzen etc. Dazu kommen weitere Einschränkungen der Runtime, gerade auch was Memory Allocations und die STL angeht. Gleichzeitig sind die Debugging-Möglichkeiten wohl auch recht eingeschränkt.
TL:DR: komplexe Addons mit WASM/C++ für MSFS zu entwickeln ist kein sonderlicher Spaß, weil die Runtime einem viele Steine in den Weg legt. Selbst erfahrene Teams wie PMDG haben damit Probleme und das erklärt auch, warum manche Sachen so lange dauern.
Das ist tatsächlich ein heiß diskutiertes Thema, gerade auch im PMDG-Forum. Die Leute von PMDG (in Form von Kok) sind nämlich der festen Meinung, dass es neben den „Programmierfehlern“ (-> Exceptions, siehe gute Erklärung von webcodr) auch völlig unverschuldete WASM-Crashes gibt, die etwas mit der Speicherallokation und dem Zugriff auf denselbigen zu tun haben.
Dann gibt es auf der anderen Seite Matt Nishan (Working Title), der an anderer Stelle (war glaube ich auf Reddit) behauptet, dass WASM-Crashes quasi ausnahmslos „Programmierfehler“ sind.
Meiner Erfahrung nach sind sowohl Kok als auch Nishan Leute, die schon einiges falsch oder einseitig dargestellt haben, daher weiß ich wirklich nicht, wer hier recht hat…
Wenn man bedenkt, wie komplex die ganze Geschichte ist, liegt die Wahrheit vermutlich in der Mitte, also sowohl Probleme im Code, als auch der Runtime selbst.
Man braucht vermutlich einen sehr defensiven Programmierstil und viel Erfahrung, um damit gut umgehen zu können und selbst dann lässt es sich nicht vollständig vermeiden. Wirklich von frei von WASM Crashes sind bisher ja nur Addons, die auf externe Software setzen, also Fenix oder iFly.
Aus meiner Entwicklersicht, finde ich Exceptions nun auch nicht gerade die perfekte Lösung für Fehler-Handling, aber sie sind in C++ nun mal der übliche Weg und auch in anderen an C++ angelehnten Sprachen wie Java. Man kann andere Paradigmen zur Fehlerverarbeitung wie z.B. in Rust mit Result-Typen übernehmen, aber das konsequent in eine größere Codebasis zu übertragen, noch dazu in einer Sprache, die nicht wirklich darauf ausgelegt ist, ist — wie man so schön auf Englisch sagt — ein Schmerz im Hintern.
Ich hab sowas selbst mal mit einer Kotlin-Codebasis versucht und hab’s später abgebrochen. Kotlin erlaubt wirklich viel an der Stelle, aber man merkt trotzdem, dass es dafür nicht so recht gedacht ist und so geht’s PMDG, iniBuilds & Co sicherlich auch.
Niemand macht das freiwillig und wenn ich zumindest meine Sicht auf sie übertrage, würde ich mich über diese Probleme noch mehr ärgern als meine Kunden. Man kann sicherlich iniBuilds für diverse Dinge kritisieren, genauso wie PMDG für andere, aber im Endeffekt wird keiner von beiden ein schlechtes Produkt verkaufen wollen. Zumal man iniBuilds auch einige Lerneffekte gesehen hat, sonst wäre der A350 immer noch der riesige Ressourcen-Fresser, der er von einem Jahr war.
Ich hatte bisher 2 mal einen WASM Crash mit dem ini seit Release, ich weiß garnicht was die Leute immer machen um das zu bekommen. Vermutlich sitzt das Problem in den meisten Fällen vor dem Bildschirm, völlig zugemüllte Community Ordner und irgendwelche Mods die das Flight Model noch manipulieren. Aber ja lasst uns alle einen Flieger als Study Level und besser hypen, wo man noch überhaupt nichts gesehen hat und von einem völlig neuen Developer kommt
Wow – gefühlte Statistik… Kennst Du? Ist fast so, wie wenn man Leuten mit einer Krankheit (die man selber nicht hat) sagt, sie/ihr Verhalten sei das Problem.
Viel besser und konstruktiver wäre es, du hättest geschrieben:
„Bei mir sind WASM Crashs sehr selten – ich hatte bisher nur 2 mal welche seit Release. Bin deshalb sehr glücklich und zufrieden, dass er bei mir so gut läuft. Schade natürlich für alle diejenigen, die mit den Crashes zu kämpfen haben. Denn der ini A350 ist ein schönes/tolles Addon.“
Lucky you, nun bist Du aber auch nicht der einzige Ini Kunde, schaue doch nur mal in den Ini Discord, in deren Forum oder sogar auf Reddit etc., da gibt es Meldungen zu Crashes noch und nöcher. Diesen Leuten aufgrund von Vermutungen allen vor den Kopf zu werfen da „säße das Problem ja vor dem Bildschirm“ finde ich schon etwas überheblich. Und hypen und sich darauf freuen, dass hier ein neues Produkt auf den Markt kommen wird, welches Ini evtl. Konkurrenz bieten kann sind für mich persönlich auch 2 unterschiedliche Paar Schuhe, aber hey… Und den Begriff „Study Level“ hat hier bisher niemand ausser Dir in den Ring geworfen, nichtmal der Entwickler selber, zumindest sehe ich davon nichts im Trailer. Und zur Erinnerung, Ini preisen ihren Flieger als „the ultimate airliner“ an, kann man nun selber bewerten, was man davon hält ;).
Oder es liegt daran, dass du ein casual simmer bist, der die Simbrief-Route in FMC legt, departure und arrival eingibt, einmal performance aus dem EFB rüberkopiert und dann das FMC nicht mehr anfasst für den Rest des Flugs. Damit ist die Chance tatsächlich sehr gering, einen WASM-Crash zu bekommen (der z.B. gerne im SEC-FPLN passiert).
Wenn man mit den Worten nicht so geschickt ist, ist manchmal besser, mehr zu lesen (und zu verstehen) als zu schreiben … 🙂
Gott sei dank kannst du nur andere schlecht machen, aber verschliess nur weiter die Augen vor der Realität …
Genau so fühl ich das bei Fslabs
Du hast schon eine eigenartige wahrnehmung von Ecken, ich konnte nicht wirklich Ecken feststellen im Trailer.
Aber als erfahrener 3D-Artist kannst du das bestimmt besser beurteilen.
Eventuell sollte man erstmal abwarten was noch kommt als gleich in den Raum zu werfen das sie sich selber schaden…
Schlussendlich muss der Flieger funktionieren und am besten ohne den ständigen WASM Crashes welche Ini teilweise bis heute hat und nicht in den Griff bekommt.
Von daher gut das auch andere Entwickler mit dem A350 kommen so wird ini doch etwas machen müssen!
Wie war das mit Ini und den Kabine? Wollten die nicht ursprünglich Geld dafür? Zumindest solange bis der Gegenwind zu groß wurde?
Sry da kann ich mit einem nicht so ganz detailierten Modell sehr viel besser leben als mit den Krankheiten welche der Ini A350 bis heute hat.
Natürlich ist es gut, das auch andere Entwickler kommen, und das auch ohne das man Ini immer runtermacht. WASM-crashes hatte ich z.B. genau einmal, und zwar in der Beta SU5, da ist das legitim. Ansonsten: keinen weiteren. Manchmal liegt das Problem auch an den abartigsten Mods, die der eine oder andere in seinen community-Ordner hat und die Ärger verursachen. Ob er sich nun wie ein Toaster fliegt, was weiter oben (nicht von dir!) gesagt wurde, kann ich nicht beurteilen, da fehlt mir das Fachwissen.
Also vorallem am Anfang hat der INI extremst Probleme damit. Ganz egal mit oder ohne Mods, man muss aber sehr wohl positiv sagen das sie sehr bemüht waren da recht schnell immer was dagegen zu unternehmen.
Ob er sich real fliegt kann ich ebenso nicht beurteilen, das kann ich aber bei keinem Flugzeug, ich könnte dir sagen ob sich ein Zug im Train Siumlator realistisch verhält ja aber bei Fluggeräten nicht 😂
Ich weiß nicht, ob das heute noch jemand liest, aber ich denke, ich kann ein wenig zur Aufklärung der „Ecken“ in den Winglets beitragen, da das Thema schon in älteren Beiträgen über den Rhodiumcode-Flieger aufkam:
Airbus hat beim A350-900 die Winglets bereits einmal überarbeitet. Die ältere Variante wirkt weniger harmonisch, etwas „verknickter“ und hat mehr Kanten als die neuere Version, die eine gleichmäßige, elegante Krümmung ohne Knick aufweist. Ich denke, was wir auf den Screenshots sehen, ist die ältere Version so wie hier bei diesem A350-900 (Baujahr 2018) von Delta:
Delta-A350-900-N506DN
Auf der anderen Seite sieht das VC jetzt schon eine ganze Ecke besser aus als das von iniBuilds, und das ist mir im Zweifelsfall wichtiger als das Außenmodell.
Immer wieder schön wie die Leute auf den einfachsten Ragebait bei solchen Themen reinfallen
Cool!
Ohne in Hype zu verfallen bin ich gespannt was deren A350 dann so kann. Die Messlatte von Texturen und Optik welche ini inzwischen vorlegt halte ich persönlich für unrealistisch und auch ehrlich gesagt in Teilen unnötig aber im Bereich Systemtiefe und Flugdynamiken wäre hier sicher ein Steigerung möglich.
Mist verdammt … mein Popcorn ist alle^^
DE
Da hat sich aber mein Browser verschluckt. Da sollte eigentlich was anderes stehen.