X-Plane 10 – JARDesign Airbus A330

1-910x535

Ihr Debüt in X-Plane hatte JARDesign mit der Umsetzung des A320Neo. Seit fast einem Jahr arbeiten sie nun schon an ihrem jüngsten Projekt, dem Airbus A330 mit Rolls-Royce Triebwerken. Hoffen wir auf einen baldigen Release, denn die aktuellen Bilder sehen vielversprechend aus.

12 Comments
Inline Feedbacks
Alle Kommentare anzeigen

Wieso war es eine Frage ob derJARDesign Neo A330 kommt, oder nicht? Er ist ja schon seit geraumer Zeit in der Entwicklung und wenn JARDesign etwas bewiesen haben, dann ist es Ausdauer. Als ihr A320 erschien war er zunächst nahezu unfliegbar, während er heute der komplexeste und vollständigste Airbus unter X-Plane ist (immer noch Lücken im Bordcomputer und Flugmodell).

Was eher interessant ist, wann und in welcher Form er erscheint. Nach dem Rohrkrepierer JetDesign A330 ( http://store01.prostores.com/servlet/x-planestore/Detail?no=570 ) ist zunächst einmal der Zugzwang weg, Daher würde ich schätzen 2015.

Mir will der Sinn dieser News nicht einleuchten. Eine Frage wird gestellt, ohne Quellenangabe augenscheinlich beantwortet um letztlich die gleiche Frage umformuliert in einer Aussage nochmal zu stellen?

Wenn inoffizielle Quellen vorliegen, sollte das auch entsprechend geschrieben werden. Einer News weitere Infos entlocken zu müssen ist nicht der Aufklärung dienlich.

Hallo Andy, vielen Dank für deine Kritik! Ich als Autor habe mich auch etwas schwer getan beim verfassen dieser “News”. Im Grunde soll dieser Artikel nur darüber infromieren, dass ein A330 im Entstehen ist. Da nicht jeder so gut informiert ist wie du, kann das ledigliche darüber berichten schon Neuigkeit genug sein.
Nicht immer ist der literarische Output optimal. Daher nehme ich deine Kritik als Anlass, die News noch einmal zu überarbeiten. Ich wünsche dir einen schönen 3. Oktober

Nein nein, hier hast Du zu viel hineininterpretiert. Ich bin keineswegs informiert was das Produkt angeht, im Gegenteil. Mir war nur die “wird er erscheinen? ja! hoffen, dass er es wird!” -Mitteilung der Origninalnews ein wenig suspekt. Nun klingt ja alles ein wenig anders und schon weit einleuchtender. 🙂

Dem muß ich mich bedingt anschließen. Es ist ja kein Geheimnis, das JARDesign seit geraumer Zeit an einem A330 arbeiten. Da sie mit ihrem A320Neo vor allem Ausdauer bewiesen haben (von einer Katastrophe bis zum momentan komplexesten Airbus unter X-Plane (immer noch Einschränkungen im FMC und dem FlyByWire), gibt es auch relativ wenig Zweifel, dass sie ihren A330 irgendwann veröffentlichen werden. Allerdings werden sie sich nach dem Rohrkrepierer JetDesign A330 mit Sicherheit auch etwas Zeit lassen ihren Flieger ordentlich abzurunden, denn jetzt haben sie einen gewissen Ruf. Daher würde ich sagen 2015, vielleicht sogar noch später.

Eigentlich wäre es mir lieber gewesen, wenn sie den FMGC des 320 fertig entwickelt hätten. Er ist leider – um es mit britischem Understatement auszudrücken – in einem “remarkably low state”. Das ist wirklich schade, denn das Flugzeug insgesamt zeigt gute Ansätze. Das könnte mal was werden. Aber leider hat wohl der Kommerz die Oberhand gewonnen. Hoffen wir, dass wenigstens mit dem A330 die Entwicklung des FMGC weitergeht – wann immer das sein wird 😀

Nun, ich weiss nicht wirklich ob man beim A320 wirklich so viel weiter kommen könnte. Das Problem ist: Als dieses Projekt anfing entschied man sich die gesamte Avionic in LUA innerhalb von SASL abwickeln zu lassen. Damals war man sich nocht nicht im klaren dass LUA intern nicht mit 64 Bit umgehen kann. Geschweige denn, dass man mit gewaltigen Krücken arbeiten muß.
Was heute in diesen Fall ja intern passiert ist: SASL teilt mit, dass LUA Speicher benötigt wird. Daraufhin versucht X-Plane selbst 10 Blöcke a´30 MB innerhalb der unteren 2GB zu allozieren. Und nur dieser Speicher steht LUA zur Verfügung.

Doch nur damit kann man einfach Plattformübergreifend arbeiten ohne alle Plattformen selbst zu besitzen. Wenn ich es richtig sehe wird auch die A330 noch so aufgebaut sein.
Ob man innerhalb dieses Kontext so viel mehr erreichen kann?

Selbst Philip hat sich innerhalb der B777 und 757 immer wieder den Schädel am internen Modell von X-Plane eingerannt. Kein Wunder dass er jetzt die Seiten gewechselt hat, um die Probleme anzugehen.

Die 300 MB sind tatsächlich wenig, v.a. denke ich da an Sounds, die mit SASL komplett als unkomprimierte Wavedatei geladen werden müssen. (Man muss sich mal vorstellen: Selbst die kleine Panthera, die fast nur Defaultsysteme verwendet, braucht schon knapp 60 – 100 MB Luaspeicher (je nach dem, wie lang die Lieder sind), bloß weil man im Cockpit zwei Lieder abspielen kann…)

Beim A320/330 muss aber auch an der Programmlogik des FMC und des FBW gearbeitet werden, und das geht auch ohne massiven Speichermehraufwand. Hier frage ich mich eher, ob Lua schnell genug ist. Das Navigationsdisplay des A320 braucht ja schon ewig zum Neuzeichnen der Icons, wenn man die Zoomstufe wechselt.

Danke Karsten, für die interessanten Einsichten in die Programmier-Details.Es ist natürlich äusserst bedauerlich, dass die Weiterentwicklung durch solche Umstände praktisch verunmöglicht wird. Da lobe ich mir die “einfacheren” Entwicklungen mit C#. Allerdings ist man damit wegen .net auf Windows beschränkt, was eben für X-Plane Entwicklungen nicht gefragt ist.

Wir müssen aber auch unterscheiden zwischen Dingen, die v.a. speicherabhängig sind und Sachen, die v.a. die Programmlogik betreffen. In dieser Hinsicht wäre sicher noch mehr drin als bisher umgesetzt. Allerdings ist auch die Verarbeitungsgeschwindigkeit von SASL/Lua nicht die beste. (Wie lang es allein dauert, im A320neo die Zoomstufe auf dem Navdisplay zu wechseln… wenn der voll mit Navigationsicons ist, dauert das mehrere Selunden, bis die wieder da sind).

Davon abgesehen wäre es für sich als Profis verstehende Entwickler sicher sinnvoll, wie von Karsten unten angesprochen, C++ zu lernen (oder entsprechende Leute anzustellen) und sich die entsprechenden Testrechner zuzulegen. Oder man macht es wie X-Aviation, die ganz klar sagen, Linux und 32-Bit wird nicht unterstützt, weil sich der Aufwand nicht lohnt.

Offtopic vorweg: Das ist jetzt der 3. Versuch, einen Kommentar hierzu zu schreiben. Es wäre schön, wenn es nach dem Absenden des Kommentars eine Meldung gäbe, die mir bestätigt, dass der Kommentar gespeichert wurde oder dass er ggf. noch moderiert wird o.ä. Sonst ist das etwas frustrierend.

Ontopic: “Praktisch verunmöglicht” würde ich nicht sagen. Es gibt Sachen, die sind speicherabhängig, aber es gibt auch Dinge, die man ohne größeren Speicherbedarf implementieren könnte.

Insgesamt bin ich aber der Ansicht, dass sich als Profis verstehende Entwickler weiterentwickeln sollten, und ggf. auch lernen, native Plugins zu schreiben und eben auch den Aufwand mehrerer Testumgebungen auf sich zu nehmen. SASL bzw. Lua ist natürlich supereinfach zu lernen, weswegen es verständlich ist, dass man damit anfängt. Aber irgendwann reicht das nicht mehr.

In Carenados B1900D wurde übrigens das Mausrad-Featurer nicht in SASL geschrieben, sondern dafür liegt ein separates Plugin im Flugzeugordner.

Nun, die Entwicklung in C# oder auch Swift ist nicht wirklich einfacher, da es nur auf X-Plane eigenen Strukturen arbeiten würde. Das ganze kann man genauso gut in C++ machen, was überall verfügbar ist, aber man benötigt dann auch mehrere Rechner und muß drei(theoretisch 6) mal testen.
Das ist bei LUA nicht nötig da diese auf einer virtuellen Maschine läuft, nur kann diese eben nur mit maximal 2 GB arbeiten und die Entwickler von LUA halten es dennoch nicht für nötig eine eigene Speicherverwaltung dazwischen zu schalten, weil die das Ganze ausbremsen würde.