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 32 / 512 |
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:
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:
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:
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
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 |
1,15 | |
Bild 2
Microsoft |
1,25 | |
Bild 3
Microsoft |
0,935 | |
Bild 4
(MS) |
0,952 | |
Bild 5
(MS) |
ca. 1,1 | |
Bild 6
(MS) |
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 |
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:
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.
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:
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:
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: Albertinum, Brü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