Um die besten Erlebnisse zu bieten, verwenden wir Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wenn Sie diesen Technologien zustimmen, können wir Daten wie das Surfverhalten oder eindeutige IDs auf dieser Website verarbeiten. Die Nichteinwilligung oder der Widerruf der Einwilligung kann sich nachteilig auf bestimmte Merkmale und Funktionen auswirken.
Die technische Speicherung oder der Zugriff ist unbedingt erforderlich für den legitimen Zweck, die Nutzung eines bestimmten, vom Abonnenten oder Benutzer ausdrücklich angeforderten Dienstes zu ermöglichen, oder für den alleinigen Zweck, eine Kommunikation über ein elektronisches Kommunikationsnetz zu übertragen.
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Die technische Speicherung bzw. der Zugriff dient ausschließlich statistischen Zwecken.
Die technische Speicherung oder der Zugriff ist unbedingt erforderlich für den legitimen Zweck, die Nutzung eines bestimmten, vom Abonnenten oder Benutzer ausdrücklich angeforderten Dienstes zu ermöglichen, oder für den alleinigen Zweck, eine Kommunikation über ein elektronisches Kommunikationsnetz zu übertragen.
Die technische Speicherung bzw. der Zugriff ist erforderlich, um Nutzerprofile für den Versand von Werbung zu erstellen oder den Nutzer auf einer Website oder über mehrere Websites hinweg für ähnliche Marketingzwecke zu verfolgen.
Jetzt nochmal warten, bis die P3D Version raus kommt….uff…
Du musst es positiv sehen: technisch ist der P3D dem FSX viel zu ähnlich als dass man tagelange Warterei damit begründen könnte. Aber der P3D bietet mehr Möglichkeiten. Was ich sagen will: jede Minute warten wird vermutlich in eine Verbesserung des Produktes gepackt. Und ich möchte stark wetten, dass mit dem bekannten Wrapper+Austausch einiger Dateien die FSLabs auch im P3D rennt so wie es die Majestics und PMDG’s auch tun. Als Customer interessiert mich die Lizenzproblematik der Hersteller recht wenig.
Hm, im FSLabs Forum wurde klar veröffentlicht, dass man die FSX Version jetzt kaufen kann und später auf P3D upgraden kann, indem man den Differenzpreis zahlt. Man hat dann beide Lizensen.
Ich hatte vor einiger Zeit mal FSX Steam für 5$ gekauft. Jetzt schnell geladen und den Bus gekauft. Für erste Flüge bis die P3D Version kommt ist das allemal gut, zumindest wenn man nicht warten kann, wie ich.
Noch der Link:
http://forums.flightsimlabs.com/index.php?/topic/7765-a320x-license-upgrade-path-clarification-request/
finde ich sehr fair!!
Nee, ich warte, FSX kommt mir nicht mehr auf die Platte… 🙂
Also ich habe mir beide Videos angesehen- und muss sagen – nachdem ich bereits 100erte Stunden mit den Aerosoft Airbussen unterwegs war – dass ich diesen Hype nicht ganz nachvollziehen kann.
Die Leute sind ja “richtig narrisch” auf dieses “Gerät” – ich hingegen bin´s noch lange nicht – und ich glaube, dass so “mancher”, wenn er dieses Teil erst auf der Platte hat und damit fliegt- sich einem Déjà-vu-Erlebnis ausgesetzt sieht!?
Nur, wenn man sich nicht tief mit der Mechanik des A320 auseinander gesetzt hat. Das war ja auch das Ziel von Aerosoft. Die täglichen Handgriffe eines Piloten abzubilden. Aber das Timing (APU+Eng spoolup times), die Berechnung der Fluids (ich sag nur: “Leute, ihr könnt aufhören nach dem Bug zu suchen. Das ist ein Bug im echten Bus!”), die 3D Sounds, allein das Verhalten und das Auswirken der Cargodoors auf die Hydraulik, das Wirken der PTU, die reale Umsetzung des Managed und Open Descent… das sind Featurs die hat der AS 320 einfach nicht.
Diese Umsetzung von FSLabs ist für Freaks gedacht welche auch bis in die letzte Simulationskante gucken. Schonmal versucht ohne Hyd Pressure im Accu trotz gesetzter Parking Brake die Engines zu starten? Der FSLabs rollt weg! EDDL… Bergauf, AntiIce rein, N1 geht hoch, der Berggang ist aktiv.
Der Hype resultiert daraus, dass einige Leute doch mehr technisches Wissen vom Bus haben und von Aerosoft enttäuscht waren. Hier wird sogar das Schwabbeln im Fuel tank berechnet.
Ich hätte müssen auf meinem Flug nach Spitzbergen sogar die FL senken damit der Fuel nicht freezed. Ich tat es nicht… bis #1 ausfiel und ich runtergehen musste. Hell, hier ist sogar Vogelschlag simuliert.
Auch diese klicks wenn Du einsteigst und die Batt’s aktivierst und dann ext. Power. Im ASE fühlt es sich so komisch an. Hier hörst Du das klickern der Relais.
Pack high, low? Spielt hier eine Rolle. Du hast eine Weile auf einem Feld bei hoher Temp gewartet? Dann schalte besser Cargo Cooling auf low. Selbst die Bremstemp. Fühler gehen nicht gleich nach einer Vollbremsung hoch; nein hier wird die Abgabe der Hitze an die Umgebung simuliert bevor die Fühle Hitze registrieren. Auch nach einem GearUp steigt erst nach einiger Zeit die Hitze ein klein wenig an.
Das sind so kleine Details die einem weniger technischen Nutzer nicht auffallen; dieser wird mit dem ASE vorlieb nehmen. Aber wenn man genauer hinschaut, dann ist das der erste echte Bus!
Das kann ich unterschreiben. Mir macht der AS Bus immer noch Spaß, vor allem da ich den A319 mehr mag als den A320 ^^.
Aber seit letztem Donnerstag fliege ich nur noch den FSLabs Bus wegen den von Andy genannten Gründen.
Schaltet mal beim AS Bus die komplette Hydrulik aus. Das Teil fliegt im AP immernoch fröhlich umher, trotz dropender Ailerons im Flug. Schaltet mal Ext-Pwr aus. Gibt es einen unterschied?
Usw. usw.
Die Liste der “Ungereimtheiten” beim AS Bus ist lang. Wer irgendwie damit so ungefährt Airbus fliegen will ist sicher bedient. Wer aber will, das sein Knopfdruck irgendwas “systemtechnisch” bewirkt und nciht nur das Lämpchen ausgeht (z.B. AS Bus Fuel pumps…), der kommt hier an einem Kauf vorbei.
Gut, vielleicht ist es auch eine Berufskrankheit, dass ich als Ingenieur es auf den Tota nicht leiden kann, wenn Sachen nicht technisch korrekt modelliert sind… 🙂
Korrekt! All das was du schilderst, resultiert in einem, die
mich noch nie dagewesenen, “Mttendringefühl”!
Der AS Airbus war nach etlichen Updates ein guter Lückenfüller, aber die Leute die Hardcore-Simulation suchen, und sich in der NGX, der Q400 oder der LSH Maddog wohlfühlen, hatten kein Äquivalent in Sachen Airbus.
Nun ist das anders, der FSL A320X hat die Latte neu positioniert, das Teil ist der schiere Wahnsinn! Und mit der Ankündigung, dass man nur das Delta beim Crossgraden auf die P3D Version wird zahlen müssen, ist diese Software ein absolutes Muss für den realitätsverliebten Simmer und definitiv jeden Cent wert! Der AS Airbus wird in den verdienten Ruhestand geschickt!
Die Sache ist ganz einfach…
Für einen Flug von A nach B in Airbus Optik ist der Aerosoft Bus völlig in Ordnung. Der Sound das Feeling usw sind toll gemacht und wenn man nicht in FMGS rumspielt wie wild passiert auch nix.
Der FSL ist einfach eine wesentlich tiefere simulation.
Der Fokus ist ein ganz anderer was sich auch im Preis widerspiegelt.
Zudem ist die Performance deutlich besser als die Jungs von aerosoft das hingekommen haben.
Möchte man viele ModellVarianten zu einem günstigen Preis fliegen und dabei einen Airbus ähnlichen Flieger bedienen nimmt man AS A320 usw …
Möchte man eine Airbussimulation die wesentlich tiefer geht und alles andere in dem Bereich übertrifft dann greift man zu FSL und zahlt halt etwas mehr.
Rgds PC
“Die Leute sind ja „richtig narrisch“ auf dieses „Gerät“”
Zu einem gewissen Grad nachvollziehbar. Die Leute warten auch schon 6 Jahre auf den ersten Airbus, der diesen Namen auch tatsächlich verdient. Die Herrschaften von Flightsimlabs haben Wort gehalten und sind ihren Ankündigungen gerecht geworden.
“sich einem Déjà-vu-Erlebnis ausgesetzt sieht!?”
Ein Déjà-vu habe ich eher bei den Reaktionen auf einen solchen Release:
typische Preis-Quängeleien (“geschenkt wäre noch zu teuer”)
Auch gegen weitere Vorteile wird argumentiert “Release in Raten” ist für ein solch mächtiges Produkt beispielhaft und keine Schikane.
Die Frage: “Warum überhaupt?” stellt sich auch nur dann, wenn man mit dem Konzept die Wahl zu haben, noch nicht gänzlich vertraut ist.
Fragen in der Qualität von “Wird es einen A380 geben?” Nachdem man eben das erste Modell der A320 Familie hergestellt hat.
Dicht gefolgt von Fragen der Güte “Ist XY umgesetzt?”, weil man das Vokabel irgendwo aufgeschnappt hat und man damit die eigene Expertise hervorheben möchte.
Der Typus “Hobby-Skeptiker” mit der Frage an die Community, “Warum auf ein vollständig simuliertes Produkt umsteigen?” ist auch legendär.
Wenn es eh das AS “Dingens” gibt. Wer sich diese Frage nicht von ganz alleine beantworten kann, sollte bei seinen Leisten bleiben. Weil es Arbeit ist, sich in ein solches Produkt einzuarbeiten. Wer schon nicht von alleine herauszufinden in der Lage ist, was es bedeutet, mit einer vollständigen Airbus Simulation konfrontiert zu sein, wird den Möglichkeiten des Produkts höchstwahrscheinlich nicht gerecht werden und ist mit dem was man hat sehr gut bedient.
Von A nach B kommt man schließlich auch mit den FSX-nativen Modellen und mit dem
“Dingens”
Vergleiche die sich nicht anstellen: “Vollständigkeit”
ProduktX (nach 100en Hotfixes) mit ProduktY (RTM)
und das als Vorteil des einen Produktes hervorzuheben.
Und es verliert auch gerne ein Mitbewerber nicht notwendiger Weise die Contenance, um dann wieder zurückzurudern.
Wahnsinn. PMDG Qualität in einem Bus. Das hätte ich niemals für möglich gehalten…
Das war doch von vorne herein klar Dieter, wenn man die Hintergründe kennt und weiss wer eigentlich PMDG gegründet hat.😉
LG
Endlich einmal ein paar “harte” Fakten über den FSLabs Airbus – vielen Dank @Andy und @FreaXter!
Gefällt mir – …wahrscheinlich kaufe ich diesen Bus!
Ansonsten hat man bisher wenig bis gar nichts erfahren über diese Airbus-Simulation “die nicht nur eine Simulation eines Airbus-ähnlichen Modells darstellen soll” (Zitat).
Auch auf AVSIM gabs nur ein Gezerre auf 1000enden Nebenschauplätzen- worauf der Thread in Gefahr geriet, durch den Moderator geschlossen zu werden.
Also bisher wenig substantielles hier auf simFlight – obwohl wir sogar einen echten Flugkapitän “in unseren Reihen” haben.
Gerne hätte ich gewusst, wie Oski (he knows everything) Wagner die Systemtiefe beurteilt.
Der meldet sich meistens auch nur dann wenn es hier “hoch hergeht” .. Hey Jungs, kriegt euch mal wieder ein…
Hallo Walter,
Danke für die Blumen, aber zuviel der Ehre. Gottseidank weiss ich nicht alles! 😀 Da du mich scnon zitiert hast, möchte ich mit einem kleinen Beispiel zur Systemtiefe daran anknüpfen, weshalb ich den FSL Bus als Airbus Simulation und nicht nur Airbus-ähnliche Simulation bezeichne. Einer der Hauptdatenkanäle im Airbus ist der sogenannte ARINC 429 Datenbus. Vereinfacht gesagt, gibt jeder Sensor und jedes System seine Signale und Flags auf diesen Datenbus, und jeder Sensor und jedes System liest daraus die Daten, die es für seine Funktion benötigt. Also alle Daten werden auf diesem Datenbus hin- und hergeschickt, und jeder, der was davon braucht, nimmt sich seine Informationen.
Während nun eine Airbus-ähnliche Simulation ein paar Fehlzustände mit einer einfachen Wenn-Dann Logik signalisiert und ein(e) entsprechende(s) Warnung oder Systemversagen simuliert, ist beim FSL Bus dieser ganze Datenbus simuliert. Das System funktioniert damit genauso wie im “richtigen Leben”. Also jeder Wert eines Systems oder Sensors wird auf dem Datenbus transportiert und von der “zuständigen Stelle” interpretiert und ausgewertet. Das heisst natürlich auch, dass praktisch jeder Sensor ebenfalls simuliert sein muss und die entsprechenden Daten an den Datenbus sendet. OK, ich kann es nicht deutlich genug sagen, dies ist eine starke Vereinfachung. Aber man kann vielleicht erahnen, was für eine immense Arbeit dahinter steckt, zumal von Airbus direkt natürlich keine Auswertungsmatrix zu kriegen ist. Die Verknüpfungen mussten für jedes System aus dem FCOM herausgearbeitet werden.
Was heisst dies nun für die Simulation? Nichts weniger, als dass eigentlich die gesamte Systemtiefe des Airbus simuliert werden KANN! Dass hier bei den Tausenden von Verknüpfungen noch Fehler vorhanden sind, ist unter diesen Bedingungen logisch. Wesentlich ist aber, dass die Voraussetzungen geschaffen sind, eine 100%ige (oder jedenfalls nahezu) Simulation zu generieren!
Wenn man bedenkt, dass allein der Beta-Test ein Jahr gedauert hat, lässt sich erahnen, wieviel Detail-Arbeit hier geleistet wurde und – da ja bekanntlich der Teufel im Detail steckt – noch zu leisten sein wird. Aber eben – die Voraussetzungen sind im Gegensatz zu andern Simulationen von “Hause aus” gegeben, dass eine nahezu 100%ige Simulation möglich ist. Das ist in der Geschichte der Flugsimulation, wie wir sie betreiben, mehr als ein Meilenstein!
Diese ARINC geschichte würde sicherlich klarer mit Hilfe eines Beispiels Oski !
http://lmgtfy.com/?q=arinc+wiki&l=1
Hatte ich natürlich schon gemacht. Nur wie programmiert man das ?
Mich würde interessieren (am besten anhand eines Beispiels) wie die “klassische” Programmierung es macht und wie FSL es macht mit Arinc.
Die Frage ist sehr… sagen wir realitätsfern. Hast Du die Frage welche Du gestellt hast auch verstanden?
ARINC ist ein Protkoll. Ähnlich TCP, UDP ICMP etc pp. Es definiert die Art des Datentransports. Möchte man in seinem Programm nun dieses Protokoll verwenden, definiert man Klassen/Methoden (Objective vs classic programming style), implementiert das Proktoll entweder von selbst oder importiert SO’s/DLL’s welche definierte Abfragen zulassen (vermutlich letzteres das immer irgendwo Lib’s liegen welche die RFC’s zu 100% abbilden). Meinem Verständnis nach dürfte 429 auf OSI 3-5 aufsetzen und ein wenig Ähnlichkeit mit UDP haben da keine gezielte Kommunikation stattfindet sondern in den “Bus gebrüllt wird” ähnlich dem veralteten CIDR-Verfahren.
Um Deine Frage zu beantworten: Schreib Doch mal ein einfaches .net Programm mit einer einfachen UDP Kommunikation. Anschließend suchst Du dir die entsprechenden Standards, liest und verstehst sie und dann kannst Du selbst auch ein kleines Bus-System realisieren. So schwierig ist nicht obwohl AIRIC429 steinalt ist in meinen Augen.
Danke für die Antwort. Ob ich meine eigene Frage verstanden habe ist gut! Ich glaube ich habe mich schlecht ausgedrückt.
Aus Oski’s Ausführungen könnte man den Eindruck haben dass eine wirklich komplette Simulation NUR möglich ist wenn man auch das Arinc429 simuliert.
Die 737 benutzt auch Arinc429 und die 777 Arinc629. Pmdg hat beide zur Perfektion simuliert(da sind wir uns doch einig glaube ich) ohne Benutzung der entsprechenden Arinc Protokolle (Jedenfalls war nie die Rede davon).
WAS also kann ich MEHR mit Hilfe von ARINC? Das ist meine Frage.
Zugegeben bei Benutzung von Arinc ist das Programm intern noch näher an der Realität dran aber mir als virtuellem Piloten dürfte es doch egal sein ob die Simulation Arinc benutzt oder irgendeine programmminterne Kodifizierung.
Ich möchte Oski’s Worte nicht in Frage stellen. Nur verstehen möchte ich sie. Aber mit meinen sehr begrenzten Progammierkentnissen wird das wohl nicht möglich sein.
Stell Dir den ARINC-Bus des A320 eher wie ein Patchpanel vor. Jeder Sensor hat dabei seinen eigenen Anschluss. Aber eben auch die Computer welche die Daten für die DU aufbereiten und schließlich die DU (DisplayUnit) welche die Daten schließlich in ein Lesbares Format bringt und im Cockpit anzeigt. Theoretisch könntest Du quasi über einen Anschluss eines der vielen Fuelsensoren Pings auch am elektrischen Actuator am Höhenleitwerk empfangen. Soweit ich noch weiß hing alles an einem Bus.
Die 737 verwendet zwar das Protokoll verwendet aber eher eine serielle Kommunikation zwischen Sensor und Ausgabegerät.
Wenn man programmiert kann man mit einem switch-case sehr sehr viele if-then’s einbauen. Das funktioniert bei einer 737. Bei einer 777 wird es schon sehr komplex, aber es geht. Beim A320 jedoch müsstest Du 60.000 if-then’s schreiben. Und das schlimme ist, dass diese auch noch je nach Bedingung anders reagieren müssen, d.h. Du hättest noch Auswertungen innerhalb dieser Anweisungen. Genau dies ist derartig komplex und der Grund wieso viele Schmieden daran scheidern.
FSL ist den anderen Weg gegangen und hat einfach mal das Bus-System nachgebaut. Sie brauchen keine If-Then’s oder switch-case Anweisungen. Sie schicken die Signale einfach in die Logik und gucken was rauskommt. Dazu aber, und genau das hielt RSR für unmöglich, muss man alle Sensoren und Verarbeitungseinheiten (über 60.000!) implementieren und mit einer eigenen Logik versehen. Und genau diese Logik herauszuarbeiten ist das Schwierige an der Sache. Hier gibt Airbus nur die Informationen bekannt welche Piloten und Techniker brauchen. D.h. FSL brauchte Zugang zu Piloten, Technikern, FCOM’s, technical Advisories und Prüfanleitungen für Techniker sowie Systembeschreibungen. Der Zugriff zum FullMotion-Sim war nötig um Wissenslücken durch Prüfen und Probieren zu schließen.
Danke für die ausführliche Antwort !
Da auch FSL uns keine Hardware(Bus) liefert sondern nur Software muss die komplexe Logik des A320 irgendwie PROGRAMMIERT sein.
Soweit ich das jetzt verstehe hat FSL nicht einen “Switchcase” mit 60000 ‘If-Then’ sondern einen Bus mit seinen 60000 “Logiken” für Sensoren und Verarbeitungseinheiten programmiert.Dumme Frage eines Laien: Beinhalten diese Logiken denn keine ‘If-then’?
Mir fehlt sicherlich das nötige Grundwissen um das alles zu verstehn aber ein Beispiel einer einfachen A320 Funktion und deren (vereinfachte) Darstellung in beiden Systemen könnte sicher zu mehr Klarheit beitragen. (meine Frage vom Anfang)
Doch, diese Logiken enthalten if-thens. Mir fällt es schwer es korrekt zu formulieren…
Beim FSL gehst Du in das System direkt und hast dort deine if-thens. Ausschlaggebend ist hier aber die Datenherkunft der Werte. Beim FSL hast Du die Werte über das Bussystem simuliert. Bei anderen Produkten gibt es dieses Bussystem nicht. Das bedeutet dass Du Änderungen umfangreich prüfen musst. Das wird exponentiell schwieriger je mehr Komplexität Du reinstopfst. Bei 60.000 Statements kannst Du nicht Zeile für Zeile durchgehen und gucken wo noch eine Auswertung erfolgen muss.
Wenn Du aber ein Bussystem hast welches in der Main einfach weitere Methoden aufruft und die Werte übergibt kümmerst Du Dich nur um 1 System.
Einfaches Beispiel die FBW Computer:
klassisches if-then:
– Nehm Input von Spieler und gucke ob Werte OK -> sende an Höhenruder
– if alternate oder direct law = verhalte dich entsprechend.
Dann machst Du Dir die Mühe die Bedingungen für die Law’s zu suchen und zu programmieren wann welcher aktiv ist. Dabei passieren Fehler; seien es menschliche oder weil du nicht immer an bestimmte Dinge gedacht hast.
Beim FSL:
– Input von Spieler ist X
– sende Input an die FBW Computer
– FBW Computer geben korrigierte Werte zurück
– sende diese Werte an Actuator
Dann hast Du hier eine einfache Logik drin, dass die FBW Computer nur im Normal Law diese Bewertung vornehmen. Dann hast du eine weitere Funktion welche bestimmt unter welchen Umständen der Normal Law aktiv ist. Du arbeitest hier also sehr sehr sehr modular. Und du bist gezwungen jedes System wie im realen Bus nachzubauen.
Nehmen wir ein weiteres Beispiel: wenn man knapp mit Fuel plant und in den Sinkflug geht, kommt eine Fehlermeldung im EICAM. Ich weiß nicht welche – diese Info müsste Oski beisteuern. Aber: bei der klassischen Umsetzung müsste man das jetzt mit if-then programmieren. In etwa so: “if Fuel less than X kg and FPS -1000 then message”. Beim FSL brauch man eben jenes nicht programmieren. Das ergibt sich einfach aus den Gegebenheiten welche existieren einfach weil die echten Sensoren nachgebildet wurden. Hier gab es in der Alphaphase einen Fehler welchen Andrew versucht hat nachzustellen und auszubügeln wo aber ein Pilot meinte, nene lass ma das nen echter Bug vom Bus.
Welch ein langes Kommentar; sry für TL;DR.
Wow! Vielen Dank für die Mühe und die ausführlichen Erklärungen !
Ich nehme an die Instruktion “If Fuel, less x kg the message” gibt es auch bei FSL , aber wahrscheinlich nicht im MAIN program sondern in einer SUB-funktion des entsprechenden Sensors. FSL liefert uns ja keine Bus-hardware sondern eine programmierte Simulation des Bus.
Ich glaube ich habe jetzt eine bessere Vorstellung von der Sache. Das Main program ruft nur die einzelnen Funktionen des Bus und der Sensoren auf (60000 Stück) Somit ist die Programmierung sehr modular und entspricht gleichzeitig dem realen Ablauf.
Nochmals Danke für die Mühe und die Geduld !
Was mich besonders plagt bei diesem Flugzeugtyp (nicht in dieser Simulation) ist, ob die Piloten wissen welche Ereignisse wie verknüpft sind um Beispielsweise die Schubumkehr aktiv werden zu lassen. Ist die Schubumkehr programmäßig über numerische Operanten so gestaltet, dass die Maschine am Boden sein muß und dieses durch die sich drehenden Räder bestätigt wird. So darf eigentlich die Schubumkehr bei kräftigem Aquplaning, obgleich das Fahrwerk eingefedert ist, nicht ansprechen.
LG Cundri
Moin Cundri,
am 14. Sept. 1993 hat es unter anderem aus diesem Grund ein Flugzeugunglück in Warschau mit einem Lufthansa-Airbus gegeben.
(s.a. https://de.wikipedia.org/wiki/Lufthansa-Flug_2904)
Als Konsequenz daraus wird die Aktivierung der Störklappen nicht mehr an 12 Tonnen-Fahrwerksbelastung und einer nicht näher beschriebenen Radumdrehung gekoppelt. Jetzt reicht eine Belastung von 2 Tonnen aus und es geht rund.
Grüße
Ralf
Herzlichen Dank!
Leider nein. Meiner Erfahrung nach wissen die meisten Piloten eben NICHT mit den Systemen des Airbus etwas anzufangen. Die Hintergründe der Systemhandlungen sind nicht bestandteil von Schulungen und viele auch meiner Nachfragen hätte ich besser beantworten können.
Einfaches Beispiel LH 1829. Wegen vereister Sensoren wurde bedingt durch das Mehrheitsprinzip der einzige korrekte Sensor ignoriert und der Bus ging in den Alphafloor Protection. Beide Piloten zogen am Stick aber der Bus wollte mit der Nase nach unten. Sie kamen partout nicht auf die logische Folgerung “OK. Bus hat Kontrolle. Bus darf keine Kontrolle haben. Wann hat er keine Kontrolle mehr (=direct Law). AH OK! Ich schalte 1 ELAC und 2 SEC aus und schon bin ich im DirectLaw und der Bus macht was ich will”.
Oftmals haben Flightsimmer mehr technisches KnowHow aber weit weniger Routinge gerade was Notfallmaneuver angeht. Tiefgreifende Systemfragen auch in Checkrides abzufragen ist zumindest in Deutschland von sowohl Cockpit als auch den Airlines unerwünscht.
Ja, genau dieses erfüllt mich mit Argwohn. Es ist die Philosphie die dahinter steckt. Dem Computer wird alle Macht verliehen, die Piloten werden zu Handlanger degradiert. Im Grunde genommen ist nicht der Computer schuld, sondern jene die vor der Eingabeeinheit des Programmes sitzen. Es scheint, auch wenn es weh tut, das eine Gruppe eben dieser Menschen sich anmaßen unfehlbar zu sein. Jenen die da vorne in der allerersten Reihe sitzen, jedoch keine Möglichkeit geben in einer “Notschaltung” die absolute Kontrolle über das Flugzeug zu übernehmen. “Fly the aircraft first!”
Sobald ein stabiler Flugzustand erreicht ist, gibt es meist genug Zeit zum Alltag zurückzukehren. Es ist die Zukunft des Fliegens, doch sie ist erst am Beginn.
LG Cundri
Hallo Andy, .. wow – was du alles weisst, Hut ab – Wahnsinn ! Hast du dieses Fachwissen vom “richtigen” fliegen oder aus Handbüchern von FS_Addon Flugzeugen?
Beim Unglücksflug der Air France von Rio nach Paris muss es wohl ähnlich gewesen sein. Hab´ die Dokumentation darüber im Fernsehen gesehen und war entsetzt, was diese 3 Superhelden im Cockpit abgeliefert haben…!
Grüße
Walter
Ein Mix aus allem. Mein Vorwissen der realen Fliegerei (PPL + abgebrochenes TR für 737, Vordiplom in der Steuerungslogik des A320), meine Macke dass ich Systembeschreibungen haben will (Kritikpunkt beim FSLabs Bus!!!) um die Systeme in der Logik zu verstehen und letztlich auch das Probieren im großen Sim einer Airline wenn ich einen Software-Auftrag dort habe und das Verhältnis stimmt.
Ich bin früher bei LH Systems fast täglich geflogen in so gut wie allen Regionalfliegerchen (737, A320, CRJ, Avrojet, ATR42, Dash8) und das meistens im Cockpit. Gekoppelt mit einem Flightsim und komplexen Addons und inhalierten Systembeschreibungen macht sowas süchtig und gibt ein kleines Wissen.
Im Prinzip hast Du den Nagel auf den Kopf getroffen mit der Aussage “Nichts weniger, als dass eigentlich die gesamte Systemtiefe des Airbus simuliert werden KANN”.
Das Kernproblem bei der Programmierung einer ultra-realistischen Systemsimulation ist, dass genau bei der Implementierung der speziellen Details sich häufig die Original-Flugzeughandbücher ausschweigen und die Programmierer im Grunde genommen die Systemlogik in solchen Fällen INTERPRETIEREN müssen.Es kann am Ende dazu führen, dass es mit der Realität exakt übereinstimmt oder auch nicht.
Ich bin über den Aerowinx PS1 mit dem Virus “Flugsimulation” infiziert worden und gerade bei der kürzlich herausgebrachten Nachfolgeversion PSX zeigen sich genau diese Details. Teilweise werden bestimmte Szenarien sogar in einem Full-Motion-Simulator nachgestellt, um zu prüfen ob die Systemlogik richtig erfasst und umgesetzt wurde – eben weil es dazu keine brauchbare Dokumentation gibt.Noch immer werden dank des großen Engagements des Entwicklers diese kleinen Fehler in unzähligen Mini-Updates korrigiert, wodurch sich die Simulation tatsächlich auch in den letzten Details immer mehr dem Original annähert.
Auf einem Routine-Flug von A nach B wird man vermutlich nie merken, dass ein Detail nicht korrekt programmiert ist, aber wenn man es drauf anlegt und die Simulation richtig fordert, fallen diese Ungereimtheiten auf.
Ich bin daher sehr gespannt, wie sich der FSLabs Airbus in der Hinsicht schlägt. Ohne Zweifel wird da sehr gute Arbeit geleistet worden sein (die will ich in keinster Weise schmälern) und die gängigen Fehlfunktionen werden alle korrekt simuliert sein, aber zum jetzigen Zeitpunkt kann ich vollmundige Aussagen, dass es sich 1:1 wie das Original verhält, nicht ganz nachvollziehen.
Noch spannender finde ich übrigens die grundsätzliche Frage, wieviel % der Nutzer vom FSLabs Airbus mit zufälligen oder induzierten Fehlfunktionen fliegen. 😉 Für einen gemütlichen Feierabend Flug auf VATSIM oder IVAO ist das Produkt meines Erachtens rausgeworfenes Geld.
Fakt ist: FSL musste die Systeme irgendwie mit Logik versehen. Wenn sie falsch ist, wird sie vermutlich korrigiert. Immerhin wurden hier in wenigen Tagen fast eine halbe Million mit einem Nebenjob verdient (geteilt durch alle+Provisionen von Drittpartnern). Die 318, 319, 321, 330 unterscheiden sich kaum von der A320. FSL wäre blöd die Flieger nicht noch zu releasen; es ist eine Kuh die gemolken werden will. Auch die A340 ist mit wenigen Modifikationen umzusetzen. Du kannst Dir sicher sein, dass negative Reputation (“die patchen XYZ nicht”) vermieden wird.
Und Du musst bedenken dass FSL durch einen Streit mit RSR bei PMDG entstanden ist (zumindest 2-3 Personen von FSL). Man will schließlich dem Ex-Arbeitgeber zeigen was man so alles kann und was möglich ist. Denn RSR persönlich hat den A320 aus der Roadmap gestrichen eben wegen dieser unbekannten Komplexität. Und diese hat ja, wie wir nun wissen die Entwicklung um 3-4 Jahre verlängert. Ursprünglich replantes Release Ende 2013? HOHOHOHO 🙂
Hi Andy,
wie kommst du auf die halbe Million?
Verkaufte Exemplate per Steamranking genommen, paar weitere Flugkandidaten von Vatsim grob überschlagen, mit bekannten Verkaufszahlen von anderen Publishern quergecheckt und eine vage Äußerung geäußert. Und diese Summe ist lediglich ein recht gering genommener Wert wenn man bedenkt dass die Mehrheit der Simmer nicht zu dem Produkt greift.
Ansonsten gestern abend 18k Spieler im FSX:SE. Wenn sich würder jeder das Addon kaufen sind wir bei 1,8Mio Gewinn. Dann wissen wir, dass die Steamgamer nur ein geringer Prozentteil sind aller FSX Simmer.
Andy, hast Du meine Mail bekommen?
Ich lese bei den Eigenschaften nur ab Windows 7. Würde das Ding gar nicht mehr auf Vista 64 laufen? Die beiden OS haben doch fast die gleiche Struktur…
Da sich seit Vista alle Windowse den gleichen Kernel teilen und nur Verbesserungen und Erweiterungen vorgenommen wurden, würde ich denken dass jedes Programm läuft was im Userland läuft (also so ziemlich jede Software).
Nur unter Win10 gibt es bei einigen Programmen Probleme weil ab Win10 der RAM gezippt wird und einige Programme damit einfach nicht klar kommen. Ist beim FSX aber wurscht weil 32bit Programm womit Win10 nicht in Verlegenheit kommt bei <4GB usage zu zippen. Win8 hatte als Neuerung noch einen Tickless Timer bekommen aber da die Software W7 kompatibel ist dürfte das kein Problem darstellen (würde auch nur Probleme generieren, wenn man an der Blk Frequenz rumschraubt).
@Andy – ich hab´mir – wieder und wieder deine Statements durchgelesen: Genial (und das ist noch ein Hilfsaudruck”)
Also- nochmal meine allerhöchste Bewunderung wie du dich auskennst. Deine Ausführungen sind “Geld wert” und einer fachlichen Dissertation gleichzusetzen!
Da kriegt wahrscheinlich sogar unser Oski noch “glühende Ohren” – wenn er das liest…
Erstmal Danke für die Blumen und ein kleines Veto. Ich bin IT’ler welcher sich von der Aviatik verabschiedet hat. Oski ist sein Leben lang geflogen. Und er engagiert sich nach wie vor für den Nachwuchs (Respekt an dieser Stelle!). Es gibt hier nix was mich auch nur annähernd mit Oski vergleichen lassen könnte. Sein Fachwissen, seine Liebe zur Aviatik und auch seine Expertise bei den Fliegerchen ist unumstritten genial. Ich als Informatiker jedoch finde die Airbusse wegen ihrer Automation geil (die ELAC und SEC hatten eine sehr sehr frühe Version von corosync!!!) und heimisch. Ich kenn noch von früher die 737. Aber ich bin weder im Liniendienst geflogen noch kenne ich sämtliche Routinen auswendig.
Und ich bin in der Softwarebranche heimig und lass mich leicht durch Unwissen anderer reitzen; das nich immer gut.
Und diese fachliche Dissertation hab ich sogar geschrieben – über den A320 damals anno 2004. 🙂 Ich muss gestehen ich war schon über den A310 erstaunt; das war der erste Flieger mit dem ich in Berührung kam und dessen Typerating ich machen sollte bis die Airline entschied die werden alle zu Frachtern umfunktioniert.