Hallo zusammen,
an Horst:
Zitat:
Und die Änderung in deiner „Ausführung“ (Uferlinie (selbe Breite und Textur) und ein paar Wasserklassen) hat mich für Österreich knapp eine Stunde gekostet. Auch bei Flüssen mag ich Uferlinien
Also sicher auch für Flugwerk kein Problem dies darzustellen!
|
Na, wenn das "kein Problem" ist, warum werden die dann nicht mitgeliefert? Oder willst du damit sagen, dass das jeder User, so wie du, bei Bedarf Uferlinien und Wasserklassen in "knapp einer Stunde" selbst einbauen sollte?
Mein Beitrag war auch nicht als Belehrung gemeint, sondern als Wunsch eines potentiellen Users, der es schade findet, dass wichtige optische Elemente der Gewaesser "ausgeklammert" werden. Realismus ist fuer mich persoenlich eben mehr als nur akkurate Positionierung.
Sorry, deine Aussagen ueber UT kann ich auch nicht nachvollziehen. Nochmals: es geht nicht darum, was hier bereits theoretisch durchdiskutiert wurde, sondern was letztlich auf dem Markt erscheint. Reden koennen wir alle halt viel
UT und Flugwerk benutzen, soweit ich weiss, dieselben NavTeq/GDT/TeleAtlas Grunddaten, daher werden die Basiselemente wohl sehr aehnlich sein. Ich habe UT auch nur erwaehnt, weil die eben die Gewaesser und andere Aspekte der Landschaft offenbar kompletter darstellen werden, als das bei Flugwerk AROE der Fall ist. War aber nur ein Hinweis, denn ich habe ja selber auch weder AROE noch UT Europe gesehen. Und von AP habe ich sowieso nicht gesprochen
------
Zum Thema Konventionen:
Ich denke, dass in vieler Hinsicht diese Diskussion fruchtlos ist, denn in der Praxis gibt es halt immer andere Prioritaeten und Sachzwaenge, die eine Einhaltung von Konventionen verhindern wird. Daher appelliere ich mehr an die einzelnen Produktionsteams, zumindest die Stolpersteine durch "Open Book" Projektdesign und Dokumentation so klein wie moeglich zu klopfen und, wo immer praktikabel, sich auch ueber die eigenen Firmengrenzen hinaus ueber Kompatibilitaeten zu verstaendigen.
Zu Michaels Meta-Daten Idee: gefaellt mir auch sehr gut, ist aber wohl wirklich nur durchsetzbar, wenn das direkt vom MS Designteam vorgesehen wuerde, z.B. in der Form von SDK Tools.
Uebrigens hat Jim Keir bereits vor ein paar Monaten mal ein kleines Tool erstellt - bglpatch, siehe
http://forums.avsim.net/dcboard.php?...ng_type=search - das direkt beim User LOD8 Zellen aus Defaultfiles "herausstanzt" und, bei Deinstallation des Add-ons, wieder mit Defaultdaten fuellt. Also ein aehnlicher Ansatz, wie es das JABBgl Tool mit den FL9*.bgl Default-Flugplatzflattens macht.
Das Problem mit solchen Tools besteht aber darin, dass sie, theoretisch zumindest, das FS EULA verletzen. Ich verteile zwar auch selber munter gepatchte Defaultdateien, trage aber damit selber das "Risiko", anstatt es dem Tooldesigner aufzubuerden. Daher mein Gedanke der Implementierung via SDK Tools. Angeblich haben die FS Macher ja angekuendigt, dass fuer die naechste Version die SDKs bereits vorab zur Verfuegung gestellt werden, aber das glaube ich erst, wenn ich es sehe
Ciao, Holger