Dieses Mal geht es um drei Themen. Zunächst ein erster Einblick in die neue Flight Factor A320 Ultimate, die sich inzwischen im öffentlichen Betatest befindet. +++ Dann kommen wir zu einem ersten Überblick über JustSims Riga, das für 22 Euro 50 zu haben ist. +++ Und ganz zum Schluß beschärftigen wir uns mit einer Analyse von Alan Shafto der glaubt eine mögliche Ursache über den Weathervaning Effekt in X-Plane 11.10 herausgefunden zu haben, der vor allem Taildraggern es nahezu unmöglich macht bei langsamen Geschwindigkeiten am Boden zu manövrieren.

FF A320 Ultimate

Was für ein Tag. Wenige Stunden vor Erscheinen der ersten Beta sickerte durch, dass man die A320 wohl um 19:00 Weltzeit freischalten würde. Man musste mindestens 3 Flight Factor Flugzeuge bei X-Plane.org gekauft haben um in den Genuss des Sonderangebotes von 79.95 US-$ zu gelangen.

Mit einer Verspätung von 10 Minuten wurde der Shop drastisch langsamer. Und etwas später tauchte auch der Airbus auf der Seite auf. Leider war der Shop merklich überlastet, doch beim dritten Versuch lief alles gut.

Das Resultat: innerhalb von 20 Minuten waren alle 500 Lizenzen der ersten Beta Runde verkauft.

Das Ergebnis: Wahnsinn.

Schon die erste Beta ist derart gut, dass in den meisten Fällen nicht die Simulation, sondern die Nutzer daneben liegen. Und das nicht nur bei Leuten, die derart verrückt sind die JAR Design A320 mit diesen Flugzeug vergleichen zu wollen.

Als wenn sich die JARDesign besonders an Airbus angelehnt hätte.

Wenn die Frage aufkommt mit welchen Programmen man die Flight Factor A320 Ultimate vergleichen kann, kann man fast nur ein Flugzeug nennen: die FSLabs A320.

Diese kostet jedoch erheblich mehr und wenn es um die Simulation geht, gibt es neben Bugs in der Beta, fast nur den Sound, der momentan mit der aktuellen FSLabs nicht konkurrieren kann. Außerdem sollte man die Bedienung einiger Knöpfe noch einmal überarbeiten.

Davon abgesehen ist der Vergleich bei weiten nicht so klar, wie man erwarten würde. Auf der einen Seite die Airbus Simulation auf einem normalen Rechner und auf der anderen Seite eine relativ unbekannte Simulationsplattform für den A320, der in X-Plane hinein gebastelt wurde.

Doch das ist schon mal ein Ansatz, denn diese Systemsimulation ist derart detailliert, dass sie mit Sicherheit nicht für einen einfachen Simulator geschrieben wurde.

Dies fiel im Zusammenhang mit einem Bug auf. Wie zahlreiche erste Berichte sich lustig machten (“-52°C. Wir haben wohl Pinguine als Passagiere.”), war die Klimakontrolle zu Beginn fehlerhaft. Als einige Leute sich mit diesen Detail der Simulation auseinandersetzten fiel auf, dass sogar das Klima der Kabine über die direkte Ansteuerung der Triebwerke und APU inklusive aller Ventile durchgeführt wird.

Ein kleines Detail, das im Normalfall in einem Simulator sehr grob abgeschätzt wird, wird in diesen Fall durch eine Simulation aller beteiligten Systeme erledigt.

Kein Wunder das einige Reviews interessante Details offenbarten:

https://www.youtube.com/watch?v=lm2rx-Agq1I

Das ist keine Software die für ein Spiel geschrieben wurde, sondern für ernste Ausbildungszwecke. Es werden sogar eine Reihe von Details durch diese externe Engine durchgeführt die man normalerweise in der Rendering Engine abwickeln würde. So zum Beispiel Regentropfen, oder Reflektionen des Flugzeugs.

Kein Wunder, dass die Entwickler davon träumen, ihre Software eines Tages auch für den FSX und P3D anbieten zu können. Allerdings sollte man hier keine unrealistischen Erwartungen wecken. So eine Anpassung dürfte Jahre dauern und wohl kaum über Flightfactor laufen. Und ob die Integration auch im FSX oder P3D so nahtlos gelingt wie in X-Plane müsste man erst einmal abwartem.

Sollte dies jedoch gelingen, dürfte es für FSLabs eine mittlere Katastrophe darstellen.

Alle Überlegungen die FSLabs in Bezug auf X-Plane gehegt hat dürften mit diesen Flugzeug Geschichte sein, denn sie müssten mit einem Produkt konkurrieren, das auf X-Plane ausgereift arbeitet und zu einem deutlich niedrigeren Preis angeboten wird.

Hier wird, in Bezug auf Multiplattformunterstützung, auf einem Niveau gearbeitet, von dem PMDG nur träumen kann. Die Entwickler können sich voll auf ihre Plattform konzentrieren und jede Änderung würde gleichzeitig allen unterstützten Plattformen zugutekommen.

Wenn man es mit einem anderen Flugzeug in X-Plane vergleichen will haben wir höchstens die IXEG 737 Classic und auch das nur in Bezug auf die Immersion.

Dieses Flugzeug hat das Potential die beste Simulation auf einem Heimcomputer überhaupt zu werden! Das größte Problem bei unserem ersten Testflug… Über Riga herrschten derart viele und starke Unwetter, dass SkyMaxx Pro und Riga zusammen den Rechner an den Rand der Überlastung brachten. Dazu noch ein komplexer Flieger … Obwohl, in Anbetracht der Komplexität stellt der A320 sogar recht geringe Anforderungen an das System.

Etwas lächerlich war jedoch die Auswahl der offiziellen Liveries in der Beta. Von vier Liveries eine tote Firma (Air Berlin) und eine andere, die in der Realität nur Boeing 737er einsetzt (Ryan Air). Allerdings haben die Freeware Designer sich sofort mit Feuereifer auf dieses Flugzeug gestürzt. Sobald es also die Betaphase verlässt, dürfte eine unüberschaubare Vielfalt an freien Liveries zur Verfügung stehen. So dürften die Payware Liveries wieder ausgesprochen wenige Kunden finden.

Alles in allem ein sehr interessanter Ansatz, der auf einiges Interesse stoßen dürfte, was nicht zuletzt die gewaltige Menge an Streams bestätigt, die über diesen Flieger erscheinen.

Die A320 Ultimate kann sowohl im kommerziellen Bereich kostengünstigere Simulatoren ermöglichen und gleichzeitig durch den Verkauf an Endkunden als „Spiel“ höhere Umsatzzahlen mit sich bringen. Und JARDesign wird sich stark überlegen müssen die Preise zu senken, ansonsten dürften seine Airbusse schnell in Vergessenheit geraten.

---

JustSims Riga

Kaum dass JustSim sein Riga für X-Plane auslieferte fing das Unwetter an. Immer wieder neue Gewitter. Und die Gegend ist auch mit deutlich mehr Häusern versehen als man es sich vorstellt. Beide Elemente zusammen machten diesen Flughafen echte Probleme.

Mit der neuen JustFlight Piper Arrow III machten wir dennoch ein paar Rundflüge. Das Flugzeug selbst bekommt jedoch einen eigenen, weit größeren Artikel, den wir dazu nutzen werden auch mal Flight Sim World und X-Plane genauer auf den Zahn zu fühlen. Auch das Flugverhalten der beiden Arrow III Versionen werden wir dabei sehr kritisch begutachten.

Eigentlich hat JustSim unter X-Plane vieles richtig gemacht. Wie üblich fehlen die AutoGates in der ersten Fassung, doch das sind wir in diesen Fall gewöhnt.

Wir haben den X-Plane 11 typischen Bodenverkehr. Die Fenster und Asphaltflächen sind mit PBR-Reflektionen versehen und in der Nacht gehen sehr viele Lichter an.

Außerdem hat man die nähere Umgebung des Flughafens mit einer groben Fototextur versehen.

Und man hat auch das größte Gebäude Rigas, den Fernsehturm, mit in die Szenerie integriert. Ansonsten verlässt man sich auf das AutoGen und die Straßenkarten von X-Plane 11.

Der Flughafen ist sowohl für X-Life, wie auch das sich immer stärker verbreitende World Traffic 3 vorbereitet. Und unter World Traffic 3 muss man stellenweise unheimlich aufpassen nicht unter die Räder, bzw. in die Triebwerke zu kommen.

Und wenn man die Wolken, wie auch die Gebäudedichte etwas reduziert verdoppeln sich trotz des miesen Wetters die Frameraten sehr deutlich. JustSim ist an der miesen Performance also unschuldig. Leider kam diese Erkenntnis erst nach dem Video.

---

Schwächen in der Flugdynamik von X-Plane 11.10

Wir hatten Alan Shafto ja bereits mehrfach erwähnt und vorgestellt. Der einfache Simmer kennt ihm am ehesten durch seine neue Super Cub (die er in der Zwischenzeit noch einmal deutlich verbessert hat).

Doch wir hatten uns mit ihm ja auch im Zusammenhang mit dem Update der vFlyteAir Cirrus SR20 beschäftigt. Vieles was dort erwähnt wurde basierte auf seinen Streams. Es dürfte heute kaum jemand geben, der sich intensiver mit den heutigen Flugprofilen von X-Plane auskennt, als er.

Dennoch hatte er am 26. Oktober einen denkwürdigen Stream. Wer ihn sehen möchte, ab Minute 40 geht es los:

Original Stream . Doch Vorsicht er redet über 4 Stunden.

Für alle anderen hier einmal eine Zusammenfassung. Im Grunde regt er sich darüber auf, dass er mehrere Tage Arbeit in die Isolierung eines Problems gesteckt hat und Austin Meyers hat nicht wunschgemäß reagiert.

Allerdings dürfen wir nicht vergessen, das beide in unterschiedlichen Situationen stecken. Alan versucht nun einmal mit äußerster Akribie alle Schwachstellen in seiner Super Cub aufzudecken und zu beseitigen. Dabei entdeckte er ein größeres Problem:

Bei Seitenwind macht der PropWash, oder auch Slipstream etwas seltsames, wenn der Motor nur langsam dreht. In diesen Fall wird auf den Winbdstrom des Propellers der Seitenwind einfach addiert. Das führt dazu, das unter solchen Bedingungen der Luftstrom des Propellers das Seitenleitwerk gar nicht berührt. Doch da kleinere Maschinen und vor allem Taildragger auch in dieser Lage das Ruder als Lenkunterstützung brauchen, haben sie ein Problem.

Ohne Seitenwind und bei höheren Geschwindigkeiten funktioniert jedoch alles wie erwartet. Und zwar für einen Simulator nahezu perfekt, trotz aller Schwächen die die Blade-Theorie in Wirklichkeit besitzt.

Eigentlich weiß jeder, dass die einfachen Vorstellungen der Bladetheorie in Wirklichkeit sehr grobe Vereinfachungen sind. Vereinfachungen, die bei geschickter Anwendung jedoch trotz aller Probleme zum richtigen Ergebnis führen. Das ist die eigentliche Stärke von X-Plane.

Das Problem beim PropWash ist jedoch, dass bei diesen, vor X-Plane 11 vollkommen ignorierten Effekt, eine Reihe von Dingen ablaufen, die es in der Blade Theorie gar nicht gibt.

In der Bladetheorie gibt es Dinge wie Reibung, oder Energieumformungen nur wenn Luft in Kontakt mit einem Festkörper, einen Profil, ist.

In Wirklichkeit hängt der PropWash Effekt jedoch von ganz anderen Dingen ab. Dinge die nur die Luft miteinander anstellt.

In der Grenzschicht des Luftstroms bildet sich ein sogenannter Wirbelkanal aus Turbulenzen heraus, in dem die Luft, wie von einem Festkörper geleitet wird. Dabei ist die entscheidende Größe kein einfacher Vektor, sondern die in diesen Luftstrom enthaltene Energie. Denn nur diese ist konstant, während die Luft in diesen Kanal eine Reihe von Vektoren hat. Und nur einer dieser Vektoren wird von der Bladetheorie betrachtet.

Die Geschwindigkeit des Luftstroms wird direkt hinter dem Propeller „gemessen“. Das Problem: In Wirklichkeit nimmt diese Strömungsgeschwindigkeit innerhalb des Wirbelkanals zunächst zu.

Erst im späteren Verlauf wird diese Geschwindigkeit maximal. Sie verdoppelt sich in etwa. Gleichzeitig sorgen andere Effekte dafür, dass diese Strömung sich dem Verlauf des Rumpfes anpaßt. Dieser Wirbelstrom, oder auch Slipstream, kann also in Wirklichkeit gar nicht vom Rumpf weggeblasen werden.

Stattdessen fächert er sich im Verlauf immer mehr auf und verliert seine Geschwindigkeit. Dadurch nimmt die Stabilität der einengenden Turbulenzen immer mehr ab und die Luft kann schließlich doch noch verblasen werden. Nur ist dies im Allgemeinen erst nach dem Seitenruder der Fall.

Alan schlägt also vor zunächst einfach den verdoppelten Geschwindigkeitsvektor einzutragen und diese Richtung bis zum Rumpfende  fortzuführen. Erst dort kann eine normale Vektoraddition vom verdoppelten Geschwindigkeitsvektor und des Seitenwinds erfolgen.

Um die abnehmende Stabilität des Wirbelkanals zu simulieren schlägt er stattdessen eine Einengung des Wirbelkanals vor ,um damit den sinkenden Einfluß des Seitenruders darzustellen.

Auf der anderen Seite haben wir allerdings Austin Meyers, inklusive seines Stolzes auf sein Flugmodell, für das er bekannt wurde.  Inzwischen ist er allerdings ein wenig älter geworden. Er hat allerdings auch gelernt, das viele Entwickler zunächst ihre Vorschläge gar nicht richtig durchdacht haben. Um abzuwimmeln lautet seine Standardantwort also: „Ich glaube dir nicht. Beweis es mir.“

Damit bestätigt er scheinbar den Eindruck eines bornierten und teilweise weltfremden Entwicklers, als der er häufig genug, wahr genommen wird.

Er hat zu viele, auf den ersten Blick scheinbar geniale Einfälle erlebt, die im Endeffekt das ganze Kartenhaus des Flugsystems zum Einsturz brachten.  Er weiß also aus Erfahrung, dass es dumm wäre, mitten in der Hitze des Gefechtes, die Gleichungen einfach so umzustellen.

Mit dieser Antwort erreicht er zweierlei. Zum einen zwingt er den Bittsteller das ganze Problem noch einmal aus einer anderen Perspektive zu durchdenken. Aus der weiteren Argumentation kann man recht gut ablesen, wieviel Ahnung der andere vom Thema überhaupt hat und wo diese Theorie vielleicht ihre Schwachstellen hat.

Austin hat schließlich ein weitaus größeres Problem. Eine scheinbare Lösung kann die Problematik dieses Entwicklers vielleicht lösen, doch für so manchen anderen neue Probleme aufwerfen. Durch diesen Code müssen schließlich nicht nur Taildragger, sondern auch Flugzeuge mit Bugrad, Jets und Helikopter. Ein Irrtum kann sehr viel zusätzliche Arbeit machen.

Außerdem hat er gerade das Problem, dass er in einem Betatest steckt. Was viele nicht wirklich sehen: Er ist zwar der Chef des Unternehmens, er ist aber nicht der Chef von X-Plane! Was ihn faszinierte war vor allem das Flugmodell. Doch X-Plane ist im Laufe der Zeit weitaus größer geworden. Daher ist der Leiter vom Desktop Programm X-Plane Ben Supnik. Und dieser Leiter sitzt gerade seinem “Flugmodell-Entwickler” Austin Meyers im Nacken, weil es soviele Fehler beim Flugmodell gibt.

Doch auch Austin dürfte nach dieser Argumentation von Alan schnell erkannt haben, dass die Lösung dieses Problems wohl in etwa so aussehen sollte:

Nur hilft dies dem Entwickler natürlich nicht weiter. Dieser möchte wissen, wann endlich das Problem behoben sein wird. Doch das kann man noch gar nicht sagen. Es deutet sich jedoch an, dass die Problematik noch einmal neu angepackt werden muss, da man etwas zu einfach gedacht hat.

Ein weiterer Punkt ist natürlich auch die Tatsache, dass Austin zugleich Chef von Laminar ist. Die Version 11.10 hat die primäre Aufgabe schnelleren Code zu liefern. Und teilweise dürfte man diesen Zeil auch näher gekommen sein. Nur besteht die Lösung nicht einfach darin die alten Einstellungen beizubehalten, sondern teilweise wurden im Untergrund die Metriken umgestellt, so dass die eine Änderung eines Parameters eine ganz andere Wirkung erzielen könnte als noch unter X-Plane 11.05 .

Alle anderen Auswirkungen, wie eine Verbesserung des Flugmodells, sind für den Chef von Laminar nur angenehmes Beiwerk.

Doch für eine ganze Reihe von Entwicklern könnte es doch auf, zumindest temporären, Korrekturcode hinauslaufen.

Alans Argumentation scheint zumindest in sich schlüssig zu sein und seine Argumentation könnte auch eine Erklärung für einige andere Probleme liefern.

Ben weist wohl nicht ohne Grund wieder verstärkt darauf hin, dass X-Plane beim Flugmodell die Versionsnummer des PlaneMaker berücksichtigt, um den Simulationscode festzulegen. Bei einigen Flugzeugen bestand die Lösung auch tatsächlich einfach darin das Flugzeug in der neuesten PlaneMaker Version zu laden und wieder zu speichern. Allerdings weist Ben darauf hin, dass vermutlich alle Default-Flugzeuge eine Nachjustierung benötigen.