Notizen und Ergänzungen zu einem Flugsimulator-Vortrag

W. Näser, Marburg, 2004 ff.      
         

0. Vorwort. Aus der Beschäftigung mit PC-Flugsimulation (ab Ende Februar 2004) und basierend auf dem Interesse an Aviatik und Luftfahrtgeschichte seit Mitte der 70er Jahre entstanden die folgenden, größtenteils in den Vortrag vom 28.1.2005 eingeflossenen Überlegungen.

Ihr Ziel war und ist es, die Flugsimulation mittels PC für kulturgeschichtliche und didaktische Fragestellungen und Präsentationen fruchtbar zu machen. Unberücksichtigt bleiben rein militärische Anwendungen wie z.B. Combat Simulator, IL-2 Sturmowik usw., auch wenn immer wieder argumentiert wird, hier unterscheide sich die virtuelle Kampfwelt von der Lebens-Realität und es gebe daher keine Nachahmungsgefahr.

In seinen Möglichkeiten, das soll aufgezeigt werden, geht der PC-FS weit über gewöhnliche "Spiele" hinaus, hier sollen die Grundzüge und einige besonders reizvolle Möglichkeiten, aber auch die Grenzen des Programms aufgezeigt werden. Die folgenden Notizen basieren auf dem an meiner ehemaligen Schule in Bad Arolsen gehaltenen Vortrag und wurden / werden ergänzt.

1. Das Programm
Der seit Anfang 2004 millionenfach genutzte Microsoft-Flugsimulator 9 "A Century of Flight" umfaßt in der Grundkonfiguration nur ca. 2,5 GB, geht jedoch in den möglichen Erweiterungen und Modifikationen ("professionelles" Arbeiten) weit darüber hinaus, so daß, wie ich weiter unten aufzeige, mit allen Modulen Umfänge von 50 und mehr GB nicht selten sind.

1.1. konstitutiv sind:

Cockpit-, Ton- und Landschaftsdateien (ausgenommen der Pfad \scenery\base) können auf andere Partitionen bzw. externe Laufwerke ausgelagert werden, sofern dies bei umfangreicheren Installationen nötig ist. Bei jedem Neustart werden zuerst die sceneries überprüft und wird im Falle von Änderungen die betreffende scenery.dat neu geschrieben. Aufgrund solcher Variablen funktioniert es nicht, das gesamte Programm auf eine DVD-R zu überspielen und von dort aus zu starten. Zweckmäßig kann es jedoch sein, verschiedene FS-Konfigurationen auf individuellen Partitionen einzurichten; befinden sich diese Spezialkonfigurationen auf einer externen Festplatte, sind sie (via USB 2.0) auf allen Rechnern lauffähig, in denen der FS8 und / oder FS9 installiert ist und sich die nötigen Daten in der Registry befinden.

Grundsätzlich lassen sich verschiedene Ziele und Anforderungen formulieren:

Zweck
Anspruch
Programm-
Variante
Partitionen
Umfang in GB
Grafik, Pixel
Bit /       MB 
RAM
min.
RAM
opt.
CPU
GHz
IFR-Training,
Konfiguration
gute Cockpit-Darstellung
und Instrumentenablesung
ab FS 8 (siehe
separaten Text)
 1
 4-7
1024 * 768
    16 /  128
512
2 GB
Centrino
ab 1,4 / bis 32-Bit
Spielen,
VFR
-Training
mittlere Güte v. Flugzeug-
und Landschaftsdarstellung
ab FS 9
 1 oder mehr 
 4-7
1280 * 768
    16 /  256
512
Pentium IV
ab 2,4
Spielen, VFR,
Unterricht
höchste Ästhetik der
Präsentation
ab FS 9
(Upgrade 9.1)
 1 oder mehr
 50 oder mehr
 ab 1600 * 900
     32512
1 GB
4 GB
Pentium IV
o.ä. ab 3,0


1.2. Der Umfang des FS 9:

a) Grundversion (geringfügig erweitert auf 3,316,422,138 Bytes, erste DVD-Sicherung v. 26.2.2k4; probeweise installiert auf Dell - N:). Hat bereits einige gute virtuelle Cockpits, genügt vollauf für einfache und schwierige Schulungen bis hin zum "Verkehrspiloten" mit Musterzulassung z.B. für die B 737.

b) Erweiterungen (addons) werden nötig für spezielle Studien, z.B. zur Luftfahrtgeschichte oder Landschaftsdarstellung und erfordern professionelles Arbeiten mit ausgelagerten Sammel-Pfaden (Stand: 8. Dezember 2005); eine dermaßen ausgedehnte Konfiguration umfaßt:

  1. c:/FS9/Panels: 4.053.516.380 Bytes mit 544 Pfaden (=Panels und Varianten)
  2. j:/ FS9 (in Stamm- oder Hauptpartition) mit allen Pfaden und Einzeldateien zusammen: 19.284.243.724 Bytes, darin:
    j:/FS9/aircraft: 13.247.455.909 Bytes mit 553 Haupt-Pfaden (jedes Muster weiter untergliedert)
    j:/FS9/gauges: 3.126.345.675 Bytes (intern 109 Verzeichnisse, dazu 14.956 Einzeldateien)
  3. k:/fsound: 5.837.288.432 Bytes in 370 Pfaden
  4. i:/Addon Scenery: 3.588.937.341 Bytes in 79 Pfaden
  5. m:/ scenery: 8.934.173.619 Bytes mit 19 Haupt-Pfaden
    -------- dazu auf externer Festplatte: ------------
  6. y:/Scenery (incl. Cities): 7.128.433.921 Bytes in 30 Pfaden

Gesamtumfang in dieser erweiterten Konfiguration = 48.826.593.417 Bytes (47.68 GB).

Innerhalb des auf dem neuen Acer-Aspire 9813 angesiedelten Projekts "Flugsimulation als lebendige Luftfahrtgeschichte und Beitrag zur Landes- und Kulturkunde" ergeben sich (Stand: 18. Oktober 2007) folgende Datei-Ressourcen:

  1. c:/FS9/Panels: 6.767.386.181 Bytes in 698 Pfaden (Panels und Varianten);
  2. j:/FS9: 51.914.577.510 Bytes in in 62 Haupt-Pfaden mit 237.597 Dateien, darin u.a.:
    - /aircraft: 27.417.740.633 Bytes mit 744 Hauptpfaden (Flugzeugdaten außer -> Gauges und -> Sound),
    - /gauges (=Cockpit-Instrumente und Flugsteuerelemente): 4.608.599.758 Bytes mit 175 Pfaden und darüberhinaus 17.631 Einzeldateien;
    - /Germany: 4.042.939.093 Bytes in 427 Pfaden (deutsche Flughäfen mit Szenerie- und Texturdateien)
    - /texture: 2.164.506.708 Bytes in 20.789 Dateien (allgemeine und spezielle Texturen)
    k:/fsound: 9.357.684.564 Bytes in 498 Pfaden
    m:/ addon scenery: 2.250.388.779 Bytes in 53 Pfaden;
    m:/cities: 4.111.099.287 Bytes in 115 Pfaden;
    m:/Eurw-FSX: 154.286.791 Bytes;
    m:/Eurw-MS: 58.714.778 Bytes
    m:/RJ: 1.036.311.488 Bytes (Japan Teil 1)
    m:/RJ-Ground2k2: 240.738.607 Bytes (Japan Teil 2)
    m:/RJ-Mesh: 240.737.067 Bytes  (Japan Teil 3)
    m:/SG: 350.178.740 Bytes (allgemeine, nicht ortsbezogene Szeneriedaten)
    m:/SG-AF2Germany: 1.634.956 Bytes (deutsche Flughafendaten)
    m:/SG-AF2: 12.550.156 Bytes (ausländische Flughafendaten)
    m:/SG-Helipad: 821.096 Bytes;
    m:/SG-komb: 3.493.565.221 Bytes in 7.468 Szenerie- und 27.269 Textur-Dateien
         (Ressourcen des in E:/FS9 untergebrachten "integrativen Deutschland-Simulators")
    m:/SG-LC: 50.267.643 Bytes (Landklassen-Daten für J:/FS9)
    m:/SG-Lib: 66.304.842 Bytes (Library-Files für J:/FS9)
    m:/SG-Rivers: 13.375.211 Bytes (separate Fluß-Dateien für J:/FS9)
    m:/SG-Roads: 307.082 Bytes (ergänzende Straßen-Dateien für J:/FS9)
    m:/SG-Soar: 25.411.871 Bytes (segelflugbezogene Zusatzdaten für J:/FS9)
    m:/SG-Traffic: 159.713.432 Bytes (verkehrsbezogene Zusatzdaten für J:/FS9)
    m:/SG-VFR: 63.231.210 Bytes (VFR-Daten für J:/FS9)
    m:/SG-Worldcup: 5.151.631 Bytes (auf die Fußball-WM 2006 bezogene Ortsdaten für J:/FS9)

Die Summe aller aus Acer-C:/FS9/panels, J:/FS9, K:/fsound und M:/ (als Standalone-Paket des "internationalen Flugsimulators") auf eine externe Festplatte (TrekStor USB 2,5", Partition 122 GB, komprimiert) gesicherten Daten beträgt 80.374.426.503 Bytes in 83 Haupt-Directories mit zus. 407.251 Dateien (Zählung wie oben mit WinContigDefrag, keine Datei beim Überspielen fragmentiert).

Daneben existiert noch eine zweite Installation E:/FS9 mit derzeit 11.986.051.707 Bytes in 63.184 Dateien. Der "integrative Deutschland-Simulator" (siehe unten) ist in 23 Hauptpfade untergliedert und bezieht ergänzende Daten aus C:/FS9/panels (Cockpits), k:/fsound (Triebwerk-Tondaten) und m:/SG-komb (ortsbezogene Daten). Den Löwenanteil bestreiten hier /aircraft (Flugzeug-Grunddaten) mit derzeit 8.245.516.370 Bytes in 220 Pfaden und /gauges (Cockpit-Instrumente) mit 1.997.683.778 Bytes in 130 Pfaden und zusätzlich 7.210 Einzeldateien; beide Directories liefern die Daten der weitgehend auf die deutsche Luftfahrtgeschichte bezogenen und / oder zum Testen (Darstellungsästhetik, Funktionalität, Flugdynamik) installierten Flugzeugmuster.

Vorstehende Aufstellungen illustrieren den über jedes konventionelle Betriebssystem weit hinausgehenden Datenaufwand solcher (stetig wachsenden) Installationen. Bestimmte, sehr gut ausgearbeitete Flugzeugmuster beanspruchen hierin mit sämtlichen Grundtexturen, Panel- und Ton-Dateien nicht selten allein jeweils mehr als 100 MB und sprengen als quasi autonome Programme den Rahmen vieler bisher als aufwendig betrachteter PC-Anwendungen.

Außer den Grundprogrammen FS9 und FS8 sowie X-Plane 7 wurden getestet:

  1. 727 Professional (Just Flight)
  2. 737 NG (=next generation) 600 / 700 (PMDG / Aerosoft Paderborn)
  3. A 320 Pilot in Command (Ubi Soft)
  4. A 340 Professional (enthält auch A 330; Just Flight)
  5. Apollo Giga Scenery, Vol. 1-3 (photo realistic sceneries, 3 DVDs, www.apollosoftware.com)
  6. B 747 Ready for Pushback 2004 (profisoft / VMAX)
  7. Balearic Islands & Gibraltar V. 3.0 (Aerosoft)
  8. DA-20 Katana V. 1.1 (Aerosoft)
  9. Dash 8-300 Professional (Phoenix)
  10. D-Sat 6 (3 DVDs, ecw-Dateien, BUHL)
  11. Eurowings 2004 (Aerosoft Paderborn)
  12. FS Terrain (mesh sceneries, 4 CDs, Just Flight)
  13. German Airports 1, 3, 4 (Aerosoft)
  14. Global scenery V. 7 for X-Plane 7, 4 CDs (NE / SE / NW / SW quadrant; Laminar Research, www.x-plane.com)
  15. Helipack (Simviator, Blomberg)
  16. Hong Kong 2004 (Flight Soft)
  17. Karibik / Fly to the Carrbbean (Flight Soft)
  18. My World 2004, Vol.1 (Europe & Asia) und 2 (The Americas)
  19. Real Germany Region 2: Nord-Ost (fotorealist., 3 CDs, Aerosoft)
  20. Scenery Germany 1, 2, 3, 4 (Aerosoft)
  21. Scenery Manhattan V. 1.1: Impressions of a City (Aerosoft)
  22. Sim Control 2004 (Installations-Oberfläche)
  23. Traffic 2004 (Just Flight)
  24. Ultimate Traffic (=Flight 1 Software, Just Flight)
  25. Wings of Power: WW2 Heavy Bombers and Jets (shockwave, www.halycon.de)
  26. World Airports 2 (Just Flight)
  27. Japan Scenery (DVD) 1 und 2

Sämtlich installiert, würden diese Addons mindestens mehr als 50 GB einnehmen; daher war eine sinnvolle Beschränkung nötig und wurden nur diejenigen Module belassen, die als "funktionaler Mehrwert" gelten können. Umfangreiche Szeneriepakete wurden nur temporär installiert und erprobt und erwiesen sich zu komplex für die hier verwandte Hardware.

1.3. Kompatibilität
1.3.1. FS8 zu FS9
Wie schon oben erwähnt, sind auch viele für den FS9 konzipierte Flugzeugmodelle kompatibel mit seinem Vorgänger; sogar die bei www.flightsim.com frei erhältliche, ausdrücklich mit dem Vermerk "FS2004 only" versehene, als FS-Modell brandneue Armstrong Whitworth Argosy 200 series vom 16.11.2k5 (*.mdl = 2.626.844 Bytes; Texturen = 16.261.082 Bytes; Sound = 13.204.998 Bytes; Panel = 15.986.375 Bytes) ließ sich trotz ihrer heiklen Flugdynamik bei full flaps und wenig Steigwinkel von Seattle Tacoma aus in die Luft und später bei zero flaps mit ca. 140 kn in eine stabile Fluglage bringen, wie das im Versuch mit dem Compaq hp/nx6110 (Centrino 1,5 GHz, Win XP prof., Grafik 128 MB / 1024 * 768) erstellte Bild rechts beweist; bemerkenswert die klar umrissene, detaillierte und auch in puncto Propeller-Rotation realistische Darstellung der Maschine. Überhaupt eignet sich der FS8 hervorragend für das Testen und Darstellen historisch wichtiger Flugzeugmodelle.

Kompatibel mit FS8 (und daher mit FS8 kombinierbar) sind außerdem die Bereiche

Die Leistungsfähigkeit des FS 8 kommt, wie schon erwähnt, vor allem in der Vielfalt seiner Flugzeugmodelle zum Tragen, die sich zum Teil durchaus mit denen des FS 9 messen lassen, wie u.a. eines der am besten ausgearbeiteten FS8-Muster beweist, die auch von der Lufthansa zum fortgeschrittenen Verkehrspilotentraining benutzte (und in diesem Sinne auch für den FS 8 und 9 bestens geeignete) Piper Cheyenne 400:

Das gilt auch für ihr in 2D und 3D voll funktionales (und somit IFR-taugliches) Cockpit:

1.3.2. FS9 in verschiedenen Umgebungen

Mein linker obere Screenshot (vom 15.4.2k6) zeigt die attraktive DC-6B via FS9 und 1024*768 Pixeln im hp/nx 6110 (Centrino 1,6 GHz, 128 MB Grafik, 512 MB RAM) unter Windows XP professional / SP 2 und demonstriert einmal mehr die Möglichkeiten dieses bescheidenen Business-Notebooks. Darunter eine am 6.8.2k6 verewigte, sich mit gesetzten Klappen in die Nordseeluft erhebende Beechcraft B 190 C mit 1280 * 800 Pixeln im DELL Inspiron 9100. Der letzte Screenshot entstammt der "Nach-Inszenierung" eines realen Erlebnisses: etwa Mitte Juli 2006 erlebte ich am Himmel über Marburg-Richtsberg gegen 21:30 den faszinierenden Anblick einer in etwa 11.000 Metern Höhe von der Abendsonne strahlend ockergelb kolorierten großen Linienmaschine: vom Erscheinungsbild her zweifellos eine Boeing 747 der JAL: Motivation genug, die zugehörige Höhe zu erfliegen, mit entsprechenden Optionen (Datum, Uhrzeit, Wetter) die Situation nachzustellen und im Beobachter-Modus ein (leicht bearbeitetes) Bild zu erzeugen, das der Sichtweise mit einem starken Fernglas entspräche. .

Natürlich arbeitet FS 9 nicht unter allen Betriebssystemen und in allen Hardwareplattformen gleich gut. Hinsichtlich anspruchsvoller Konfigurationen gab es nur wenige Probleme unter dem im Bullman EK4 P4 vorinstallierten, an die Hardware perfekt angepaßten Windows 2000 professional. Alle Module arbeiteten problemlos, der rückgekoppelte Speedlink-Joystick übertrug die optierten Steuerdrücke. Der Wechsel zu Windows 2003 Server Enterprise führte dazu, daß der Joystick nicht mehr vibrierte, was auch durch ein Downgrading auf Windows 2000 professional (bzw. dessen Parallelinstallation zu Win 2k3) nicht zu beseitigen war. Auch mit dem flotten Dell Inspiron 9100 (Grafik: ATI Mobility Radeon 9800, 256 MB) konnten unter Win XP professional / SP 2 weder der Speed-Link noch ein alternativer Joystick das "forced feedback" entfalten. XP bremste im Default-Betrieb mit unverlangten Meldungen (an ... update has been downloaded") und sonstigen Eingriffen, weshalb entsprechende "Dienste" und das sogenannte Sicherheits-Center deaktiviert werden mußten; allerdings sollte aufgrund der daraus resultierenden Viren-Gefahr in diesem Betriebszustand die Flugsimulation nur vom Internet abgekoppelt erfolgen.

1.4. Hardware-Anforderungen:

Der äußerst komplexe und rechenintensive FS9 beansprucht selbst ein Hochleistungs-Notebook wie das Dell Inspiron 9100 mit seinem 150-Watt-Netzteil bis zum Limit (das Bullman -NT liefert 100 Watt und das des hp/nx6110 nur 50, was diesen Rechnern auch beim FS9 genügt). Auch beim "Normalbetrieb" werden jeweils 450 bis 500 MB RAM beansprucht (zu den Problemen siehe unter "Landschaften").

1.5. Funktionskontrolle
Der Microsoft-Flugsimulator arbeitet nur dann sicher und zuverlässig, wenn mit Hardware-mäßigen Eingabemitteln (Tastatur, Joystick) alle im Programm verfügbaren Steuer-Vorgänge realisiert werden können (zum Hubschrauberflug siehe unten). Das bedeutet quasi die Macht über das gesamte Verhalten des simulierten Luftfahrzeugs, also Motor-Leistungsregelung, Fahrwerk, definiertes Aus-/Einfahren von Luftbremsen bzw. Landeklappen, Kontrolle der Flugsteuerflächen (Seiten-, Höhen-, Querruder, ggf. auch Vorflügel). Außerdem müssen mit bestimmten Tasten(kombinationen) und der Maus alle irgendwie schalt- oder verstellbaren Aggregate (gauges) des Instrumentenbretts (panel) erreich- und veränderbar sein. Dies alles verlangt einwandfrei arbeitende Hard- und Software. Um die Flugdynamik mit allen Bewegungen des Luftfahrzeugs im Flug voll ausschöpfen zu können, brauchen wir eine der Realität konforme sensible Steuerung, die mit Eingabetasten nur eingeschränkt möglich ist. Allen Anforderungen gerecht wird nur ein robuster, feinfühliger, mechanisch und elektrisch präziser Joystick mit höchster Wiederkehrgenauigkeit aller eingestellten Parameter. Mit zusätzlichem "Gashebel" ausgerüstet, kann er auch die im sog. Leistungsquadranten realisierte Triebwerkssteuerung zumindest teilweise umsetzen. Anspruchsvolle Joysticks (wie der Speed Link) sind hochkompliziert, mit zahlreichen integrierten Schaltkreisen, Mikroschaltern und (verschleißanfälligen!) Geber-Potentiometern ausgerüstet, von deren Präzision das Verhalten der Flugmodelle abhängt. Vibrations-rückgekoppelte Joysticks vermitteln den geschwindigkeits- und höhenabhängigen Widerstand der Flugsteuerflächen sowie die (auch akustisch vermittelte) Beschaffenheit des Rollweges. Leider funktioniert auch bei mehreren Joysticks diese Vibrationskopplung nicht unter dem neuen Windows XP mit dem bei PC-Neulieferungen unverlangt eingespielten, nicht entfernbaren Service Pack 2, konnte jedoch mittels Neuinstallation von Windows XP prof. mit Service Pack 1 reaktiviert werden.

Vor jedem Flug sollte vom Cockpit aus und extern im Beobachter-Modus die gesamte Steuerung geprüft werden. Bild rechts zeigt oben das Original-Cockpit der in Marburg-Schönstadt stationierten, als D-EIMC registrierten Cessna 172 (Foto W. Näser 17.4.2k4), darunter (als etwas verzerrten Screenshot) das im Flugsimulator 9 abgebildete sog. Virtuelle Cockpit der defaultmäßig eingesetzten 172SP: hier müssen alle Elemente der Flugsteuerung (Steuerhorn, Gas- und Gemischverstellung, Klappenhebel, Seitenruderpedale) möglichst exakt auf die jeweiligen Joystick- und Tastenangaben reagieren. Wird der virtuelle "Gaszug" nur halb herausgezogen und / oder neigt das Luftfahrzeug trotz aller Steuerkonzentration zum Gieren, so ist der Joystick neu zu kalibrieren, z.B. durch Option der Default-Werte (das gilt für alle gängigen Produkte).

1.6. Flugzeugmodelle als Spiegel der Fluggeschichte:
Verfügbar sind drei komplexe Installationen: Dell (J) sowie externe Platten (T) und (Y). Da der verfügbare Beamer nicht mit dem Dell Inspiron 9100 (Grafik: ATI Mobility Radeon 9800, 256 MB) zusammenarbeitete, mußte auf den (zwei Jahre alten) Bullman EK4P4 Grand zurückgegriffen werden (CPU 2,8 GHz, 1 GB RAM, HD 60 GB, Grafik ATI Mobility Radeon 9000 mit 64 MB). Das erforderte viel Inspiration, da die Demonstrationsabläufe hauptsächlich auf den Dell-Rechner hin konzipiert waren. Daher konnten nur die mit ** bezeichneten Flüge der folgenden Liste aktiviert und demonstriert werden:
       ---------- schwierig! -------

1.7. Gestaltung und Funktionen des Cockpits
Das Virtuelle Cockpit der Trident ím folgenden Screenshot zeigt, was im Flugsimulator 9 möglich ist:

Solche Cockpits demonstrieren auch in bescheidenen FS-Konfigurationen (siehe oben) eindrucksvoll den jeweiligen technischen Standard der einer Epoche zugehörigen Muster, so in folgenden Beispielen:

1.8. Darstellung der Zelle und der beweglichen Flugsteuerflächen
hierzu umschalten auf (T). Achtung: Aus-/Einfahren der Landeklappen nur bei hochauflösender Grafik realisierbar!

1.9  Hubschrauber-Flug
Nicht umsonst konnte ich ihn in meinem o.a. Vortrag nicht präsentieren. Mit dem bisher hauptsächlich verwendeten Black Hawk Vibration Flightstick SL-6637 ist es so gut wie unmöglich, einen auch in puncto Landung akzeptablen Flug durchzuführen; zu den wenigen "gutmütigen" und daher einigermaßen leicht im FS9 handhabbaren Mustern zählen z.B. der Bell-206 Jet Ranger (Screenshot oben) / Long Ranger oder der Bristol 171 Sycamore.

Beim Hubschrauberflug gliedert sich die Flugsteuerung in

  1. Links-rechts-Steuerung (Gierachse, Kurvenflug) mit Fußpedalen
  2. Auftriebsteuerung (Steig-/Sinkflug) mit dem Collective-Hebel (pitch)
  3. Vorwärts-/Rückwärtssteuerung (Längsachse) und
  4. Schräglage (Querachse) mit dem Steuerknüppel
  5. Schubsteuerung (throttle control / manifold pressure control) per Gashebel

Der teils unpräzise reagierende Black Hawk vereinigt (2) und (5), was einen exakten Sinkflug (und damit eine Präzisions-Punktlandung) unmöglich macht; zudem ist für Vollgas der linkseitige Hebel nach vorn und damit herunterzudrehen, wogegen für gleichzeitiges Steigen der fehlende Collective-Hebel eigentlich nach oben zu ziehen (= zurückzudrehen) wäre. Leichte Vorwärtsbewegung des Steuerknüppels neigt die Heli-Nase und begünstigt, wie in der Realität, das Vorwärtsfliegen; Rechts-/Linksdrehung des Knüppels ermöglicht (1), Neigen um die Querachse (4). Ein exakter Schwebeflug (hovering) ist nur sehr schwer zu realisieren und erfordert äußerste Geduld und Feinfühligkeit. Exakt ließen sich Helikopter im FS 9 nur mit aufwendigen externen Steuerungs-Interfaces fliegen: sensiblen Fußpedalen für (1), einem Collective-Hebel für (2), einem präzisen Steuerknüppel für (3) und (4) und einer sensiblen Schubsteuerung (throttle control) für (5); diese Steuerelemente könnten am Sitz des Simulator-Piloten angebracht und per USB-Hub an den Computer gekoppelt werden.

1.10. Handhabbarkeit:
a) Optionen
(Steuerung, Schwierigkeitsgrade; rückgekoppelte Joysticks wie der Speed Link werden nicht immer erkannt).
b)
Modi: 2D-Cockpit, virtuelles (z.T. voll flugfähiges) 3D-Cockpit, Tower- und Beobachtungsflugzeugmodus (Parallelflug), Vogelflugperspektive (Ctrl-S).

1.11. audiovisuelle Ästhetik:
Bild und Ton im Flugsimulator
Die FS-Version 9 läßt kaum Wünsche offen hinsichtlich des Realismus von Flugmodellen. Rumpf und Steuerflächen, Fahrwerk und Motore (auch Gegenschub) arbeiten korrekt, Motor- und andere Geräusche (z.B. Aus-/Einfahren der Landeklappen und des Fahrwerks) entsprechen im optimalen Fall (live aufgenommene Originalgeräusche) der Realität. Voraussetzung für beste Bild- und Tonqualität ist ein schneller Rechner mit Hochleistungsgrafik und leisem Lüfter, sofern keine externen Boxen benutzt werden. Je höher auflösend die Grafik, desto mehr Flugzeug- und Gelände-Details werden sichtbar; das zeigt sich z.B. beim Flug über Hamburg oder Seattle.

1.12. Technischer Realismus
Wie weit sich die virtuelle Darstellung mit der Realität deckt und wie detailliert ein ausgearbeitetes Model des Flugsimulators 9 arbeitet, möge der während eines Simulatorflugs im Beobachter-Modus erstellte, rechte Screenshot verdeutlichen: es handelt sich um das geringfügig eingezogene linke Hauptfahrwerk eines Airbus A 318 just in dem Moment, als ein faszinierender Einblick in den geöffneten Fahrwerksschacht mit seiner ganzen Hydraulik gewährt wird. Darüber erkennen wir das in den Mustern A 318 bis 321 eingesetzte Mantelstromtriebwerk CFM56-5B mit seinem typischen Heck-Konus.
Extrem realistisch sind auch die musterspezifischen, Cockpit und Triebwerke betreffenden Tondateien; vergleichsweise konnte ich dies feststellen am 8. und 12.3.2k6 beim Flug Frankfurt-Tokyo mit einer 747-400 der All Nippon Airways (JA 8097). Während die mächtigen GE-Triebwerke beim Start und im Reiseflug speziell im hinteren Kabinensegment fast brüllend laut erschienen, sank der Pegel bei Verlassen der Reiseflughöhe auf ein an Segelflug erinnerndes Rauschen herab, was in ausgearbeiteten 747-Modellen des FS9 exakt imitiert wird. Ebenso bestätigt sich die beim Rückflug über das noch winterliche Deutschland vermittelte Atmosphäre, werden die entsprechenden Zeit- und Wetterdaten eingegeben.

1.13. Flugdynamik (Flugzeugbewegung): Starten/Landen, Fahrwerk ein/aus usw.; Hinweis: bei schlechtem Flugverhalten (Vortrieb, Stabilität, Autopilot u.a.)
Die meisten FS9-Modelle besitzen eine ausgeglichene, in allen Phasen konstante und zuverlässige Flugdynamik, deren Daten in der sog. *.air-File festgeschrieben sind. Sollte in bestimmten Fällen das Flugverhalten zu wünschen übrig lassen, empfiehlt sich ein Austausch dieser Datei gegen die eines in Größe und Antrieb ähnlichen Musters;  so konnte z.B. das Autopilot-Verhalten der B-58 Hustler mittels der concorde.air stabilisiert werden). Im Internet werden immer wieder neue, verbesserte Air-Files zu verschiedenen Mustern angeboten. Ebenso wichtig ist eine optimale Konfiguration des Joysticks, ohne die Starts und / oder Landungen zum fiktionalen Horror mutieren können.

1.14. Handling: Simulation vs. Realität
"War es wie im Simulator?" fragt Herr Ziegler. Um die signifikanten Unterschiede zu erkennen, muß man, wie beim KVFL-Schnupperkurs vom 16.9.2006, zumindest mal für ca. 40-45 Minuten über Control Yoke und Fußpedale eine Cessna 172 gesteuert haben, ohne die Möglichkeit, Trimmruder, Gas und Gemisch verstellen zu können. "Schauen Sie nach vorn, auf den Horizont, den Sie über der Cowling gut sehen können, wenn Sie die Maschine horizontal halten." Guter Rat ebenso wie das Bild des Wellensittichs auf dem Finger. So leicht wie diesen bewegen heißt: entkrampft steuern und die eigene Verspanntheit überwinden. "Fliegen Sie eine Rechtskurve, schön nach Standard". Sanft schrägt sich die alte Cessna, rechts am Panel der "Mike Charlie" (Foto v. April 2004) sind keine Instrumente, man schielt nach links, versucht das Beste zu machen aus Wendezeiger, Variometer und Horizont, schließlich will man ja einen guten Eindruck hinterlassen. Und dann weiß man, was man die letzte Dreiviertelstunde gemacht hat, und wird sie nie vergessen. Die gute alte Cessna, ein -zigtausendfach bewährtes technisches Wesen, das auf kleinste Bewegungen reagiert, die Kurve schon bei geringstem Pedaldruck einleitet und ruhig in der Luft liegt, wenn man mit ihr einen Bund geschlossen, das Gespür für ihre Rückmeldungen bekommen hat. Das ist direktes Fliegen, nicht Fly-by-Wire wie beim Joystick am PC, das ist Anspannung und Teilhabe mit allen Sinnen, unvergleichbar mit allem bisher Erlebten. Insofern, muß man spätestens jetzt erkennen, ist eine nur per Joystick koordinierte PC-Flugimulation allerhöchstens eine Form der Vorstellung vom tatsächlichen "Handwerk" des Fliegens. Die Erfahrung dieses sonnigen Tages wird süchtig machen, anspornen und für immer nachwirken, auch wenn vielleicht die innere Distanz zurückkehrt, die Fliegen am PC wieder zur Freude macht.

1.15. "Gelände wird geladen...": Gestaltung und Darstellung von virtuellen Flugplätzen und Landschaften

Der am 19.9.2k6 von einer märchenhaft wirkenden Landschaft der Scenery Germany 4 gemachte
Screenshot deutet an, was derzeit im Flugsimulator 9 möglich ist. Werkzeuge wie Ground Environment
lassen auch nicht-fotorealistische Bodenstrukturen plastisch erscheinen:

Im Vergleich dazu eine reale Landschaftsansicht (bearb.):

Im Anfang 2005 gehaltenen Vortrag konnten aus technischen Gründen (Auflösung und Rechner-Anpassung des Beamers) nur bescheidene Eindrücke der Landschafts- und Flugplatzgestaltung vermittelt werden. Die zu einigermaßen tragbaren Preisen erhältlichen Beamer realisieren meist nur 1024 * 768 Bildpunkte, das entspricht der Auflösung der gängigen Business-Notebooks. Erst ab 1280 * 800 Pixeln können jedoch die in den Landschaftsdateien verfügbaren Daten voll ausgeschöpft werden; zudem muß, in Zusammenarbeit mit einer schnellen CPU und optimal angepaßtem Bus-System, die Grafik des Rechners mindestens 15-20mal pro Sekunde ein 3D-Einzelbild in allen Feinheiten (Strukturen, Farben, Kontrastierung) neu errechnen und ausgeben können.

Landschaften werden im FS realisiert auf der Basis sog. Landclass-Dateien (*.bgl; zum Verständnis siehe hier).  Die Landclass-Informationen enthalten die topographischen Daten wichtiger Sichtflug-Informationen wie Straßen, Gewässer, Ortschaften, während als Overlay wirkende sog. Mesh Sceneries in bestimmten Abständen (z.B. 19, 38, 76 m) aus Satellitendaten gewonnene Höheninformationen hinzufügen. Letzteres wird jedoch vielfach übertrieben, so daß Berge und Täler nicht selten "hypertrophiert" wirken. Mittels sog. Flattening-Werte lassen sich solche vertikalen Verzerrungen korrigieren, doch ist dieses Verfahren sehr aufwendig und erfordert gute Programmierkenntnisse und viel Zeit. Positionierungsfehler können sich ergeben, werden LC-Dateien aus verschiedenen FS-Versionen oder aus der Grundversion und Add-ons kombiniert; eine Rolle spielt auch die Lade-Hierarchie. Wird ausgiebig mit Landschaften experimentiert, so sollte jede Änderung dokumentiert und der jeweilige Stand mit allen geänderten bzw. neuen Variablen gesichert werden.

Vergleichende Szenerieanalyse
In derselben Partition lassen sich mehrere individuelle FS9-Minimalinstallationen einrichten; jede enthält neben den Root-Dateien (fs9.exe, language.dll, *.cfg) die Pfade /aircraft (mit der Cessna 172 oder 210), /autogen, /fonts, /gauges, /modules, /scenery, /texture, /uires und ggf. /weather. Die jeweils zu analysierende Szenerie wird mit einem definierten Einstiegspunkt (entry point) eröffnet, hier "Marburg Mitte" (in /Dokumente und Einstellungen/.../Eigene Dateien/Flight Simulator-Dateien/*.flt (7.298 Bytes), *.wx (93.656 Bytes). Hier die Ergebnisse:

FS9-
Konfiguration
Größe
in GB
Screenshot
Bild 1

Microsoft
original

1,15
Bild 2

Microsoft
+ SG-
Landclass

1,25
Bild 3

Microsoft
+
Landscape
Germany


0,935
Bild 4

(MS)
+ARE
+Landscape
  Germany

0,952
Bild 5

(MS)
+Landscape
  Germany
+ARE
+SG-
  Terrain-
 
daten  
(_*, A399*
usw:)

ca. 1,1
Bild 6

(MS)
+ARE
+Landscape
  Germany
+SG-
  Terrain
+SG-
  Landclass
+Flightport-
  Addon

2,15
Bild 7:
FS 8 (!)
ohne MS-
EUR-Daten
+ ARE
+ German
Landmarks

(VFR Ob-
jects)
+ HP*.bgl
+ LC*.bgl
aus UT
Europe

(18.6.2k9)
Bild 8

MS
Flugsimul.
10 (FSX)

original

14
FSX +
Zusätze

siehe Text unten

Die originale Microsoft-Szenerie (Bild 1) ist nichtssagend; Flußlauf (Lahn) und Stadtautobahn sind äußerst ungenau, ebensowenig können wir anfangen mit der fiktiven Bodenstruktur. In Kombination mit den Landclass-Dateien der Scenery Germany (LC_*, in /Addon Scenery/scenery; Bild 2) entstehen eine erweiterte Bebauung und kleine bewaldete Areale. Alternative 3 bevorzugt hingegen die Bewaldung; von der Stadtautobahn durchschnitten, erstreckt sich diese bis in Höhe der Elisabethkirche und führt Marburg in die Zeit des Mittelalters zurück. Werden in -/Eurw die Microsoft-Szeneriedaten gelöscht und sind ausschließlich deutschlandbezogene aus All Streets of Europe (ARE) wirksam, so sind in der Grundtextur von Bild 1 die MS-Variante von Lahn und Stadtautobahn gelöscht und zeigt sich letztere in korrekter Führung, während wir die offensichtlich in diesem Areal von ARE vergessene Lahn vermissen. Werden, wie in Falle (3), die Daten des Freeware-Projekts Landscape Germany (vor allem GermanyLC.bgl = 134 kB) addiert, ergibt sich mit Bild 4 schon ein etwas besseres Gesamtbild, wenn auch die Stadtautobahn noch immer weitgehend von Baumbewuchs gesäumt wird; zur Darstellung der (in Höhe der Elisabethkirche inkorrekterweise die Autobahn schneidenden) Lahn müssen die Terrain-Dateien der Scenery Germany mitwirken (Bild 5). Flightport's EDFN-Szenerie basiert auf den zu Bild 5 benötigten Daten und fügt lediglich einige Objekte (Schloß, Elisabethkirche) hinzu; erst Bild 6 zeigt eine den tatsächlichen Verhältnissen weitgehend entsprechende erweiterte Besiedlungsstruktur, was durch Hinzufügung der SG-Landclass-Dateien (LC_050* usw.) erreicht wird. Nach zeitraubenden Versuchen zur Optimierung des "alten" Flugsimulators 8 mit FS9-kompatiblen Addon-Modulen konnte Mitte 2009 eine beachtliche Marburg-Darstellung nach Bild 7 erzielt werden.

Wie sich MR-Mitte im originalen Flugsimulator 10 (FSX) darstellt, zeigt Bild 8. Die Stadtautobahn ist (bis zum Baggersee) korrekt, doch fehlt in der Autogen-Landschaft die Lahn ebenso wie der Schloßberg und die Lahnberge. Werden die ARE-Flußdaten, SG4 (ohne EDFN), SG-Landclass, SG-Terrain und das Addon hinzugeladen, so erscheinen die Lahn, die Lahnberge und der Schloßberg, während die Elisabethkirche in einem riesigen Krater verschwindet. Sind alle deutschlandbezogenen ARE-Daten aktiv, so ergibt sich nach endlos scheinendem Laden bei ruckeligem Flug und teilweisem Stillstand ein Gewirr aus doppelten Straßen und extensiver, doch unauthentischer Bebauung. Werden im Scenery-Bereich alle mit durchlaufenden Nummern versehenen Directories getilgt, ändert sich daran nichts.

Topografische Inkompatibilitäten
Probleme können dann entstehen, wenn eine kommerziell erhältliche über eine(r) Default-Szenerie installiert wird, z.B. die auf CD angebotenen "All roads of Europe"; wirkt die Szenerie zusammen mit den Grund-Daten (Straßen, Seen, Flüsse) des FS9 oder anderen Szenerien wie Sc. Germany 1, Sc. Germany 2 oder German Airports, erscheinen zusätzliche parallele Straßen und außerhalb von Küstenlinien parallele Ränder oder ein als Insel gestaltetes "Deutsches Eck" (am Zusammenfluß von Rhein und Mosel vor Koblenz). Im kurzen Beiheft, das durch peinliche Rechtschreibfehler auffällt, werden diese Unstimmigkeiten damit erklärt, daß die von der renommierten Firma NAVTEC hier zugrundegelegten Daten nicht kompatibel seien mit denen von FS9. Zumindest was die deutschen Gebiete angeht, wurden die Microsoft-Szeneriedaten offensichtlich schlampig aufbereitet, was dem Flugsimulator einen Teil seiner Authentizität abspricht.

Ähnlich verläuft es nach der Installation der Scenery Germany 2. Diese umfaßt auch Hamburg und dessen Umgebung; eine aus der kostenlosen Szenerie Hamburg-2003 und HHGroundFS2004 abgeleitete, verbesserte Szenerie (mit der zusätzlich enthaltenen AOL Arena). Wird vergessen, die Vorversion der Szeneriedaten zu löschen, gibt es in der Nähe der Speicherstadt plötzlich zwei identische Fernsehtürme und auch andere Verfälschungen. Doppelte Straßen, Flüsse und Gebäude - das ist vergleichsweise etwa so, als dozierte ein Professor aus einem Anatomie-Atlas, in dem alle Muskeln, Nerven und Knochen doppelt auftauchen - er würde sich damit bei allen Studierenden zu Recht der Lächerlichkeit preisgeben. Doch den Nutzer/innen der teils teuer verkauften "Add-ons" mutet man derlei Unzulänglichkeiten zu: vielleicht weil man sie als "Amateure" nicht für voll nimmt.

Andererseits will ich nicht in Abrede stellen, daß eine Reihe sowohl äußerst kompetenter wie idealistischer "Flightsimmer" ständig bemüht ist, ergänzende Szenerien zu entwickeln und sie kostenlos ins Netz zu stellen. Stellvertretend für alle sei das FS-Designerteam Ronald Lampel, Henry Noack und Thomas & Heinz Kings genannt, das u.a. eine ausgezeichnete Ergänzung zur Scenery Germany 3 bereitstellt, in der auch der bisher vernachläsigte Airport Köln-Bonn enthalten ist.

Vergleichen wir nun exemplarisch die virtuelle Darstellung des unteren Endes der Edertalsperre bei Herzhausen mit dem Einfluß der Eder, des mit 177 km längsten Nebenflusses der Fulda:

links: ungenau u. ohne Aussagekraft als Teil der originalen
FS9-Szenerie; rechts: (ca. 75° linksgedreht) reale Land-
schaft mit Vöhl-Herzhausen, dessen Web-Server das Bild
entstammt
rechts: aus demselben Blickwinkel wie im Original-
Luftbild erstellter Screenshot des Edersees mit
Aerosoft-Scenery Germany 4; Vöhl-Herzhausen fehlt
und die Straßenführung nördlich der Brücke ist
ungenau und disproportional.

links: nach Löschung der Microsoft-Daten und Ersatz aus
All Roads of Europe (ARE); rechts: ohne Microsoft- und
ARE-Daten, mit Aerosoft-Scenery Germany 4

In den Spiel-Szenerien links fehlt die Brücke (der B 252 Richtung Frankenberg), in allen sucht man vergebens die Bebauung; auch die Parzellierung des Bodens und die Straßenführung entsprechen nicht der Realität. Kümmerlich und wie ein angeklebter Faden wirkt im stümperhaften Microsoft-Original (und links unten als "Artefakt" mit X markiert) die einfließende Eder. Bislang am detailreichsten und natürlichsten ist die im Juni 2006 herausgebrachte Aerosoft-Variante, sie enthält als einzige die an Herzhausen und dem Eder-Einfluß vorbeiführende Bahnlinie.

VFR-Flug über Waldeck im Microsoft-Design
Als jemand, der diese Strecke mindestens 2.000-mal mit dem Auto befahren hat, fliege ich per FS8 oder FS9 im nordhessischen Raum vom kleinen Sportflugplatz Mengeringhausen (bei Bad Arolsen) aus in südlicher Richtung über Korbach, dann an der Edertalsperre vorbei die Ederstraße entlang bis Frankenberg und dann weiter nach Marburg, um dort möglicherweise auf dem kleinen Flugplatz Schönstadt zu landen. Dabei bediene ich mich der defaultmäßigen, also von Microsoft vorgegebenen Szenerie.

Zunächst suche ich vergeblich Bad Arolsen. Zwar gibt es am vermuteten topografischen Punkt eine Art Wasserlache, die wohl den neugeschaffenen kleinen Twiste-See darstellen soll (ohne allerdings den Ort Wetterburg zu zeigen), doch das Bild der "Stadt im Walde" suche ich vergeblich, finde nur einen undefinierbaren Platz mit ein paar via Autogen hingestellten, undefinierbaren Häusern. Dann suche ich die in Richtung Korbach-Frankenberg verlaufende Bundesstraße 252, fliege einen ziemlich ungenauen Pfad entlang, überquere ein Biotop, das man für die Kreisstadt Korbach halten könnte, wende mich dann zum Edersee, dessen Ausläufer ich bei Herzhausen passiere. Wie das linke obere Bild zeigt, sind jedoch weder Herzhausen noch Vöhl auszumachen, das Ende der Talsperre ist stark vereinfacht, Eder, Bahnschienen und Höhenzüge verlaufen danach seltsam gewunden und Frankenberg ist nur zu erahnen. Wenig später sollte ich Marburg überfliegen, doch was mich in dieser Simulatorlandschaft erwartet, hat mit der landschaftlich so schönen und interessanten alten Universitätsstadt nur wenig gemein (dazu oben "vergleichende Szenerieanalyse", Bild 1). Ich bin diese Strecke oft abgeflogen, auch nach zusätzlich installierten Deutschland-Mesh-Dateien, habe auch vergeblich am Edersee das romantische Schloß Waldeck und die im 2. Weltkrieg heimgesuchte, imposante Sperrmauer gesucht, doch immer war es dasselbe blamable Resultat und habe ich mich gefragt, was die "Designer" solcher Landschaften eigentlich im Sinn hatten. "Realistischer ist kaum möglich", lautet der Slogan des Flugsimulators 8. Und nun haben wir seit nahezu 2 Jahren den FS9. Wenn ich vom perfekt in die Umgebung eingepaßten Tacoma Airport aus am Boeing Field vorbei über die schöne Landschaft von Seattle fliege, über den Hafen an der Küstenlinie und der Skyline entlang, dann empfinde ich das als Ortsfremder sehr beeindruckend und mag das werblich für US-Kunden sehr attraktiv sein, doch an die FS9-Nutzer ím für die Luftfahrtgeschichte so wichtigen und innovativen Deutschland hat man wohl nicht gedacht - ein Beweis mehr, könnte man polemisieren, warum viele US-Amerikaner über das Kernland des "alten Europas" so schlecht orientiert sind.

Große Hoffnungen erweckt(e) die lange als bedeutender Fortschritt beworbene, von Aerosoft erst Mitte 2006 vorgestellte Scenery Germany 4. Den Edersee bildet sie besser ab - allerdings ohne die wichtige Sperrmauer (die als fotorealistisches Modul hätte eingebettet werden können). Einen nahtlosen Anschluß bietet die (wenig detailreiche) Frankfurter City zur extra zu kaufenden, jedoch hervorragend detailreich gestalteten Rhein-Main-Airport-Szenerie; wird letztere zusätzlich installiert, erscheinen plötzlich Bauwerke der City doppelt, was durch Tilgung von Modul-Doubletten (*.bgl) zu beheben ist.

Schönstadt und die Marburg-Szenerie
Die im Netz von www.flightport.de als Freeware angebotene, 16 Scenery- und 92 Textur-Files umfassende Marburg-Szenerie und Aerosofts kommerzieller Scenery Germany 4 enthalten wichtige Daten zum kleinen Verkehrsflugplatz MR-Schönstadt (EDFN) und zur Kernstadt. Die weniger ergiebigen Aerosoft-Daten können gelöscht und durch die Flightport-Varianten ersetzt werden; alle *.bgl müssen in einem Addon-Pfad (\secenery) präsent sein, die *.bmp im Sammel-Pfad FS9 (oder \SG\texture). In den zentralen Pfad \SG gehören (zur Darstellung statischer Objekte) die Flightport Gmax-Library und (zur Vervollständigung von Ortsinformationen) die SG 2-4 betreffenden Aerosoft-Landclass-Dateien. Zum korrekten Einfärben aller (in *.bgl modellierten) Objekte (z.B. Autos) müssen auch die nicht zur Szenerie gehörenden Basis-Dateien (z.B. car*.bmp) in FS9\texture vorhanden sein.

Das unterste Bild zeigt den erst relativ spät entdeckten, direkt an EDFN grenzenden Betrieb Holz-Schmidt, wo ein winziger Gabelstapler (links) emsig durch die Szenerie fährt; wie genau die von Jörg Dannenberg konzipierte Flightport-EDFN ist, zeigt auch das aus einem Screenshot (Cessna 172 rot an AVGAS-Tankstelle) herausvergrößerte Detail mit den auf Null gestellten Tank-Uhren.

Ein am 2.5.2k7 entstandener Tele-Screenshot zeigt die neben dem Zaun geparkte Cessna F-GATJ und dahinter eines der korrekt eingefärbten Kraftfahrzeuge:

Eine noch stärkere Herausvergrößerung zeigt ein weiter rechts hinten geparktes KFZ mit klar lesbarem Nummernschild "DA-EJ 240":

Der Szenerie-Realismus ist beachtlich, dazu ein Vergleich der (am 19.9.2k6 beim Flugtag fotografierten) Realität und der entsprechenden Simulation:
Bild 1 (Foto oben) zeigt EDFN beim Tag der Offenen Tür vom 9.9.2k6, Bild 2 (Mitte) als Screenshot das Add-on im FS9 (mit 'static aircraft' und Markierung), Bild 3 (unten) EDFN als Teil der ebenfalls mit dem Flightport-Addon erweiterten Szenerie im neuen Flugsimulator 10 (FSX): die Objekte lassen sich integrieren, die (unter FS 9.1 authentischer dargestellte) Umwelt entspringt als Autogen-Szenerie weitgehend der Phantasie. Der schwarze Streifen vor den Hallen deutet auf teilweise Inkompatibilität der Bodenstruktur (Ground-Dateien und Apron sind zu entfernen).

Hier der Anflug "in echt" (stark herausvergrößertes und deshalb etwas unscharfes Foto oben) und in der Simulation (unten):

Die Haupt-Objekte sind an ihrem Ort, doch wäre hier noch viel zu tun, um auch in der Schrägsicht des simulierten Anflugs die (hier nicht gewölbt erscheinende) Bodenstruktur natürlich wirken zu lassen.

Simulator-Plätze mit nur relativ kurzer und zudem etwas holpriger Bahn (750 x 30m, Gras wie in Marburg-Schönstadt) eignen sich übrigens gut für vergleichende Tests dahingehend, was sich von dort aus "in die Luft bringen" läßt. Unter dem FS9 ergaben sich für EDFN bisher folgende Flugzeugmuster:
  • Aer Macchi MB 326 (Trainer)
  • Aer Macchi MB 339 (Trainer und Luftunterstützung)
  • Airbus A 300 B4-605R
  • Airbus A 318
  • Airbus A 319
  • Airbus A 320
  • Airbus A 350-1000
  • +Airbus A 400 M
  • +Antonov An-26
  • Antonov An-148
  • ATR-72
  • Avro "Vulcan"
  • BAC Canberra B MkII
  • Brittan Norman BN 28
  • Blériot XII
  • +Boeing 707-131 (alte Ausführung)
  • +Boeing 707-359 (Turbofan)
  • Boeing 717 (hier: Span Air)
  • +Boeing 727-100 F
  • Boeing 727-200
  • Boeing 737-800
  • Boeing 737-900 (hier: ANA)
  • Boeing 757-300 (hier: Oasis HongKong)
  • Boeing 777-222
  • +Boeing B-47
  • +Boeing B-52
  • +Boeing RB-50F "Super Fortress"
  • Boeing C-17 Globemaster
  • Boeing C-22 B (=727)
  • Boeing FA-18E
  • Bombardier CS 130
  • Bombardier Learjet 60
  • ++Bristol Britannia
  • +Canadair "Argonaut"
  • Convair CV 580
  • Convair CV-990 Coronado
  • Dassault Mirage F1
  • Dassault Mirage 2000
  • Dassault SMB 2
  • De Havilland Dash 7
  • De Havilland Dash 8 Q100
  • De Havilland Venom
  • Dornier Do-28
  • Dornier Do-228
  • +Douglas A-4 E
  • Douglas DC-4 ("Rosinenbomber")
  • +Douglas DC-6B
  • Douglas DC 8-72 F
  • +Douglas MD-11 Cargo (hier: LH "WOW"; 2 Versuche, optimal aus Cockpit-Sicht)
  • Douglas MD-81
  • +Embraer EMB-145
  • +Embraer EMB-170
  • *English Electric Lightning Mk II
  • *Eurofighter EF 2000
  • F-4 Phantom
  • *F-16 "Viper"
  • Fairchild Republic A-10
  • Fairey Gannet ASW (U-Jagd-Flugzeug, 2 koaxiale Propeller)
  • Fiat G-91 Gina
  • +Fokker F-27
  • Fokker F-28
  • Fokker F-70
  • +Fokker F-100
  • Fokker 50
  • Fouga Magister
  • Hawker Sea Hawk
  • Hunting Percival Pembroke
  • Ilyushin IL-14
  • Junkers Ju 388
  • +Lockheed C-5 A Galaxy (s.u.)
  • Lockheed C-130 "Hercules"
  • Lockheed P-3 C (U-Jagd und Seeaufklärer)
  • +Lockheed Super Constellation (hier: LH)
  • Lockheed TF 104 (ROCAF)
  • Messerschmitt Me 262 A-1a "Schwalbe"
  • *Mikojan-Gurevich MiG 15
  • *Mikojan-Gurevich MiG 21 bis
  • *Mikojan-Gurevich MiG 25
  • NAMC YS-11
  • Nord 262-A
  • ++Panavia MRCA Tornado GR4 (IDS) nur Flügel ausfahren, nicht auch Bremsklappen
  • Northrop F-5E Tiger II
  • Northrop T-38 (Trainer)
  • *Pilatus PC-21
  • Republic RF-84 G
  • Royal Aircraft Factory Harrier GR 7 (VSTOL)
  • Rohrbach Roland
  • *Saab Viggen
  • Short Stirling
  • Shorts 360
  • Soko Galeb (Trainer)
  • +Sukhoi Su-17 "Fitter K"
  • Sukhoi Su-22 M
  • Transall C-160
  • VFW 614 "ATTAS"
  • Yakovlev Yak-3

Alle Starts in Richtung MR (= RWY 22, leicht abschüssig); selbstverständlich galt immer, für höchsten Auftrieb zu sorgen, den oft sehr kritischen (und lebenswichtigen!) Steigwinkel zu beachten und die Flaps, Vorflügel usw. schon bald vorsichtig schrittweise einzufahren. Besonders sensibel in dieser Hinsicht reagierten die mit "+" bezeichneten Muster, äußerst schnell und wendig die "*"-Typen. Selbst die von 4 GE TF 39 1 C mit je 18.450 kp angetriebene, 75,3 m (und damit ein Zehntel der Bahn) lange, 19,8 m hohe und fast 380 Tonnen schwere C-5A mit einer definierten Startrollstrecke von 3.697 Metern konnte am Bahn-Ende vorsichtig "rotiert" (Bild 3 oben) und kurz darauf zum Steigflug gebracht werden. Stand: WN 27112k7

Von der Simulation zur Realität
Werden in \Eurw und \scenery\world sämtliche Microsoft-*.bgl durch ARE-Daten ersetzt, ergibt sich in Kombination mit den unerläßlichen SG-Landklassendateien (in -world), GermanyLC.bgl (134,240 Bytes, in -Eurw) und der Flightport-Scenery untenstehendes Bild der Marburger Kernstadt. Als Schönheitsfehler fallen u.a. auf, daß 1. die Elisabethkirche hier auf der Ketzerbachkreuzung steht (nicht hinter ihr wie in SG4; immerhin ein Fortschritt, aber noch keine Perfektion) und 2. die Lahn am Ende ihres ausgeprägten Bogens die Stadtautobahn schneidet, was ebensowenig der Realität entspricht. Dennoch genügt eine solche Darstellung, um in einem ersten Anlauf zumindest einige konstitutive Elemente dieser in vielen Jahrhunderten gewachsenen Kulturlandschaft zu vermitteln.

Ein zweiter Schritt könnte darin bestehen, die Simulationen mit der (am 9.9.2k6 aus einer Cessna 172 aufgenommen) Realität zu vergleichen:

Phase 3 greift aus einem zweiten Luftbild wesentliche Elemente heraus, wie in meiner Einleitung zur Landeskunde im WS 2006/07 dokumentiert.


Komplexität vs. Modularität

Die in von mir getesteten Teile der Scenery Germany (1 = Süddeutschland, 2 = Norddeutschland mit Hamburg, 3 = NRW, 4 = Hessen und Thüringen; Mega Airport Frankfurt; Berlin VFR, German Airports 1,3 und 4 zum FS9, GAP 2 vom FS8) enthalten jeweils eine Menge von Landklassen-, Mesh-, AFCAD- und anderen ortsspezifischen Lagedaten und Texturen, von denen einige doppelt oder noch häufiger bzw. in verschiedenen Versionen vorhanden sind, was zu entsprechend doppelter Darstellung topografischer Elemente und von Menschenhand geschaffener Objekte führen kann.

Grundsätzlich lassen sich alle Dateien aus den Aerosoft-Paketen, aber auch aus anderen lokalen Szenerien in ein gemeinsames, zentrales Directory (z.B. "SG") überführen (das sich auf einer separaten Partition befinden und auf das von mehreren FS9-Installationen aus zugegriffen werden kann); dabei werden viele funktional redundante Doubletten eliminiert. Sofern das keine Inkompatibilitäten verursacht (z.B. bei Bäumen oder Bodenstrukturen), können sie mit der jeweils neuesten Version überschrieben werden. \SG umfaßt dann z.B. 2,022,064,320 Bytes mit 4.336 *.bgl in \scenery und 20.582 *.bmp in \texture. Zur Entlastung von SG wandern spezifische Module in Zusatz-Pfade: /SG-Af2, /SG-exclude, /SG-Landclass, /SG-Rivers, /SG-Rivers2, /SG-Roads , /SG-Schiffe, / SG-static, SG-Terrain (texture = leer), /SG-Traffic und /SG-VFR. Auf sie kann auch dann zugegriffen werden, wenn "SG" nicht als Addon optiert ist. In gezielten Versuchen ist zu ermitteln, welche Dateien in die SG-Zusatzpfade gehören, welche Zusatzpfade evtl. entbehrlich sind und welche Dateien im Stamm-Pfad \SG verbleiben müssen.

Das im FS9-Root befindliche, sehr schnell geladene \texture enthält in der originalen FS9-Konfiguration nur die Dateien des Grund-Programms; hier können jedoch auch SG- und Airport-Texturen untergebracht werden - schrittweise, um zu testen, wie viele Dateien nötig sind, um ein Areal korrekt zu laden und darzustellen. Enthalten FS9\texture und FS9\scenery\world\texture zueinander inkompatible Dateien (z.B. versuchsweise aus FS8 oder dem neuen FSX), so kann das Laden gestört werden. Grundsätzlich ist relevant, inwieweit die originalen Microsoft-Szeneriedateien belassen bzw. einbezogen werden. Manche interferieren mit Add-ons; fehlen bestimmte Elemente, wird die Szenerie nur sehr langsam geladen (und das RAM fast bis auf 0 MB verbraucht) oder stockt das Laden; möglicherweise wird das Gelände nur unvollständig dargestellt, wie untenstehender Screenshot verdeutlicht: zwar sind alle nötigen SG-Module aktiv, doch fehlt ein Microsoft-Detail und hört am Übergang von SG3 zur Default-Szenerie der Rhein kurz hinter dem Airport Köln-Bonn mitten im Gelände auf.


Wird das Modul ergänzt, ist der Fehler behoben:

Für solche "Werkstatt-Arbeit" sind die Flüge an den kritischen Stellen abzuspeichern, so daß nach Korrekturversuchen dort exakt fortgefahren werden kann. Überhaupt sollte von Zeit zu Zeit die Begelung kritischer Directories dokumentiert werden, um bei "Verschlimmbesserungen" zum sicheren Stadium zurückkehren zu können.

Wie sich Directory-Strukturen und Lade-Hierarchie auf die Landschaftsdarstellung auswirken, zeigt der in dieser Hinsicht besonders kritische Airport Leipzig-Halle (EDDP). Oben die FS8-Version (7 / 120 Files) in älterer Bebauung:

nachfolgend als FS9-Variante (5 / 12 Files) der neue Airport; die umgebende Grauzone ("terra incognita") signalisiert, daß wesentliche Elemente der Sachsen-Szenerie fehlen (Original-Microsoft-Dateien oder Addon-Files).

nun EDDP in völlig anderer Umgebung und mit korrekter Verkehrsanbindung (aber noch ohne 'static aircraft'):

Hier ein Ende April 2007 entstandener, ziemlich "photorealistischer" Screenshot des modernen Regionalflughafens; die fast parallele Bodensicht kann darüber hinwegtäuschen, wie es mit der Flugplatz-Umgebung beschaffen ist.

Aus unerklärlichen Gründen können nach wie vor größte Probleme mit dieser Szenerie auftreten, wenn im Zuge des weiteren Systemaufbaus Anordnung und / oder Struktur der beteiligten Directories geändert werden; so wurde beobachtet, daß bei zwei verschiedenen FS9-Installationen trotz ausreichend bestückter Root-Texturpfade und über 2 GB an *.bgl und *.bmp enthaltendem Zentralpfad SG2-4 die Szenerie entweder sehr langsam geladen (und dabei das RAM fast völlig verbraucht) wurde oder spezifische Elemente (z.B. Bodenstruktur) fehlten. Problematisch ist und bleibt auch die Anbindung von EDDP an das umgebende Gelände, vor allem dann, wenn "All Streets of Europe" in die Szeneriedarstellung einbezogen werden.

Exaktheit und Perspektive
Generell ist zu fragen, was wichtiger ist: der landschaftliche Gesamteindruck und damit die optische Ästhetik oder die topographische Genauigkeit. Beides scheint angesichts der nur bescheidenen Programm- und Hardware-Ressourcen bislang nicht zu korrelieren. Betrachten wir zu didaktischen Zwecken (deutsche Landes- und Kulturkunde) exemplarisch die sehr reizvoll gelegene, schon im ausgehenden Mittelalter durch Salz-Handel reich gewordene Stadt Lüneburg und ihre Umgebung (rechts: Ausschnitt aus ADAC-Karte), die im dynamischen Überflug präsentiert werden sollen.

Die von Sascha Lindenberg und Arne E. Ehlers geschaffene, eigentlich für den FS8 konzipierte, kostenlose und sehr farbenreiche Szenerie des Flugplatzes von Lüneburg (EDHG) und seiner Umgebung wurde mit großer Akribie und Liebe zum Detail erstellt; informatorisch wichtige Objekte wie z.B. am Elbe-Seitenkanal (zwischen Elbe und Mittellandkanal) das 1974 erbaute Schiffshebewerk Scharnebeck, eines der größten in Europa. Beim VFR-Überflug offenbart sich ein großer Teil dessen, was in der Stadt-Website angepriesen wird: Landschaften an der (durch die Stadt fließenden) Ilmenau, an (der durch Wildwasser-Rennen bekannten, bei Bispingen entspringenden) Luhe und Neetze, Wiesen, Felder und Wälder, das Biosphärenreservat „Flußlandschaft Elbe“ und die nach dieser Stadt benannte Heide. Sie funktioniert auch innerhalb der Grundkonfiguration des FS9.

Was die Topografie als Grundschicht (basic layer) betrifft und schon in bezug auf "All Roads of Europe" beobachtet wurde, gibt es in bestimmten Fällen Inkompatibilitäten zwischen FS8 und FS9 oder wenn Zusatz-Szenerien "übereinander montiert" werden. Probleme ergeben sich dann, wenn eine Szene zusammen mit den Modulen von Scenery Germany 2 in den FS9 eingebunden wird; auf den ersten Blick sieht zwar alles sehr schön bunt aus, doch entdeckt man wenig später, daß nicht nur im alten, von der Ilmenau durchflossenen Stadtkern Häuser und eine Kirche im Wasser stehen (Bild li.), sondern vieles parallel bzw. doppelt vorhanden ist: eine Kirche, der Kreideberg-See, der Fernsehturm, der Elbe-Seitenkanal, das Schiffshebewerk. Auch einige Straßen scheinen doppelt zu existieren.

Zur Problematik noch folgende Anmerkungen:

  1. Auch wenn alle EDHG-Addon-Daten nach \aerosoft\Scenery_Germany_2 transferiert werden, erscheint die Szenerie farbgetreu und korrekt plaziert. Einige der EDHG-Objekte (z.B. Elbseitenkanal, Schiffshebewerk) wirken sogar detaillierter.
  2. Innerhalb von SG2 sind A406*.* verantwortlich für Fernstraßen und Gewässer im Raum Lüneburg; werden sie entfernt, übernimmt
    - (zusätzlich zu ARE- *.hyp) Landscape Germany\Rivers\ die Darstellung von Gewässern,
    - ARE mit *.str, *.rd, *.hwy die Darstellung des gesamten Straßennetzes.
  3. a) Deutschlandbezogene Microsoft-*.bgl können in -\eurw\scenery und -\world\scenery gelöscht und durch Dateien aus Landscape Germany und / oder All roads of Europe ersetzt werden. Werden z.B. alle HL*.* durch g?hyp.bgl aus A.R.E. ersetzt, erscheinen Flüsse und Seen in korrekten Dimensionen und ergeben sich nur wenige vorgelagerte Linien wie z.B. zwischen der Mainau und dem Bodensee-Ufer.
    b) ARE-Schlüssel: hyp = Gewässer (Flüsse, Seen, Kanäle); str = kommunale Straßen, rd = Nahverkehrsstraßen und BAB-Ausfahrten, hwy = Fernverkehrsstraßen (Bundesstr. und Autobahnen).
    c) ARE-*.bgl interferieren mit Microsoft-Modulen und bestimmten Addon-Daten. Sind (ohne MS-Daten) ARE- und SG-Module aktiv und erscheinen Straßen und / oder Flüsse doppelt, so sind in der SG bestimmte Landklassenmodule (z.B. A*_9.bgl) zu tilgen.

Fläche vs. Räumlichkeit
Außerdem kommt es darauf an (und zeigt sich der topografische Wert von FS-Landschaften), aus welchem Blickwinkel man die Szenerie betrachtet. Unter FS9 überfliegen wir wieder Lüneburg, diesmal mit <Ctrl-S> aus der Vogelperspektive. Interessanterweise zeigt die der Ehlers-/Lindenberg-Version unterliegende Topografie nicht die oben festgestellten Doppelungen, zudem offenbart sie erstaunlich viele, topografisch relevante, aussagekräftige Details (Foto rechts). Erst in diesem Vergleich zeigt sich die performative Diskrepanz zwischen der (via Draufsicht vermittelten) 2D-Kartensicht und der (via Mesh, Autogen und photorealistisch eingezeichneten Objekten vermittelten) 3D-Schrägsicht. Lebendig und realitätsnah wird für uns allerdings erst diese offenbar so schwierig simulierbare räumliche Sicht, zeigt sie doch Bauwerke und andere Landschaftsmerkmale als begreifbare mehrdimensionale Strukturen und vermittelt so das Gefühl, tatsächlich über diese und keine andere Landschaft zu fliegen und die damit verbundene Dynamik des Reisens auszukosten.

Von den sehr schön nachgebildeten Flugplätzen St.Gallen-Altenrhein oder Friedrichshafen aus gestartet, sehen wir dank Scenery Germany 1 zwar östl. Konstanz im sog. Überlinger See die einigermaßen naturgetreu nachgebildete Insel Mainau, doch in der 3D-Schrägsicht liegt Konstanz selbst an unüberwindlichen Ufern, Brücken suchen wir vergebens. Die Zeichner haben also noch jede Menge zu tun.

Im Gegensatz zur an topografischem Kartenmaterial orientierten Vogel-Perspektive benötigt die 3D-Schräg- oder gar Bodensicht ein Vielfaches an mehr oder weniger schnell wechselnden Orientierungsdaten; je größer die Flughöhe, je statischer wirken die überflogenen Landschaften und es genügt noch die in einem schnellen PC verfügbare Grafik-Leistung, um Feinheiten wie die im Bild rechts gezeigten darzustellen. Detailreiche Flugplatz-Szenerien oder städtische Ballungszentren lassen das Bild dagegen ruckeln, werden sie im Tiefflug überquert.

Probleme der Nah-Sicht
In der pointilistischen Malerei, etwa den "Bäuerinnen bei der Arbeit" von Georges Seurat (1859-1891; li.) und anderen neuen Stilrichtungen entsteht der ästhetisch wirksame Gesamteindruck erst aus der Entfernung; im Bild festgehalten wird nur, was der Künstler als wesentlich erachtet. Ähnlich ist es bei 3D-Szenerien des Flugsimulators; oft scheint es, als fliege man über gemalte Landschaften, deren Entwurf das Ziel hatte, einzig die charakteristischen, konstitutiven Merkmale zu integrieren und mehr oder weniger irrelevante Details wegzulassen. Noch aus etwa 2000 Metern Höhe sind viele Simulator-Landschaften auch per Schrägsicht einigermaßen präsentabel (siehe dazu den unter "3. Schlußbemerkungen" eingefügten Screenshot); je tiefer jedoch der Pilot hinuntergeht und je näher z.B. Straßen, Flüsse, Böschungen, Häuser heranrücken, desto grober wird die Darstellung bei der "Flachsicht"; der passende Screenshot unten entstand am 9.8.2k6 bei einem Überflug im Raum Köln-Bonn und zeigt aus geringer VFR-Höhe eine wie "gemalt" wirkende rurale Landschaft.

Je schneller eine Landschaft überquert wird und - das gilt besonders bei naher Flach-Sicht - je mehr Einzelobjekte in kürzester Zeit erfaßt werden, desto mehr ist in Echtzeit zu verarbeiten und darzustellen. Auch High-End-PCs arbeiten beim FS9 schon am Limit; es sind also alternative Verfahren zu finden, die eine solche dynamische Nah-Sicht ohne größeren Detail-Verlust so gestalten, daß nach VFR-Bedingungen tatsächlich ohne potentielle Fehlorientierung geflogen werden kann. In einem bislang noch utopischen Ansatz könnte das sog. ECW-Kompressionsverfahren (Enhanced Compressed Wavelet), das u.a. auch für das sprachwissenschaftlich revolutionäre Großprojekt des sog. Digitalen Wenkeratlas (DiWA) genutzt wird, hier wesentliche Verbesserungen schaffen. Der ECW-Modus bietet eine Technik, die aus einer riesigen, viele GB fassenden Gesamt-Sicht nur aktuell benötigte Detail-Daten auf den Bildschirm zoomt. Das aus der Satellitenauswertung entliehene Verfahren könnte auch dem Simulatorflug zugutekommen, sollte es gelingen, im stark abgeschrägten oder gar bodenparallelen Sichtmodus wichtige Details aus einer hochkomplexen Landschaft in Echtzeit auf den Schirm zu zoomen und auf diese Weise eine Orientierung zu schaffen, die der natürlichen Betrachtungsweise weitgehend entspräche. Im Gegensatz zur Auswertung statischer 2D-Bilder erfordert die dynamische 3D-Boden-Sicht je nach der nötigen Mindest-Framerate ein pro Sekunde oftmaliges Re-Zoomen und (exzerpierendes) Laden der Bildinformationen, eine bislang mit konventionellen PC-Systemen (CPU, Grafikprozessor) wohl noch nicht realisierbare Echtzeit-Performance. Sofern diese jedoch verfügbar ist, müßten auf der Basis genauester GPS-Daten und stereoskopisch bearbeiteter Fotosequenzen Szenerien geschaffen werden, die in einem Vielfachen des zur Zeit üblichen Umfangs metergroße oder noch kleinere Details (z.B. auch Verkehrszeichen und Richtungsweiser) für eine solche "Bodensicht" bereitstellten, was nicht nur VFR-Flüge, sondern auch Fahr-Simulationen bisher ungeahnter Qualität ermöglichen würde.

Bislang müssen wir noch mit allen Nachteilen der 3D-Sicht auskommen, so auch damit, daß sich bestimmte Details erst beim Überflug aufbauen, also wie aus dem Nichts erscheinen (z.B. die Schiffe, Hallen, Häuser der Speicherstadt usw. bei Hamburg2003). Bei FS-ungewohnten Betrachtern mag dies Ausbrüche von Heiterkeit hervorrufen und so den oft mühsam erreichten didaktischen Effekt infragestellen oder zunichtemachen.


Sightseeing-Luftfahrzeuge
Optimal für eine Landschaftserkundung aus der Luft sind
universell einsetzbare Maschinen, z.B. Amphibienflugzeuge
wie die Cessna 208 Caravan Amphibian (o. li.), Hubschrauber
wie der aufwendig modellierte Eurocopter EC 145 (li.) und
der revolutionäre, mit Schwenkrotoren arbeitende Bell-Boeing
V-22 Osprey
(oben)

RAM-Probleme
RAM-Allokation und Programm-Performance (Grafikausgabe, Bildlauf) hängen davon ab,

Unter Umständen kann das RAM schon nach wenigen Minuten einbrechen und, nachdem bis 1,5 GB "gefressen" sind, der Flugbetrieb entweder stocken oder (unter Vista) per einer Fehlermeldung FS9 zum Abbuch gezwungen werden. Unter Vista kann unter solchen Umständen auch nach Beenden FS9 im Speicher verbleiben und nur vom Task Manager entfernt werden. Dieses Verhalten signalisiert, daß entweder bestimmte Szenerie-Elemente fehlen oder mit der Version (hier FS 9) inkompatible Module mit angesprochen werden. Nach Ergänzung bzw. Exklusion der betroffenen Dateien wird 1. die Szenerie wesentlich schneller geladen und kann 2. länger geflogen werden, ohne daß sich das RAM bedenklich reduziert. Wie ergänzende Versuche zeigten, empfiehlt es sich, möglichst alle szeneriespezifischen Texturen im Root (FS9\texture) abzulegen; sie werden dadurch schneller geladen; die *.bgl verbleiben in ihren individuellen Pfaden. Der Umfang von FS9\texture kann dadurch auf bis zu 100.000 Files (oder mehr) anwachsen, was jedoch die Performance keineswegs beeinträchtigt.

Integrierende vs. diskrete Modul-Anordnung (siehe auch oben)
Auch war, wie schon oben festgestellt, die Reihenfolge entscheidend, in der die vielen hundert oder gar tausend Textur-Module geladen und - grundsätzlich - in welchen Directories sie bereitgestellt werden. Zum Vergleich wurden u.a. zwei getrennte, mehrfach optimierte FS9-Installationen verfügbar gemacht:

  1. ein Deutschland-Simulator mit integrierender Datei-Struktur, in dessen EURW-Bereich sich neben wenigen Grund-Dateien alle *.bgl (auch: die ICAO-spezifischen af2-Files) und *.bmp aus diversen Aerosoft-Programmen befinden (Scenery Germany 1-4, Mega Airport Frankfurt, Berlin VFR, German Landmarks); hierbei wurden alle älteren bzw. FS8-kompatiblen Doubletten überschrieben
    Version a): EURW\scenery = 599 MB mit 6.727 Dateien; EURW\texture = 2,697 GB mit 27.451 Dateien; FS9\texture (Root) = 827 MB mit 6.768 Dateien,
    Version b): EURW = 4,55 MB; SG (scenery & texture) = (derzeit) 3,31 GB, FS9\texture (Root) = 121 MB mit 1.142 Dateien;
    allgemeine Grund-Dateien in \scenery\world.
    Version c): alle ortsbezogenen Texturen in FS9\texture verlagert; das externe \SG enthält nur noch die szeneriespezifischen *.bgl.
  2. ein Welt-Simulator mit einem individuellen Deutschland-Bereich FS9\Germany, wo sich in diskreter Anordnung (die oben in \EURW enthaltenen) Flughäfen mit fast ausschließlich platzbezogenen Dateien in (derzeit) 410 Einzel-Pfaden mit jeweils \scenery und \texture befinden; die ICAO-spezifischen af2-*.bgl befinden sich in \SG-Af2; andere, gemeinsam genutzte Deutschland-Daten, z.B. statische Fahrzeuge aller Art, Bepflanzungen usw. befinden sich in den Root-Directories \SG, \SG-LC, \SG-Lib, \SG-Rivers, \SG-Roads, \SG-Segelfl, \SG-Soar, \SG-Traffic, \SG-VFR und (optional, doch nicht immer kompatibel) \SG-Worldcup sowie FS9\texture, andere allgemeine Dateien in \scenery\world.

Beide Anordnungen lassen sich auch für den (wie oben erwähnt teils mit dem FS 9 kompatiblen) Flugsimulator 8 realisieren. Grundsätzlich ist darauf zu achten, daß keine versionsfremden Landschafts-Module einbezogen werden, da sonst das Programm generell oder zumindest beim Laden bestimmter Landschaften abstürzt; u.U. sind zeitraubende Versuchs-Reihen nötig, um durch entsprechendes "Exkludieren" optimale Funktionalität zu erzielen.

Anordnung (1) hat den Vorteil einer sehr einfachen Daten-Struktur (und entsprechend kurzen scenery.cfg); die in den Sammel-Directories \EURW (Version a) bzw. \SG (Version b) enthaltenen Flugplätze müssen nicht angemeldet werden; auch bei langen Überflügen wird aus insgesamt nur 3 Verzeichnissen geladen.
In (2) ist jeder Flughafen in die scenery.cfg aufzunehmen, damit auf die ICAO-spezifischen Daten zugegriffen werden kann. FS9-inkompatible Element sind in diesem wartungsfreundlicheren Gefüge leichter aufzuspüren und fehlende Elemente bzw. Updates "punktgenau" einzusetzen. In der Konfiguration (1) wandern solche Neu-Dateien (*.bgl und *.bmp) in toto zu \EURW; wird mehrfach hinzuinstalliert, dürfen neuere Versionen keinesfalls durch ältere überschrieben oder ergänzt werden: mehrere Versionen derselben Szenerie vertragen sich nicht miteinander und es kann, wie im Falle der Hamburg-Szenerie, schlimmstenfalls zu Programmhängern und -abstürzen kommen - erst nach vielen vergeblichen Datei-Operationen wurde als Fehlerursache die Existenz einer FS8-bezogenen Landclass-Datei ermittelt. Inkompatible Objekt-Dateien (Libraries, *.bgl) können, wie im Falle von Bremerhaven, eine Art Tuch-Schleier über Landschaftsteile ziehen. Im Zweifelsfalle sind Modifikationen aus definierten Einsprung-Punkten heraus (z.B. "Test AOL-Arena", "Test Hafen Aufsicht", "vor dem alten Leutturm auf Neuwerk", -> Bild rechts) auf Objekt-Doubletten oder Texturverfälschungen hin zu prüfen.

Einbezug von Elementen aus dem FSX
Seit Ende August 2k6 ist eine als *.exe 667,153,328 Bytes umfassende Demo-Version des neuen Flugsimulators 10 frei im Internet erhältlich: der Screenshot unten verdeutlicht die sehr detaillierte CRJ-200-Cockpitdarstellung (die Drehschalter auf dem linken Seitenpanel lassen sich sogar bedienen!) und die recht natürlich wirkende Darstellung (bearb. 54.481 Bytes) der überflogenen Insel (St. Maarten, Niederländl. Antillen).

Im Vergleich dazu ein am 7.9.2k6 erstellter FS9-Screenshot (bearb. 55.975 Bytes) mit der CRJ 200 auf dem Vorfeld des Flughafens Leipzig-Halle (EDDP):

Wie (aus dem Vergleich der ähnlich detailreichen Bilder) ersichtlich, braucht sich der optimierte FS 9.1 nicht zu verstecken; dennoch gehört dem FSX die Zukunft. Erste Testläufe zeigen, daß zu ihrem Betrieb eine sehr schnelle und möglichst durch den Grafikprozessor entlastete CPU, noch mehr Speicher und viel Platz auf einer schnellen und robusten Festplatte erforderlich sind. Zwar entspricht die Programm-Architektur in manchem der des FS 9.1, doch sind die meisten Module (Flugmodelle, Effekte, Texturen, Programmbibliotheken) nicht mit diesem kompatibel; so hat es z.B. keinen Sinn, in FS9\modules alle oder auch nur wenige *.dll durch die im Root-Bereich des FSX liegenden Pendants zu ersetzen: unweigerliche Fehlermeldungen beim Start sind die Folge. Die als *.dds vorliegenden Texturen kann FS9 nicht verarbeiten, auch \scenery\base\scenery ist inkompatibel; ebensowenig sollten \props und \world in FS9 durch die FSX-Pendants ersetzt werden.

\global\scenery und -\texture (außer *.dds) lassen sich (als Layer 3) einbinden. Andere Szenerie- *.bgl und *.bmp dürfen nicht als Updates überkopiert werden (sonst ruckelige Performance). Inkompatibel sind auch alle in der Demo enthaltenen Flugmodelle und deren Panels (d.h. deren *.cab und die hierin enthaltenen *.xml). Einzig das Baron-58-Panel ist verwendbar, sofern Beech_baron.cab durch das Pendant vom Juni 2003 ersetzt wird. Testweise wurde - erstaunlich ruckelfrei mit ca. 590 MB freiem RAM - die als Addon optierte FSX-Szenerie \stmaarten überflogen, die sich - unter FS 9.1 - wie folgt präsentiert:

Inzwischen (Mitte Oktober) ist der FSX in den Läden. Erste Versuche mit dem zwangsweise per Internet zu aktivierenden Vollprogramm wurden auf dem mit aktualisiertem Windows XP / SP2 versehenen DELL Inspiron 9100 durchgeführt. Sie verliefen größtenteils enttäuschend. Wenig Bewegungsfluß, meist Ruckeln, und das bei 1 GB RAM und guter Grafik.

Mit dem FSX wurde, vermutlich aus marktpolitischen Gründen, nahezu jede Rückwärtskompatibilität aufgegeben. Zwar lassen sich in \SimObjects\airplanes\ FS9-Flugzeugmuster wie die Cessna 210 Centurion einbinden und auch fliegen, doch ist die Integration von FS9-Szeneriedaten (*.bgl, *.bmp) und Addon-Szenerien möglicherweise problematisch. Ob es möglich ist, die FSX-typischen Grafikdateien *.dds zu *.bmp zu konvertieren und mit den zugehörigen FSX-*.bgl bzw. per Austausch auch im FS9 zu verwenden, ist noch zu untersuchen.

Auch die "professionelle" FSX-Edition enthält überraschenderweise nur wenige Flugzeugmodelle. Im Gegensatz zum FS9 sind die *.mdl-Dateien wesentlich größer, die mit *.dds belegten Texturen-Directories dagegen kleiner. Abgesehen von Performance-Unterschieden bei der Instrumentierung unterscheiden sich die (sämtlich inkompatiblen) FSX-typischen Modelle nur wenig von ihren FS9-Pendants. Die FSX-Konkurrenz führte dazu, daß in letzter Zeit auch die FS9-Modelle immer detailreicher und daher realitätsnäher wurden, so daß in dieser Hinsicht auch der FS9 weiterhin "vorzeigbar" bleibt und daher seinen Charakter als "lebendiges Flugzeugmuseum" bewahrt.

Ebensowenig wie fast alle Szeneriedateien sind auch die meisten FSX-Effektdateien FS9-inkompatibel. Einige Default-Szenerien verblüffen durch ebenso kitschige wie realitätsferne Farbgebung. Addons wie Flightport's Marburg-Schönstadt (EDFN) lassen sich nur bedingt einbinden; Hamburg und Finkenwerder aus dem FS9 erscheinen und verschwinden im Sekundentakt (auch bei Löschung der FSX-*.dds). Die Lahn, ein immerhin teils schiffbarer Fluß, fehlt im FSX-Original. Die mittelhessische Umgebung und andere Landschaften gleichen eher einem Flecktarn-Muster als der Wirklichkeit. Dem Nutzer wird nichts anderes übrig bleiben als entweder teure kommerzielle FSX-Addons zu kaufen (die, wie Helgoland, auch nicht alle erforderlichen Details besitzen) oder geduldig darauf zu warten, bis idealistische "Flightsimmers" entsprechende Zusätze entwickelt und selbstlos als Freeware ins Netz gestellt haben.

Der FSX hat als Computer-Spiel gewonnen: detailreiche Autogen-Szenerien, allerlei Animationseffekte (z.B. Verkehr auf den Straßen) und viele spannende Missionen. Was die landschaftskundliche Didaktik angeht, werden solche hochauflösenden Szenerien nur mit einem erheblichen Mehraufwand an Rechenleistung zu schaffen sein, wofür ein PC mit 2 GB RAM, Dual-Core-Prozessor, schneller Festplatte und Windows Vista zu kaufen wäre. Bleibt (vorläufig) das ernüchternde Fazit, daß es Microsoft mit dem FSX gelungen ist, hier eine Zweiklassengesellschaft zu etablieren.

Nüchternes Fazit: der FSX ist nicht das, was man erwartet hatte. Die letztens (Juli / August 2007) mit dem auf 2 GB RAM erweiterten Acer Aspire 9813 gemachten Versuche sind nicht dazu geeignet, die seitens der Werbung lancierte Euphorie nachzuvollziehen; ruckelige Performance über detaillierten Szenerien, Autogen-verfremdete und daher unwirkliche Spiel-Landschaften, problematische Cockpit-Sichteinstellungen und teils wesentlich verschlechterte Szenerie-Darstellungen, so im Falle von Marburg oder Frankfurt. Vorerst bleibt nichts anders übrig als weiter mit dem bewährten FS9 und seinen stetig verbesserten Add-ons zu arbeiten.

Die obenstehenden Screenshots zeigen, was derzeit im ständig weiter verbesserten FS9 möglich ist. Die von Aerosoft in Paderborn publizierte Helgoland-Szenerie gehört weltweit zu den besten ihrer Art; in puncto Detailgenauigkeit und gestalterischer Sorgfalt bleiben hier - ebenso wie beim "Mega Airport Frankfurt" - keine Wünsche offen und eignen sich solche Darstellungen hervorragend auch und gerade für didaktische Präsentationen.

Eigenschaften bestimmter Szenerie-Typen
a) Kombinierte Szenerien aus photorealistischen Textur-Tiles und eingezeichneten 3D-Objekten (hier: Ausschnitt-Screenshot aus kommerzieller DVD-Szenerie von Tokyo mit Hafengelände und City) sind das zur Zeit erreichbare Optimum und auf den ersten Blick bestechend.

b) Abgeleitet von Satellitenfotos, bieten rein fotorealistische Szenerien meist nur aus größeren Höhen ein genaues Abbild der Wirklichkeit, wenn man von oft seltsamen Pastelltönen absieht; bei Schrägsicht entsteht ein Pseudo-3D-Effekt, im niedrigen VFR-Flug vermißt man jedoch Gebäude, Bäume und andere (eingezeichnete) 3D-Objekte, Starts und Landungen sind unrealistisch, weil ohne Möglichkeiten räumlicher Orientierung.

Wie stark in fotorealistischen Szenerien die wenig aussagekräftige Schrägsicht mit der topografisch exakten Vertikalsicht divergiert, zeigen die innerhalb desselben Ausschnitts erstellten Screenshots:

Wird in Mesh-gestützten fotorealistischen Szenerien das Flugzeug vom Startpunkt aus durch <Y> <F4> (und via Cockpitansicht kontrolliert) in eine größere Höhe versetzt, lassen sich, z.B. im Beobachter-Modus, reizvolle Bildeindrücke gewinnen wie im folgenden Screenshot (über Osaka):

Grenzt  - im Flugsimulator 8 - innerhalb derselben Szenerie die fotorealistische an eine defaultmäßige Boden-Textur, so bietet sich folgende ebenso erstaunliche wie inakzeptable Vertikal-Sicht:

Größere Foto- und Fotokombi-Applikationen wie die Japan Scenery belasten den Computer über Gebühr. Teil-Areale umfassen oft 5.000 oder mehr je ca. 50 kB große Bitmap-"Tiles", die auf 2 DVDs erhältlichen Teile 1 und 2 enthalten rund 81.000 solcher Elemente. Beim Start werden die Texturelemente entweder komplett oder sequenziell geladen, was viel RAM-Speicherplatz benötigt, lange dauert und zu den oben erwähnten Performanzproblemen führt. Außerdem kann es zu Artefakten kommen: weiße Quadrate erscheinen auf der Bildfläche. Endet das "Einzugsgebiet" der fotorealistischen Szenerie und beginnt die konventionelle, meist "Autogen"-unterstützte Bodengestaltung, klappt es möglicherweise nicht mit der Fortführung von Straßen, Flüssen und anderen geodätisch relevanten Linien; das Blau des Flußwassers wechselt im flächig-"fotografischen" Teil zu einem schmutzigen Braun, Übergänge zu frei angebotenen Texturen erscheinen wie verbindungslos eingefügte Schnittmusterbögen, deren oft wiederkehrende Zeichnungen zu jedem x-beliebigen Land gehören könnten.

Die kommerzielle Japan Scenery und die Japanese Airports können als photorealistische Szenerien nicht überzeugen. Die zusammen rund 155.000 (!) Phototextur-"Kacheln" verkomplizieren den Betrieb, die Landschaft ist seltsam verfremdet eingefärbt. Der Übergang von der photorealistischen zur Default-Szenerie ist abrupt und daher inakzeptabel. Wer Lade- bzw. Speicherprobleme hat, sollte die an Kontonummern erinnernden Photo-Texturen (z.B. 103012122303011.agn oder 01322222210101su.bmp) löschen oder durch Entfernen der zugeordneten *_ph.bgl unwirksam machen. Sind (wie z.B. im Tokioter Hafenbereich) die Default-Szenerien ungenau und müssen die Photo-Szenerien deshalb einbezogen werden, sind die allen Flugplätzen gemeinsamen Gebäude-, Bepflanzungs- und Design-Daten im Root (FS9\texture) und die bodenspezifischen Zahlen-Dateien im externen Directory RJ\texture unterzubringen.

c) die Default-Szenerien von Microsoft sind wenig abwechselungsreich und alles andere als authentisch (s. oben das Beispiel Edersee). Oft wiederholen sich bestimmte Flächenmuster (z.B. halbkreisförmige Äcker). Der "Autogen"-Modus fügt je nach Landschaft und Jahreszeit Häuser, Bäume u.a. 3D-Objekte hinzu und schafft virtuelle Spiel-Landschaften; mangels Zuordnungs- oder Wiedererkennungswert entsteht beim Überfliegen Frustration. Autogen-Landschaften sind geographisch-didaktisch ungeeignet.

d)
kombinierte Szenerien aus Landclass- und Mesh-gestützten Basistexturen, Autogen-Elementen und eingezeichneten 3D-Objekten bilden einen annehmbaren Spiel-Kompromiß, wenn nicht absolute Originaltreue verlangt wird, und bieten landschaftliche Charakteristika wie, innerhalb der kostenlos im Internet verfügbaren Szenerie von Japan, die Ansicht des ehrwürdigen Mount Fuji (Fuji San), aus der ich den Screenshot rechts "eingefroren" habe. Nach bisherigen Erfahrungen (seit Februar 2004) erscheinen mir derartige Kombi-Szenerien als am praktikabelsten, vor allem, wenn in Präsentationen flüssige Überflüge und klar strukturierte, auf das Wesentliche beschränkte Darstellungen verlangt werden.

d) AI Traffic ist künstlich generierter, dem Fluggeschehen hinzugefügter Verkehr, entweder nach dem Zufallsprinzip oder anhand definierter Flugpläne, die als Textdatei eingefügt werden. Diese Programme gestatten z.T., sich in den Verkehr einzuschalten, eine bestimmte, wo auch immer befindliche Maschine anzuwählen und deren Flug im Beobachter-Modus vom Start bis zur Landung zu verfolgen. Sowohl die überflogenen Landschaften wie auch die Art und Weise des Fliegens, Landens und Rangierens lassen sich dabei studieren.

1.13. Möglichkeiten eigener Modifikationen (Datei-Editing; Kombination / Austausch von Modulen)
Hierzu wurden bereits im o.a. Vortrag und später bes. im Hinblick auf die Landschaftsdarstellung Möglichkeiten angeführt. Ähnlich wie in einem Betriebssystem lassen sich auch im MS-Flugsimulator viele Module austauschen und durch fortschrittlichere ersetzen, so beispielsweise kombinierte Modell- (*.mdl) und Texturdateien (*.bmp), Paneldateien (*.bmp, *.cfg), Sounddateien (*.wav) sowie *air-Files bestimmter Flugzeuge, topografisch kompatible Landklassen (*.bgl), Szenerieobjekte (*.bmp), Flugmusterdaten (*.flt, *.wx), bedingt auch Instrumentendateien (*.cab, *.gau) sowie Szenerien, sofern mit der jeweiligen FS-Version kompatibel. Viele mit MZ-Header versehene Dateien (*.exe, *.dll, *.gau, ältere *.mdl) lassen sich mit ASPACK oder UPX um 50% oder mehr komprimieren und bleiben lauffähig; leider gibt es bislang keinen Kompressionsalgorithmus für die unzähligen Bitmap-Files (*.bmp) zur Darstellung von Flugzeug- und Landschaftstexturen, die den Löwenanteil einer komplexen FS-Installation ausmachen.

2. mögliche Präsentationen: u.a.
a) Demonstrationen zur Luftfahrtgeschichte. Technik und Layout der Flugzeuge. Cockpits, Zellenstruktur, Bemalung, Flugdynamik
b) Techniken (Strategien) des VFR-Flugs;
c) Start und Landung; schwierige "Approaches"
d) Gestaltung von Flugplätzen und Landschaften
e) orientierende Erkundung und didaktische Präsentation von Landschaften

3. Flugsimulation und Landeskunde
Die zum UNESCO-Weltkulturerbe Dresdner Elbtal gehörende, in der Bombennacht des Februars 1945 stark zerstörte
Innere Altstadt aus der Sicht des Flugsimulators 9 mit eingefügten Objekten: AlbertinumBrühlsche Terrasse, Frauenkirche,
Museen, Schloß und Dom, Augustusbrücke, Semperoper, Zwinger (mit Teich); hinten der nach aufwendiger Sanierung 2006
wiedereröffnete Hauptbahnhof. (Noch) nicht eingezeichnet sind u.a. Kreuzkirche und Gewandhaus.

Hier die um 90° gedrehte, mit Einbezug der LC*.bgl aus Ultimate Terrain Europe und ohne die Topo-Module aus SG Ende November 2008 erstellte Elbufer-Szenerie. Es fehlen einige Details und auch die übrige Bebauung differiert.

Auf den ersten Blick mag es ungewöhnlich erscheinen, die meist als Computerspiel abklassifizierte Flugsimulation in eine geisteswissenschaftliche Disziplin wie die deutsche Landes- und Kulturkunde einzubeziehen. Doch sind auch solche Fachgebiete verpflichtet, sich am Fortschritt der jeweiligen Anwendungsepoche zu orientieren, und gibt es keinen Grund, Methoden und Ressourcen abzulehnen, die einen didaktischen und heuristischen "Mehrwert" erbringen können. Natürlich sind trotz aller erreichten systemaren Verbesserungen reale Überflüge nicht mit virtuellen gleichzusetzen, dennoch bietet eine simulierte dynamische Landschaftserschließung die Möglichkeit, unter sinnvoller Reduktion auf das Wesentliche gerade die konstitutiven, typischen Elemente von Kulturräumen herauszuarbeiten. Vielleicht wird es einmal möglich sein, Landschaften simuliert zu überfliegen, an einem Punkt zu verharren und per Mausklick zusätzliche Informationen zu dieser "Sehenswürdigkeit" abzurufen oder beim Überqueren eines Areals dessen Beschreibung im zugehörigen Dialekt zu genießen. Der didaktische Einbezug der PC-Flugsimulation in die geographische und kulturwissenschaftliche Landeskunde bedeutet zunächst immer eine tiefgehende Auseinandersetzung mit der verfügbaren Hardware, den Möglichkeiten der aktuellen Software und dem Zusammenspiel aller Ressourcen. Das bedeutet möglichwerweise ein Bündel von energie- und zeitraubenden Herausforderungen, doch zeigen zumindest einige der bislang erzielten Resultate und die durchweg positive Resonanz der "Rezipienten", daß sich dieser Aufwand lohnt.

4. Flugsimulation = Kriegsspielzeug?
Die ständig weiterentwickelten Modelle der Flugsimulatoren 9 und 10 bieten natürlich auch wertvolle Einblicke in Geschichte und Anwendung von Jagd- und Bombenflugzeugen, die seit den Anfängen um ca. 1910 in zahlreichen kriegerischen Auseinandersetzungen zum Einsatz kamen. In ihrer weitgehenden Realitätstreue bietet die Simulation so etwas wie ein lebendiges Geschichtsbuch und die Möglichkeit, all das beliebig oft und in verschiedensten Situationen zu testen und begreifend nachzuvollziehen, was menschliche Ingenieurskunst bis in physikalische Grenzbereiche hinein ersonnen hat.

Auch hier war und bleibt - leider - der Krieg der "Vater aller Dinge" und haben Geräte wie unsere oben startende F-104 eine technische Schönheit und gestalterische Ästhetik, die über ihren eigentlichen Zweck (Menschen und Tiere zu töten) hinwegtäuscht. So schaffen militärgeschichtlich-wissenschaftliche und spielerische Beschäftigung mit der Aviatik in gewissem Sinne eine Schizophrenie, die zu erkennen und zu bewältigen bleibende Aufgabe eines jeden ist, der sich mit dieser Materie befaßt - das sage ich als jemand, der im 21. Jahrhundert jede Art von Krieg als Anachronismus empfindet. Dennoch bleibt das Faszinosum einer Simulation, die das technisch Machbare eindrucksvoll vor Augen führt. Wenn dieses technisch Machbare irgendwann einmal einzig im Dienst eines dauerhaften Friedens steht, dann hat die Menschheit gewonnen.

5. Schlußbemerkungen

Die PC-Flugsimulation ist zum einen als Trainingsprogramm für Privatpiloten anerkannt und birgt als "lebendiges Museum" zweitens viele kreative Möglichkeiten, die für die zivilisierte Welt so wichtige, über 100jährige Luftfahrt zu erleben und aktiv nachzuvollziehen: denn es ist ein bedeutender Unterschied, ob man sie in Büchern und Filmen rezipiert oder Gelegenheit hat, historische Flugzeugtypen (wie die oben in Rhein-Main abgebildete Ju-52) anzuschauen oder innovative Muster (wie die Embraer Emb-170 darunter) selbst "fliegen" und ihre Eigenschaften und Möglichkeiten aktiv erleben zu können. Sofern möglich, erschließt der Sichtflug in dynamischem Ablauf den vergleichenden Blick auf Landschaften und somit auch die Schönheit und Charakteristik verschiedenster Regionen und Biotope (Landschaften, Städte, Flugplätze) - eine begrüßenswerte Art kreativer Weiterbildung.

Die MS-Flugsimulatoren können vieles, aber nicht alles. Auch in kommerziellen Programmen bleibt die Landschaftsdarstellung trotz anerkennenswerter Bemühungen die eigentliche Achillesferse aller FS-Versionen. Selbst in Landclass-gestützten Arealen wird selten klar, wo die Realität aufhört und der Autogen-Technik weicht, welche den Landschaften die Authentizität und damit ihre kulturelle Eigenständigkeit nimmt; die Unverbindlichkeit und Beliebigkeit solcher Spiel-Welten steht im Kontrast zur GPS-orientierten Exaktheit der mitgelieferten umfangreichen Navigationsdaten.

Im Vergleich zur Ton- und Bildbearbeitung etwa stellt die anspruchsvolle Flugsimulation wesentlich höhere Anforderungen auch an die Hardware. Nicht jeder Rechner eignet sich zum Simulatorfliegen, auch wenn seine Daten das Gegenteil versprechen. Aufwendige High-End-Notebooks wie der bis 2007 verwandte Dell Inspiron bestechen mit ihrer brillanten und hochauflösenden Grafik (die 1920 * 1200 Pixel der LCD-Anzeige sind bis heute unübertroffen!), haben jedoch möglicherweise Probleme mit dem Zusammenspiel von Betriebssoftware, Speichermanagement und Simulation, während andere weniger kritisch reagieren.

                                                                --.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.--

Seit meinem Vortrag an der Christian-Rauch-Schule sind fast vier Jahre vergangen; mit der Curtiss-Jenny (Bild rechts) hörte es damals auf - aber nicht wirklich, denn es wurden - zumindest in Abständen - weitere Erprobungstests zum Flugsimulator 9 durchgeführt. Die aufwendig beworbene und vor zwei Jahren eingeführte Version X hat zunächst nicht das gehalten, was sich der nicht mit teuerstem Equipment gesegnete User versprach - demzufolge wurde auf meinen Systemen keine weitere Evaluation durchgeführt. Andererseits bietet auch heute noch der FS 9 viele Möglichkeiten, neue, besser gestaltete Flugmodelle zu erproben und Landschaftsdarstellungen zu optimieren.

Wie bereits oben erwähnt, umfaßt die Grundversion des FS9 nur ca. 3,3 GB. Aufgebaut ist das Programm wie ein Betriebssystem. Alle Module sind aufeinander abgestimmt und jeweils sowohl einsichtig wie wart- und ergänzbar; somit können auch tausende von freien oder kommerziellen Add-ons eingebunden werden.

Mit immerhin 51 Flugzeugmustern (670 Cockpitinstrumenten) und 14.367 (sämtlich IATA-codierten) Flugplätzen in 225 Ländern eignet sich die FS9-Basis auch für anspruchsvolles IFR-Training; die Landschaftsdarstellung ist allerdings mehr als primitiv; das zeigt sich besonders im europäischen Teil, wo, wie oben dargelegt, Deutschland mit am schlechtesten abschneidet. Beispiele sind der Edersee, mit 200 Millionen Kubikmetern eine der größten europäischen Talsperren, der Raum Hamburg, wo die Innen- und Außenalster zu einer Art Tümpel zusammenfließen, und das völlig falsch und absolut nichtssagend repräsentierte Stadtgebiet von Marburg (nicht übertrieben ist es festzustellen, daß viele deutsche Landschaften des MS-FS9 in fast allen Gebieten der Welt liegen könnten). Dem durchschnittlichen FS9-Nutzer, der nur seinen Spaß haben will, mag all das egal sein, zumal kann nur der, der eine Landschaft genau kennt, beurteilen, ob diese einigermaßen adäquat dargestellt wird.

Anders einige Locations der USA, z.B. der Großraum Seattle mit seinem Internationalen Flughafen Tacoma International (KSEA); inwieweit er der Wirklichkeit entspricht, müssen wir anhand von Landkarten und Luftbildern überprüfen.

Die Landschaftsdarstellung hängt auch und gerade ab von der Exaktheit des Straßen- und Gewässernetzes. Eine geodätisch bindende Norm gibt es nicht: wie oben vergleichsweise gezeigt wird, nicht einmal beim FSX. Die ganze Gegend mag schöner aussehen, ich kann sogar Baumwipfel oder vor Anker liegende Yachten erkennen, unten fahren Autos auf den Straßen, doch sind es möglicherweise irreale Spiel-Gegenden, die mir in diesen Simulatoren "verkauft" werden. Folglich bleiben die Landschaften die Achillesferse der PC-Flugsimulation und ist hier weiterhin am meisten zu experimentieren.

Solche Experimente sind material- und zeitaufwendig, möglicherweise sind fünf-oder gar sechstellige Dateimengen umzulagern und neu zu ordnen, das kann auch mit schnellen Rechnern Stunden dauern. Zudem empfiehlt es sich, alle Versuchs-Schritte zu dokumentieren, das erfordert viel Platz und führt mit der Zeit zu einer Menge von autonomen FS-Installationen auf externen Festplatten. Die derzeit aktuelle (betriebsfähige) Sicherung fast aller bisher erprobten Bestände auf einer externen 1-TB-Platte umfaßt über eine Million Dateien in rund 350 Gigabytes. In solchen Sicherungen umfaßt allein der Bereich "Gauges" (Cockpitinstrumente) rund 4,5 GB, also mehr als die ganze FS9-Basis, und die gesammelten Flugzeugmuster (z.B. die rechts in einem reizvollen Screenshot abgebildete Saab 340) sind mit rund 90 GB (!) vertreten - das ist noch nicht alles.

Wer eine solch gigantische FS9-Installation startet, muß viel Geduld aufbringen. Es dauert mindestens 10 oder mehr Minuten, bis das sich fast totverwaltende Windows XP (Vista ist noch schlimmer) in /Dokumente und Einstellungen alle Ressourcen aufgelistet und somit zur Verwendung freigegeben hat. Deshalb empfiehlt es sich, einen Aircraft-Pool anzulegen und aus diesem nur die gerade benötigten Muster herauszukopieren. Betroffen sind hierbei auch die teils sehr aufwendig gestalteten Panels. Sollen auch sie gezielt getestet werden, müssen die benötigten Gauges (es können über 100 sein!) immer im individuellen Pfad /panels belassen werden, anderenfalls sind sie aus dem großen Gauges-Pool mühsam herauszusuchen, wenn man diesen nicht in der Testinstallation belassen will. Wer Landschaften testen und optimieren will, dem genügt ein einigermaßen gut handhabbares Flugzeugmuster und der braucht dazu nur das betreffende *.mdl, das Panel, die Sound-Dateien, eine Texturengruppe, eine Air-File und eine *.cfg. Wer Flugzeugmuster in bezug auf ihr Verhalten testen will, kann dies in einer einfachen Landschaft tun und braucht daher keine gigabytegroßen Installationen, deren Ladung viel Zeit und RAM-Ressourcen benötigt.

Wenn man von den Landschaften und ihrer Problematik absieht, funktioniert der Rest des Flugsimulators problemlos. Schon in der Basisversion lassen sich kleine Verbesserungen erzielen, auch wenn man einen Gesamtumfang von ca. 4 GB nicht überschreiten will. Im wesentlichen handelt es sich um Sound-Dateien, die aus neueren, möglicherweise kommerziellen Mustern übernommen werden und z.B. eine Cessna 172 oder 182 realistischer klingen lassen, oder um Panels, die der Wirklichkeit im jeweiligen Flugdeck besser gerecht werden.

Schwierig wird es, wie in den Jahren immer wieder leidvoll erlebt, einzig mit den Landschaften. Wie oft wurden frustrierende Erweiterungen vorgenommen, brach dann der Ladevorgang ab, war das Ganze letztlich zu verwerfen. Und dann wurde wieder "ab ovo" neu angefangen mit der Basis, wurde vorsichtig hinzuinstalliert bis zum nächsten "GAU" und entstand die Frage, wie dieser zustandegekommen war - ob durch nur eine Datei (von -zigtausenden), ob durch eine falsche Priorität in der scenery.cfg oder sonst etwas. Nach alledem bleibt das Fazit, daß es immer gut ist, wenigstens auf einem Datenträger (z.B. einer hochwertigen DVD) einen installierten Original-FS 9 zu haben. Soll erweitert werden, ist dieses Original auf die "Experimentier-Plattform" zu kopieren, und dann kann es losgehen. Zur Auswahl stehen komplexe Einzel-Szenerien (z.B. Heathrow, Frankfurt) oder Komplettpakete wie Aerosoft's "Scenery Germany" (1-4) oder "German Airports" oder die "All Roads of Europe" usw., und dann kommen, wie erwähnt, die lustigen Fälle, daß Flüsse oder Straßen zu parallel oder überkreuzenden Zwillingen mutieren, daß Türme, Schlösser u.a. doppelt nebeneinanderstehen usw., und man hat zu suchen, woran das liegt - oft gibt es keine Hinweise zur Wirkungsweise bestimmter Module. Diese sind aber unbedingt wichtig um zu wissen, was - bestimmten Fällen - mit wem zu kombinieren und was zu exkludieren (zu tilgen) ist. Konkreter Fälle:

Ökonomie ist oberstes Gebot für alle FS9-Installationen, das betrifft auch das Speichern und Verfügbarmachen der Daten. Die fünf- bis sechsstellige Zahl der viel "Luft" enthaltenden Bitmaps (*.bmp) in den Flugzeug- und Szenerietexturen legt es nahe, komplexe Simulator-Konfigurationen mit allen Bereichen auf einer mit Kompressions-Option versehenen Platte unterzubringen; in meinem speziellen Fall sind auf einer 2,5"-USB-Platte (WD Passport) von 160 GB Sicherungen sowohl des FS 9 (in zwei größeren Konfigurationen zu 89 und 22 GB) und des FS 8 (mit über 700 Flugzeugmustern, nun 43 GB) sowie der Komplex Flight Instruction (> 2 GB) sowie andere Daten (ca. 2,1 GB) in der einzigen Partition untergebracht. Die 6-stellige Dateibelegung nachträglich zu komprimieren hätte sehr lange gedauert, deshalb wählte ich eine andere Lösung, lagerte zunächst alle FS-Daten auf eine externe 1TB-Platte um (dar dauerte über acht Stunden), administrierte dann die nun fast leere 160GB-Platte mit Kompress-Option (knapp 1 Minute!) und spielte dann alle ausgelagerten Daten zurück (was wiederum ca. acht Stunden in Anspruch nahm), um hernach die Platte (mehrere Stunden lang) zu defragmentieren. Der bei dieser komplexen und risikoreichen Prozedur erzielte hohe Gewinn zeigt sich darin, daß noch rund 32 GB frei sind, obwohl die FS-Konfigurationen und die anderen Daten eine (gerundete) Summe von über 159 GB aufweisen.

Vereinfachungen sind schon in der Grundversion möglich. Im Bereich /scenery läßt sich außer /base und /world alles in einen Pfad /other verschieben, die Texturen wandern ins Root. Das stört die Performance nicht im geringsten. Wer die Städte getrennt haben will, kann alle Photo- und anderen Szenerien (z.B. London) in /cities/scenery gruppieren und alle übrigen Files in /other/scenery belassen. Wer im europäischen Raum separat experimentieren will, muß /Eur-w und /Eur-e zusammenfassend als /Eur ausgliedern (und kann alles exkludieren außer AT*.bgl, NV*.bgl und OB*.bgl). Danach entsteht eine stark vereinfachte scenery.cfg wie z.B. (aber nicht zwingend!) hier:

[General]
Title=FS9-Umweltszenerien
Description=FS9 Scenery Data
Clean_on_Exit=TRUE

[Area.001]
Title=Standardgelände
Texture_ID=1
Layer=1
Active=TRUE
Required=TRUE
Local=Scenery\World
Remote=

[Area.002]
Title=Standardszenerien
Local=Scenery\BASE
Layer=2
Active=TRUE
Required=TRUE
Remote=

[Area.003]
Title=City-Photo
Local=Scenery\Cities
Layer=3
Active=TRUE
Required=TRUE
Remote=

[Area.004]
Title=Other Sceneries
Local=Scenery\Other
Remote=
Active=TRUE
Required=FALSE
Layer=4

[Area.005]
Title=Add-On-Szenerien
Local=Addon Scenery
Layer=5
Active=TRUE
Required=FALSE
Remote=
[Area.006]
Title=EUR-MS
Local=Scenery\EUR-MS
Remote=
Active=TRUE
Required=FALSE
Layer=6

[Area.007]
Title=UTEurLC
Local=Scenery\UTEurLC
Remote=
Active=TRUE
Required=FALSE
Layer=7

Alle neuen *.bgl kommen in /addon scenery/scenery, alle neuen Texturen in Root-/texture; größengleiche Dubletten werden übergangen (skipped) oder durch neuere Versionen überschrieben, das verhindert a priori jegliche Redundanz (für nur eine Szenerie spezifische Boden-Objekte sind separat in /addon scenery/textures unterzubringen).

Als erstes sind alle größeren Szenerien neuesten Datums zu installieren; nach jeder Installation ist ein Backup anzulegen. In der Folge dürfen identische Module nicht überschrieben werden, falls sie einer früheren Version angehören. Ältere Dateien wie z.B. London.bgl und die zugehörigen Texturen (z.B. LON_Hammersmith.bmp) aus der Basis-Version sind dann zu tilgen, wenn eine umfangreichere (kommerzielle) Version derselben Location hinzuinstalliert werden soll, damit nicht bestimmte Objekte doppelt erscheinen und geographische Linien durcheinanderlaufen.

Wird dieses Vorgehen strikt eingehalten, kann die obige Szenerie-Konfigurationsdatei unverändert erhalten bleiben. Falls Texturelemente (z.B. Häuser, Brücken, Bodenflächen, Schiffe) unnatürlich weiß erscheinen, sind (in Root-/texture oder addon scenery/texture, s.o.) aus Großszenerien bzw. Komplettpaketen geeignet erscheinende Texturen nachzuinstallieren, um die geforderten Farben herzustellen, damit während einer Simulation aus diesem zentralen Pool alle korrekten Texturen "on demand" geladen werden können. Root-/texture kann bis auf 100.000 oder mehr Dateien anwachsen, das beeinträchtigt jedoch nicht den Programmstart.

Besonders kritisch sind Szenerien wie z.B. Paderborn-Lippstadt (EDLP, hier Standardversion, Bild oben) oder Talbrücken (Bild rechts). Werden bei einer sukzessiven Szenerie-Installation in ein Sammeldirectory (s. oben) neuere Module durch inkompatible ältere überschrieben, kann es sein, daß das Laden von EDLP sofort abbricht oder die Talbrücke vom korrekten Straßenverlauf versetzt oder gar nicht erscheint. Kritisch erwies sich in dieser Hinsicht auch die Szenerie von Cuxhaven-Grimmershörn, die bei gleicher Dateienanzahl völlig verschieden ausfallen kann: links unten in der völlig nichtssagenden Microsoft-Einheitstextur, rechts weitgehend der Realität entsprechend (verfizierbar an Details wie der angedeuteten Festung Kugelbake oder dem Küstenverlauf), falls die zu Niedersachsen gehörenden Topo-Module der Aerosoft-Szenerie nicht fälschlich überschrieben wurden.

Leider wird man mit vertretbarem Aufwand wohl kaum eine Installation realisieren können, in der alle wichtigen Landschaften gleich gut dargestellt sind. Was der einen Landschaft förderlich ist, kann einer anderen schaden, so im Falle der Edertalsperre: nur ohne die Scenery-Germany-Module und mit UT-Eur läßt sie sich inclusive der Randstraße korrekt abbilden, doch verschwindet dabei (trotz der noch vorhandenen Landmark-Module) das auf dem Berg gegenüber der Sperrmauer liegende Schloß Waldeck und sind u.U. vorher einkopierte Großszenerien wie z.B. Leipzig-Halle oder Cologne-Bonn nicht mehr mit allen Farben korrekt ladbar. Gut, wenn zuvor der letzte Konfigurationsstand gesichert wurde.

Die oben angemahnte Ökonomie (und Redundanz-Exklusion) betrifft auch neu hinzuoptierte Flugzeugmuster. Alle Cockpitinstrumente wandern in /gauges (wo ebenfalls übergangen bzw. überschrieben wird); sofern unnötig, werden alternative Bemalungen (liveries, *.bmp) weggelassen und, sofern mehrere Maschinen dasselbe Triebwerk nutzen, die zugehörigen, typenspezifisch bis 50 MB oder mehr umfassenden Sound-Files nur einmal an zentraler Stelle (z.B. /fsound) abgelegt und jeweils in der sound.cfg (z.B. mit [fltsim] alias=k:\fsound\C-210) optiert. Welche 32-Bit-konformen MZ-Dateien (*.gau, *.dll, *.exe, auch ältere *.mdl ohne RIFF-Header) ohne Funktionsbeeinträchtigung (z.B. mit UPX) gepackt werden können, ist im Einzelfall zu erproben; u.U. lassen sich dabei viele Megabytes an Dateiumfang einsparen. Mit mehreren großen Szenerien und 30-40 detailliert gestalteten Flugzeugmustern sind - nach gegenwärtigen Maßstäben - "repräsentative" und auch für Demos (z.B. zur Luftfahrtgeschichte) geeignete FS9-Installationen bereits ab 8 - 10 GB zu realisieren; die derzeit letzte (Ende 12/2k8) , nach obiger Strategie erstellte, auch japanische Groß-Szenerien enthaltende "Kompakt-Version" umfaßt etwa 25 GB.

Auch der in die Jahre gekommene FS 8 läßt sich ähnlich neu erforschen, dateimäßig zusammenfassen und zu einem beachtlichen Demonstrationspaket erweitern. Viele für den FS 9 konzipierte Flugzeuge und Szenerie-Bausteine lassen sich integrieren, überhapt enthält, wie bereits angedeutet, der FS 8 wesentlich mehr fluggeschichtlich relevante Muster als sein Nachfolger (Bild oben: Short Sandringham) und ist schon deshalb noch immer eine - zumindest museale - Alternative. Aus diesem Grunde wurde Ende 2008 aus in rund vier Jahren gesammelem Material systematisch getestet, welche Flugmodelle sich im FS 8 darstellen und fliegen lassen; dabei zeigte sich, wie in meinem separaten Text erwähnt, eine erstaunliche Vielfalt.

Im Vergleich mit seinem Nachfolger dürfte der FS 9 das letzte wirklich offene und vom Nutzer wart- und ergänzbare System bedeuten. Im FS X ist vieles zur Spielerei entartet und es entsteht die Frage, was ich mit einer aus hundertausenden von Dateien bestehenden Landschaft soll, die letztlich doch nicht oder nur teils authentisch ist und deren Präsentation in didaktischen / wissenschaftlichen Kreisen mit Gelächter quittiert wird. Andererseits gibt es dort bestechende, mit viel Liebe zum Detail erstellte Szenerien wie den Aerosoft-"Heimatflugplatz" Paderborn-Lippstadt (EDLP), der kürzlich auch für den FS9 publiziert wurde. Solche ausgearbeitete Szenerien werden langfristig immer mehr Nutzer zum FS X hinziehen, sofern das nötige Equipment bereitsteht.

Vergleichsweise kann im VFR-Modus das seit einiger Zeit verfügbare Google Earth herangezogen werden, dessen Flugsimulator zwei Maschnen zur Verfügung stellt; eine schnelle Internetanbindung vorausgesetzt, läuft er auch auf Netbooks und Business-Notebooks mit bescheidenen Grafikkarten und läßt sich zudem mit einem Joystick betreiben. Die Szenerien beruhen auf verschieden alten und entsprechend eingefärbten Satelliten-Fotos; wie in rein fotorealistischen Microsoft-Szenerien wirken Bauten nur aus größeren Höhen dreidimensioinal, markante Bauwerke wie z.B. Marburgs Landgrafenschloß oder die Elisabethkirche fehlen, was die gezeichneten MS-Flugsimulatorszenerien plastischer erscheinen läßt.

Der bereits angekündigte Nachfolger des FS X wird nur noch mit sehr aufwendiger und entsprechend teurer Hard- und Software zu beherrschen sein; kostenlose Add-ons werden der Vergangenheit angehören. Gute, äußerst akribisch aufbereitete und wirkungsvolle Add-ons (die größtenteils auch im FS8 laufen) gibt es aber weiterhin für den FS 9; die immer detailreicheren und ästhetisch schönen Flugzeugmuster und die sogfältig erstellten Sound-Dateien werten ihn auf - das schafft Befriedigung und ermöglicht eine Motivation und Kreativität, die zum ernsthaften Betrieb eines PC-Flugsimulators unerläßlich sind.

Ohne Gewähr (siehe Disclaimer). Änderungen und Ergänzungen vorbehalten. Stand: 19.7.2013