Bewertungskriterien und Tipps für gute Szenerien

Dieser Beitrag richtet sich an Entwickler von Szenerien für X-Plane. Es gibt einige kleine Kriterien, welche man unbedingt beachten sollte, wenn man eine Szenerie für X-Plane gestaltet.

Mir ist es durchaus bewusst, dass eine Szenerie unheimlich viel Arbeit ist und das es tausende Sachen gibt, welche schief laufen können. Jedoch gibt es insbesondere auf technischer Ebene einige Kniffe, welche beachtet werden sollten insbesondere dann, wenn auf Libraries zurück gegriffen wird.

Viele verschiedene Libraries

Wie aus meinen Reviews eigentlich klar sein müsste bin ich ein Gegner von der Verwendung von vielen verschiedenen Libraries. Eigentlich sollte bei der Gestaltung von Szenerien nur zwei Libraries verwendet werden:

  1. Die interne Libray von X-Plane: Hier können auch gerne X-Plane 10 Elemente verwendet werden. So weh es mir im Herzen tut, X-Plane 9 ist leider zum Auslaufmodell geworden. Insbesondere bei X-Plane 10 werden mit jedem Update weitere Objekte hinzugefügt. Insbesondere auch innerhalb von Beta-Versionen gibt es neue Objekte. Als vernünftiger Entwickler sollte man diese Objekte nicht verwenden, weil man dann den Anwender dazu zwingt eine nicht stabile Version von X-Plane zu verwenden. Als Maß sollten nur Objekte der letzten stabilen Version verwendet werden.
  2. OpensceneryX: Da diese durch die X-Plane Community und nicht nur durch einzelne Entwickler gepflegt wird und weil ein Update über den Installer sehr einfach ist, kann OpenscenerX verwendet werden. Wenn OpensceneryX verwendet wird, dann ist unbedingt das OpenSceneryX Developer Pack mit einzubeziehen! Denn nur so werden harte Fehler ausgeschlossen.

Es ist definitiv möglich allein mit diesen beiden Quellen gute Ergebnisse zu erzielen. Alle weiteren Libraries sind deshalb unnötig. Bei der Verwendung von R2_ RU_ oder FF_ Library sind die Objekte zum Teil fehlerhaft. Außerdem wurden diese von einzelnen Entwicklern für deren Szenerien erstellt und man kann sich auch nicht zu 100% sicher sein, ob ein Support oder auch eine Verfügbarkeit in Zukunft gewährleistet ist.

Außerdem wird es für den Einsteiger sehr schwer sich die fehlenden Libraries von den verschiedenen Webseiten zu besorgen. Denkt immer daran, ihr steckt so viel Arbeit und so viel Mühe und Liebe in Euren Flugplatz / Flughafen, dann sollen diesen auch so viele Leute wie möglich nutzen können. Denkt auch an die Personen, welche Eure Szenerie nutzen wollen. Es ist sehr frustrierend, wenn ich plötzlich noch ff_library und meine X-Plane Version auf Beta updaten und noch ru_library von einer russischen Webseite herunterladen muss. Der normale Anwender möchte nur die Szenerie herunterladen, entpacken und in den scenery-Ordner schieben.

Placeholder und library.txt

Wenn Objekte von fremden Libraries doch eingebunden wurden, dann muss es innerhalb des Packets auf erster Ebene eine Datei mit dem Namen library.txt geben. In dieser Datei müssen für jedes verwendete Objekt aus einer Library ein EXPORT_BACKUP Eintrag vorhanden sein, welcher auf einen leeren Platzhalter verweist. Wenn X-Plane das Objekt nicht findet oder nicht lesen kann, wird anstatt dem Library Objekt das Platzhalter Objekt dargestellt. Für den Benutzer bedeutet das, dass es nicht zu einem Systemcrash mit hartem Fehler kommt, sondern nur dass dieses Objekt nicht dargestellt wird.

Ein gutes Beispiel dafür ist das OpenSceneryX Developer Pack. Wenn ihr nur OpensceneryX und X-Plane Libraries verwendet, reicht es auch das Developer Pack einfach der eigenen Szenerie hinzuzufügen.

Verwendung von X-Publish

Auf der Webseite von Marginal lässt sich das kleine aber feine Tool X-Publish herunterladen. Dieses Tool hilft es Szenerien zu veröffentlichen. Es analysiert die Szenerie von technischer Seite her und erzeugt eine html Seite als kleinen Report. Zusätzlich packt es alle Dateien in eine ZIP Datei. Besonders Hilfreich ist dabei der Report, da hier noch einmal alle Elemente im Paket dargestellt werden. Dabei werden Library Objekte ohne Platzhalter oder auch verweiste Dateien gesondert dargestellt. Allein aus dieser Sicht würde ich empfehlen, dieses Tool unbedingt zu verwenden.

Exclusions

Besonders in Zeiten der automatisch generierten Objekte unter Verwendung von Openstreetmap Daten sind Exclusions wichtiger denn je. Nicht ist nerviger, als wenn plötzlich die ganzen Gebäude eines Flugplatzes durch große Lagerhallen überdeckt werden. Oder wenn mitten auf dem Taxiway eine Straße verläuft. Das schlimme daran ist, dass es an den anderen Szenerien liegt. D.h. bei einem selber kann noch alles super aussehen und bei einem anderen User ist der Platz gar nicht mehr benutzbar. Der Grund dafür liegt in den Openstreetmap Daten. Denn dort sind auch alle Gebäude und Hallen der Flugplätze erfasst. Wenn wir jetzt eine Szenerie für ganz Deutschland mit diesen Daten erzeugen, werden die Gebäude auch bei allen Flugplätzen erzeugt. Das führt meistens zu eher unschönen Ergebnissen. Deshalb ist es um so wichtiger, dass Exclusions gesetzt werden. Diese Exclusions steuern dann, dass keine Objekte von zuvor erzeugten Add-Ons dargestellt werden.

Wichtige Exclusions sind dabei:

  • fac Facades: Ausschluss von .fac Files, da die Objekte von OSM2XP als .fac Objekte erzeugt werden.
  • for Forests:  for-Files definieren Wälder.  Sehr wichtig, da sonst Bäume auf der Runway stehen können.
  • obj Objects: obj Dateien sind die „normalen“ Objekte. Eine Exclusion über den kompletten Platz ist definitiv empfohlen.
  • Roads: Undebdingt notwendig, da Taxiway in OSM oft fälschlicherweise als Straßen erfasst wurden.

Kommentar verfassen