Oliver Pabst ist sicher einer der bekanntesten Akteure in der deutschen Flugsimulator-Szene und auch international für sein Programm “Airport Enhancement Services“, kurz AES, bekannt. Wir hatten die Gelegenheit zum 8. Geburtstag von AES ein Interview mit dem Vater der Idee zu führen und konnten erfahren, welche Komplexität hinter der Entwicklung steht. Happy birthday AES…

simFlight: Nahezu jeder Simmer in der Flusiszene kennt Sie durch die Airport Enhancement Services, kurz AES. Gibt es noch weitere Projekte von Ihnen?

Nein, im Sinne eines eigenständigen Produktes nicht. Aber viel meiner für die FS Entwicklung zur Verfügung stehenden Zeit fließt auch in Produkte anderer Entwickler ein, die der Kunde mir dann nicht unbedingt zuordnet. Am bekanntesten ist hier sicher AESLite, der animierte Verkehr auf und rund um den Airport. Vor einigen Jahren habe ich mich aber auch dem Thema realistischer Landebahn und Anflugbefeuerungen gewidmet, die in vielen Produkten zur Anwendung kommen und die begrenzten Möglichkeiten der Standardbeleuchtung ersetzen. Zudem gab es in den letzten Jahren viele Airport Addons, die eigentlich nur für den FSX entwickelt wurden. Da der FS2004er Simulator aber nicht so tot ist, wie ihn einige sehen wollen, gerade im weltweiter Marktsicht, habe ich auch dort Tools entwickelt, die eine Umsetzung für den FS2004 noch ermöglicht haben. Also alles mehr Produktbestandteile, die viele nutzen.

simFlight: Haben Sie beruflich auch mit Softwareentwicklung zu tun?

Ich bin seit 30 Jahren freiberuflich als IT-Consultant tätig, mitunter auch für ein großes deutsches Luftfahrtunternehmen. Die Entwicklung von FS Software war immer schon ein Hobby, mit dem Erfolg von AES konnte dann nicht nur die Freizeit für diesen Bereich genutzt werden, sondern es wurde auch ein, wenn auch kleiner Bestandteil meiner täglichen Arbeit. Somit wurde der Übergang zwischen Beruf und Hobby fließend. Leider wird die Freizeit so auch zum Teil des Berufsalltags. Mein letzter Flug zum Spaß mit dem FS ist leider Monate her.

simFlight: Seit wann beschäftigen Sie sich mit der Flugsimulation?

Als ich 1984 meinen ersten PC bestellt habe, war die Bedingung, dass der Händler mir ein Microsoft Flugsimulator Version 1.0 kostenlos dazu gibt. Das war der Anfang alles Übels. Seit es dann Anfang der 90er die Designtools für Aircrafts und Scenery von Sublogic gab, beschäftige ich mich mit der Entwicklung von Addons. Diese wurden schon damals via Modem auf die BBS [Red.: Bulletin Board System, früher als Mailbox bekannt] von Miguel Blaufuks (der der heute Simflight betreibt) „hochgeladen“ und so von vielen genutzt.

simFlight: Wie kam es zu der Idee für AES und wie lange hat die Entwicklung von AES gedauert? Können Sie sich noch an den Funktionsumfang der Erst-Version erinnern?

AES geht im Grunde auf meine Freeware von Bremen im FS98 zurück. Damals noch mit trickreicher Auslegung der Bordmittel des FS Codes von Bruce Artwick (BGLC/ASM Code) umgesetzt, gab es ja dort schon dort Follow-Me, Jetwayanimation, Catering und Tankwagen.
Mein damals noch betriebenes Hobby im FS bestand nicht nur aus dem Fliegen von A nach B, sondern im Simulieren ganzer Umläufe. Gut umgesetzte Flughäfen gab es ja, allerdings waren sie doch relativ unaufregend in dem Zeitraum am Boden. Hier fehlte eindeutig Leben rund um den Flieger. Da setzte der Gedanke für ein AES an.

Allerdings waren die Möglichkeiten der FS Mittel sehr begrenzt, ein kleiner Flughafen wie Bremen war damit umsetzbar, wenn auch nach Monaten Arbeit, größere Airports wie Frankfurt waren so aber undenkbar.

Mit dem legendären EMMA Field Projekt, das ca. 2002 im Hause LAGO entstand, lernte ich Maurizio Gavioli kennen, einer der Guru’s der FS Scene. Er war schon viele Jahre sehr tief in den FS eingetaucht und hat vor der Zeit von SDK’s (die gab es erstmals für den FS 2000 so richtig) viel Analysearbeit geleistet.

Mit seiner Hilfe ist dann die Idee gereift und zur Umsetzung gebracht worden, die heute unter den Vistamare Intelliscene Modulen bekannt ist. Im Grunde dienen diese Module als Befehlssatzerweiterung der BGLC/ASM Grafikengine des FS, so das komplexe Abläufe berechnet und gesteuert werden könne.

Der Vorteil dabei ist, dass diese Berechnungen bei jedem Framedurchlauf direkt in der Engine erfolgen, somit können Animationen sehr „smooth“ berechnet werden.
Auch wenn heute einige Personen BGLC/ASM (Bruce Artwick Graphic Language) als „alten Code“ bezeichnen, so ist dieser extrem schnell, da quasi Maschinencode (ähnlich Assembler). Und dieser Code hat auch nichts damit zu tun, dass Scenerydarstellungen langsam (Framefresser) sind, dass hat andere Gründe.

Auf dieser Basis wurde AES dann erst möglich für den FS 2004. Es hat aber noch einige Jahre bis 2006 gedauert, bis eine Grundkonzeption gefunden wurde, die auch für viele Airports umsetzbar war, bei einem überschaubaren Arbeitsumfang.
AES erschien ja dann genau vor 8 Jahren zum Nicolaus 2006, damals nur mit Jetways, Treppen und Catering. Das erste Paket enthielt auch nur 3 Flughäfen (Frankfurt, Nürnberg und Hannover), hat aber offensichtlich den Nerv der FS User getroffen. Nach ein paar Tagen war klar, da muss mehr kommen. Heute, 8 Jahre später, sind über 500 Addon Airports mit AES versorgt.

simFlight: In den letzten Monaten liest man immer wieder Kommentare von Nutzern, welche die Weiterentwicklung von AES als “eher schleppend” bezeichnen würden. Können Sie diese Einschätzung nachvollziehen?

Man liest viel in Foren, komisch nur, dass dort nie Personen beteiligt sind, die sich mit dem Design von Addons beschäftigen. Meine Kollegen sehen das deutlich differenzierter und realistischer.
Ich wäre heute gerne schon deutlich weiter, Ideen gibt es ja viele. Leider hat auch mein Tag nur 24 Stunden und Entwicklung für den FS ist gerade in den letzten Jahren nicht einfacher geworden, sprich zeitintensiver.

Anfang der 2000er wurden Pakete mit 5-6 Flughäfen binnen weniger Monate in (aus damaliger Sicht) hervorragender Qualität entwickelt, heute dauert alleine ein Flughafen länger, Heathrow zum Beispiel mehr als ein Jahr und das nahezu in Vollzeittätigkeit.

Wir müssen bei der Entwicklung heute 4 Plattformen (FS2004, FSX, P3D und ggf. noch X-Plane) im Blick haben, selbst bei den Mircosoft basierenden hat jede ihre Eigenheiten.

Der Anspruch an Detailgrad, HD-Hype etc., der seitens der Nutzer an die Addons gestellt wird, muss auf einer 10 Jahre alten Technologie bedient werden, die sich auch bei P3D nicht wesentlich geändert hat. Die Weiterentwicklung in Bezug auf Addon Qualität ist also nur durch die Entwickler der Addons erfolgt, die Plattform ist die gleiche wie vor 10 Jahren. Das kostet halt auch mehr Zeit, bis ein Schritt getan ist. Flughäfen, die früher in ein paar Monaten fertig waren, dauern heute mehrfach so lange, mehr als ein Jahr ist da keine Seltenheit mehr, ohne das der Entwickler zwischendurch Däumchen dreht.

Bei AES steht für weitere Features ein Schritt an, mehr Daten konfigurieren zu können. Dieser hat aber tiefgreifende Auswirkungen im Code, Teile davon sind schon fertig, einige fehlen noch. Dass sieht der User natürlich nicht.

Bei AES gibt es neben den Usern, die neue Features erwarten, noch diejenigen, die neue Addon-Airports schnell versorgt haben möchten. Da muss man dann einen Kompromiss eingehen, damit zumindest am Ende alle glücklich werden.

simFlight: Wie muss man sich als Nicht-Programmierer die Komplexität hinter AES vorstellen?

Die Komplexität ist nicht der programmtechnische Ablauf, der ist eigentlich recht simpel. Die Komplexität entsteht zum einen durch die Programmierung in dem maschinennahen Code, der ist nicht so einfach ist, wie heute üblich höhere Programmiersprachen. Bei denen gibt es für alles vorgefertigte Bibliotheken und Funktionen, die der FS nicht liefert.

Auch wenn der FSX/P3D heute mit Simconnect deutlich besser Schnittstellen bietet, so ist für die spezielle Aufgabe von AES, die ja mit dem Fliegen an sich nichts zu tun hat, kaum Unterstützung des FS selbst vorhanden, man muss sich vieles selber stricken, das erzeugt Aufwand.

Ein wesentlicher Komplexitätsfaktor bei AES ist die Unbestimmtheit der Situation, in der die Fahrzeuge rund um den Flieger des Users agieren müssen. Bei großen Flugzeugen ist genug Platz. AES soll aber auch mit der CRJ funktionieren. Da muss man dann sehr lange dran feilen, dass es eben für alle passt, egal wie der User den Flieger parkt, das macht es komplex.

Was es heute zusätzlich komplex und langwierig macht – und das gilt nicht nur für AES sondern alle Scenery Produkte – ist der Optimierungsaufwand den man betreiben muss, um den gestiegenen Ansprüchen an Detailtreue und Texturenauflösungen gerecht zu werden.

Die Flugzeuge werden immer „Systemtiefer“ und nehmen kaum Rücksicht auf die begrenzten Ressourcen des FS. Dem landschaftsbezogenen Designer bleibt nur der Kaffeesatz der Auflaufzeit (Frames), damit soll er dann aber schöne Dinge zaubern, ohne dass eine Diashow entsteht. Hier die richtige Technik und Ausgewogenheit zu finden, kostet heute im Design viel Zeit und macht es noch komplexer.

simFlight: Welcher Teil von AES hat Sie während der Entwicklung am stärksten herausgefordert?

Ganz klar die Menschenanimation. Fahrzeuge und Jetways sind nun mal Maschinen, da sind die Bewegungsanimationen klar beschränkt: Drehen und Verschieben.
Dafür bietet die Engine des Flugsimulators genügend Funktionen, da dies ja auch bei den Flugzeugen benötigt wird.
Menschen sind nun mal keine Roboter, der FS kein Ego-Shooter, bei dem die ganze Engine auf Menschenanimation ausgelegt ist.
Um nun das Personal rund um den Flieger einigermaßen realistisch zu bewegen, bedarf es hier vieler Tricks und aufwendigen Versuchen, bis man es mit den begrenzten Mitteln umgesetzt hat. Im FSX ist es etwas einfacher, da hier zumindest eine statisch ablaufende Skinned-Mesh-Animation möglich ist. Nur hilft diese wenig, wenn man bei jedem Flieger und verschiedensten Ausgangssituationen unterschiedlich reagieren muss. Hier bedarf es dann einer eigenen Bewegungsanimation, die auf beliebige Situationen reagieren kann, ohne dass es nach Roboter aussieht.

Dieses ist auch mit der Grund, warum es heute noch keine Beladunganimation in AES gibt, denn immer derselbe Ablauf, nur damit sich was bewegt, dass ist mir dann doch zu simpel. Vielleicht ist da aber auch nur mein Anspruch zu hoch, wir werden es sehen.

simFlight: Welche Einschränkungen im Microsoft Flight Simulator X gibt es, die Ihnen die Entwicklung erschweren?

Es ist ein Flugsimulator, Animationen sind da auf das Bewegen von Landeklappen und Fahrwerken orientiert, vielleicht noch ein drehender Radarturm, das war es.
Leider ist die Abwendung im FSX von einer „Programmierung“ der 3D Objekte, so wie es Bruce Artwick in seiner Engine angedacht hatte, nicht hilfreich, wenn es um die Steuerung von animierten 3D Objekten in der Scenerie geht.

Die 3D Objekte sind heute reine Tabellen von Punkten, Polygone und Materialien, einmal kompiliert in ein MDL File. Diese werden dann via XML Tabellen platziert.
Zur Laufzeit des FS ist da keine Veränderung mehr vorgesehen. Für statische Gebäude hinreichend, für situationsbedingte Animationen eher nicht.
Gut, der FSX hat heute ein AI Bewegungssystem, dass man auch für Fahrzeuge auf dem Vorfeld nutzen kann, das gab es beim FS2004 nicht. Leider hat man aber nur wenig Einfluss darauf, wie der FS die Fahrzeuge bewegt, da kommen dann auch schon mal sinnfreie Bewegungen heraus, die muss man dann ignorieren. Schön ist anders.

simFlight: Ein großer Kritikpunkt ist, dass die Aerosoft Flughäfen zwangsweise AES Credits benötigen, um vollen Funktionsumfang zu bieten. Was ist der Grund, dass die Fluggastbrücken der meisten Aerosoft Flughäfen nicht ohne AES funktionieren. Wir das auch zukünftig so sein?

Wo wir wieder bei den Forum Experten wären. Witzig ist immer, dass es meist die gleichen Experten sind, die die bedingt realistische Jetwayanimation im FSX als ein „Must have“ bezeichnen, andererseits sich beschweren, wenn eine Landeklappen- oder Fahrwerksanimation eines Addon-Flugzeuges nicht exakt wie beim Original umgesetzt ist.

Es ist jedenfalls Quatsch, dass hier eine „Order“ oder „Zwang“, von wem auch immer gefordert, existiert. Hat es nie gegeben und die Entscheidung darüber, wie die Jetways bei einer Scenery umgesetzt wird, trifft der Entwickler der Scenery selbst. Und es gibt auch schon lange sowohl von Aerosoft selbst entwickelte (z.B. Paderborn) als auch von ihnen nur vertriebene Flughafen-Addons (z.B. Simwings Paris, Mallorca …), die die Animation der Jetways nutzen, trotz AES.

Für mich und AES ist es sogar viel einfacher, wenn die Jetways als einzeln animiertes Modell via AFCAD platziert sind, dann kann ich sie mit AES problemlos entfernen und auch die Jetwaymodelle sind dann ja animationstechnisch vorbereitet gestaltet.
Für mich viel unangenehmer (bis hin zum No AES possible) sind solche Airports, wo die Jetways fester statischer Bestandteil der Gebäudemodelle sind, die bekomme ich nicht weg.

Um auch gleich die Frage zu beantworten, warum ist AES nicht Bestandteil des Scenery Produktes?

Weil es eben ein eigenständiges Produkt von unterschiedlichen Entwicklern ist, wie soll man dort den „Wert“ beziffern, um den der Airport teurer sein muss, damit der Aufwand entlohnt ist. Dies ist in der Struktur, wie Addons heute von vielen verschiedenen eigenständigen Entwicklern produziert werden, schwer zu regeln.

Wären Airport Addons um 5 Euro teurer, nur weil da Bodenanimation mit drin ist, würden sich zu Recht andere Käufer beschweren, deren Flug mit der Landung zuende ist und sie den „Schnick-Schnack“ nicht wollen.

Somit ist es gut wie es ist, wer komplexere Animationen möchte, kann diese hinzu kaufen, wer die nicht braucht, zahlt sie auch nicht.
Diese Trennung macht es auch möglich, dass Produkte durch AES unterstützt werden, die Aerosoft gar nicht im Programm oder unter Vertrag hat.

Ich möchte natürlich nicht ausschließen, dass es Entwickler gibt, die sich die komplexe und zeitaufwändige Anpassung der Jetwaymodelle an die buggy FSX Animation sparen, weil es AES gibt. Das muss man dann aber die Scenery Entwickler fragen, da bin ich nicht zuständig 🙂

simFlight: Mit der Einführung von GSX (Ground Services X) haben die Airport Enhancement Services Gesellschaft im gleichen Marktsegment bekommen. Welches Potenzial sehen Sie in der Koexistenz beider Produkte?

GSX und AES haben nur den Bereich der Bodendienst als Aufgabe gemeinsam. Im Ansatz sind sie aber grundverschieden. AES war nie darauf ausgelegt, auf allen Airports im FS zu funktionieren.

Wie schon bei den frühen Anfängen meiner Bremen Scenery, ist AES darauf ausgelegt, detailreiche Airport-Addons mit auf sie abgestimmte Zusatzfunktionen zu versorgen, die der Scenery Entwickler mit den ihm zu Verfügung stehenden Mitteln nicht umsetzen kann. Derzeit ist dies zum einen die Jetwayanimation für alle Arten von Jetwaytypen, auch solche, die nicht den Standardtypen entsprechen oder die doppelten und 380 Jetways. Zum anderen die Pushback Prozedur, nicht nur irgendwie auf den Taxiway schiebt, sondern so wie es der Lage und Situation der Parkposition im Original entspricht.
Für den AES Ansatz gab es ja noch viel weitergehende Ideen, die leider bisher mangels Zeit und Komplexität nicht umgesetzt werden konnten. So ist im Ansatz auch vorgesehen, den kompletten Vorfeldtraffic (das was heute noch AESLite ist) in AES integrieren zu könnten. Dies bedarf dann aber einer individuellen Erfassung, die über Vehicleroads im AFCAD deutlich hinaus gehen. Leider bei 500 Airports bereits schwierig.

So etwas kann ein global auf jedem Defaultairport funktionierendes Tool wie GSX nicht leisten, da ist der Ansatz nicht darauf ausgelegt.
Aber, deswegen existieren die beiden Tools auch gut nebeneinander, da wo AES nicht vorhanden, gibt es halt GSX.

simFlight: Herr Kok hat in Aerosoft Forum eine Andeutung gemacht die man so verstehen könnte, als würde es in naher Zukunft auch AES für PREPAR3D geben. Ist das richtig und wie sehen Sie PREPAR3D?

Ankündigungen gibt es viele bei Aerosoft, ich habe keine Infos über das, was Mathijs Koks dort vorstellt, mit AES hat es nichts zu tun.

Ungeachtet dessen bin ich derzeit dabei mit Maurizio Gavioli zu klären, welche Möglichkeiten wir haben, die Funktionalität von Intelliscene in P3D zu bringen.
Was einerseits klar ein Pluspunkt von P3D ist, nämlich die Weiterentwicklung, ist andererseits auch ein Problem, da die Integration in die Engine, so wie sie AES benötigt im derzeitigen Ansatz, problematisch ist. Es ist leider noch nicht klar, wie sich P3D in diesem Punkt weiterentwickelt.
Leider sind neuen Funktionen aber auch noch nicht so weit gediehen, um bereits alle Funktionalitäten zu liefern, die hier für einen neuen aber im Ergebnis gleichen Ansatz nötig wären. Hier ist es leider zu früh, verlässliche Aussagen machen zu können.

simFlight: Wie sehen die nächsten Meilensteine zur Weiterentwicklung von AES aus und auf was dürfen sich die Simmer am meisten freuen? Ist eine Umsetzung auch für X-Plane geplant?

Die X-Plane Frage ist einfach zu beantworten: Nein, derzeit nicht geplant. Die Entwicklung im Microsoft-basierten Simulator ist hinreichend, um mich voll auszulasten. Der FS2004 ist nicht so tot, wie ihn einige sehen wollen, der FSX kommt erst richtig in Fahrt und wird auch nicht morgen durch P3D ersetzt.
Und wenn Dovetail Games dann auch noch was aus dem Code von Microsoft zaubert, wird’s richtig unübersichtlich.

Bezüglich der Meilensteine für AES gibt es einige, manche sind auch schon recht weit gediehen, aber ich habe in den letzten Jahren gelernt, jede Aussage hierzu besser zu verweigern, denn kommt was dazwischen und man released das nicht binnen 4 Wochen, sind wir wieder bei der Frage, warum das so schleppend vorangeht 😉

simFlight: Würden Sie, rückblickend, nochmals ein Programm wie AES entwickeln?

Ich wäre bescheuert, wenn ich es nicht täte, lol.

Vielen Dank an Oliver Pabst für das Interview!

Peter Rosendahl