Nein, die bewegen sich garnicht.

@Ansgar: Es gibt AGNIS, aber keine beweglichen Jetways.

@Julio: Traffic*.bgl mit TTools dekompilieren, in einen Editor wie AITM etc. laden, die leg ICAO EDDM und Airline Lufthansa suchen und schauen, wie die Flüge nach EDDF angesetzt sind. Nach Belieben ändern, speichern und Traffic mit TTools neu kompilieren.

was um alles in der Welt ist AGNIS??

Die Andockhilfe bei EDDF ;-=)

AGNIS = automatisches Andock-Hilfesystem ;)

Nun ja... oben die Texte und Bilder zuvor waren nur zur Demonstration, dass der aktuelle Mega EDDF noch ein altes FS2000 AREA16N Flattenpolygon nutzt um den Boden waagerecht einzuebnen.

Weiterhin, dass dieses ARAE16N Flattenpoly sehr groß ist und weiterhin eigentlich dafür sorgt, dass ein Airport und dessen Bodenpolygone bzw. Bodentexturen dadurch unbeeinflussbar gegen Meshfiles werden sollen. (eigentlich....müsste man sagen, denn die Wirklichkeit ist nicht stabil)

Ich hatte auch gezeigt, was passiert, wenn man das AREA16 Flattenpolygon entfernt. Damit es besser rüber kam, habe ich zusätzlich ein Mesh mit zu niedriger Höhe unterlegt.

Wir konnten sehen Teile der Mega EDDF Scenery schweben. Auf der anderen Seite haben wir aber auch gesehen, dass im Mega EDDF Code existiert, der wenn er ungeschützt (ohne Flattenpoly) über einem Meshfile liegt das Terrain Gelände künstlich nach oben zieht.

Das brilliante folgt erst jetzt.

Denn wenn man diese Zusammenhänge nicht kennt, dann kann einen dieser folgende Bug zur Verzweiflung bringen, da er nicht als stabil bezeichnet werden kann. Es spielen andere Airport Addons als auch das Mesh an sich bzw. Einstellungen im FS eine Rolle.





Ich möchte mich nicht 100% festlegen (hatte das ganz am Anfang zu FS2004 Zeiten mal getestet, ist aber schon lange her), aber ich meine alle aktuellen FS2004 Boden Codes die wir z.B auch über AFCAD programmieren können, lösen diese künstliche Geländeverbindung zu einem Mesh definitiv nicht aus.


Es scheint also auch noch anderen nicht aktuellen Code in der Mega EDDF Scenery zu geben. (kann natürlich sein, dass es dennoch den ein oder anderen aktuellen Code mit diesem Phänomen gibt) Mir ist wie gesagt damals an den Default Airports aktueller FS2004 Technik nichts negatives aufgefallen.

Wie gesagt ich habe damals speziell beim FS2002 Runwaycode dieses Problem der Geländeverbindung ermitteln können. So kam es, dass es damals aufgrund eines weiteren Bugs im FS2002 hin und wieder sogar bei Default Airports im FS2002 zu flackernden Bodentexturen kam.


So weit so gut. Kommen wir zu dem Flackerproblem an sich und wie es entsteht.

Entscheident ist, dass man weis, dass im FS mit sehr vielen Texturen gearbeitet wird. Ob man eine Textur sieht oder nicht, hängt von der Programmierung und der Logik ab.

So können sich sehr viele Bodentexturen überlagern. Ein Taxiwaypolygon und dessen Texturen liegen z.B oben auf einem Rasenpolygon. In dem Bereich des Taxiwaypolygon sehen wir den Rasen dann nicht. Eine Taxiwaylinie liegt z.B wiederrum auf einer Vorfeldtextur usw.

Ein logisches gewünschtes optisches Verhalten.

Wir sehen es gibt hier eine Art logisches Schichtensystem (Layersystem)

Das gleiche gilt im Prinzip für Vorder und Hintergrund. Haben wir bei einer Scheune ein geschlossenes Scheunentor, dann ist dieses bei entsprechender Sicht im Vordergrund. Die Texturen die sich innerhalb der Scheune befinden interssieren uns dann nicht, sie sind im Hintergrund und müssen optisch nicht dargestellt werden.

Dieses ist übrigens die Information in der Z Ebene.

Im Prinzip was ist Vordergrund, was ist Hintergrund, was ist oben, was ist unten. Diese Entscheidung muss man der Graka mitteilen, insofern sie das aufgrund des Codes nicht selbst feststellen kann.

Immer wenn wir es mit Texturflackern zu tun haben, dann hat das mit Problemen in der Z Ebene zu tun. Es gibt in diesem Fall also ein Schichten oder Layerproblem.

Beim FS2002 hat zum Teil die fortlaufende sinnvolle Reihung bei der Programmierung ausgereicht um bei Bodenpolygonen gleichen Codes eine sinnvolle Schichtung zu erhalten.

Dieser identische Code im FS2004 macht schon mal Probleme. Erst durch eine feste Layervorgabe über Befehle bekommt man diverse Flacker Probleme in den Griff.

Aber wie gesagt, es hilft nicht immer eine sinnvolle Layerprogrammierung zu haben um Flackerprobleme zu beheben.

Auch die Information oben und unten ist für eine saubere Schichtendefinition z.B wichtig. Mit anderen Worten auf welche Höhe wird ein Bodenpolygon und dessen Textur definiert.

Liegt ein Polygon A um einen Meter höher als Polygon B, dann kann je nach Code hier allein die Höhe entscheident darüber sein, welches Polygon inkl. dessen Textur optisch gesehen werden kann.

Ein Polygon muss für ein Flugzeug übrigens keine feste Oberfläche darstellen. Bietet es hinsichtlich Code keine feste Oberfläche, dann würde ein Flugzeug wie durch eine Wolke durch dieses Polygon und dessen Textur hindurchsacken. So etwas finden wir dann in Form von einsackenden Fahrwerks Rädern usw. vor. Auch das Gegenteil schweben finden wir.



In der Regel hat man kein Flackern von Bodentexturen wenn diese einen gewissen Höhenabstand haben.
Im schlimmsten Fall sieht man aufgrund der jetzt logisch falschen Priorität (wegen falscher Höhendifferenz) nicht die gewünschte Textur. Zum flackern kommt es im Regelfall erst dann, wenn diese Polygone ganz dicht übereinander liegen oder aber wenn aus irgendwelchen Gründen sich ein schräger anderer Boden mit eigenen Texturen durch so ein flaches Bodenpolygon und dessen Textur durchdrückt.

Dieses sollte man wissen, denn alles das spielt hier beim Flackern von Texturen eine Rolle.

Behalten wir mal nur das Höhenproblem als Texturflackerverursacher im Hinterkopf.

Ich erwähnte, dass so ein AREA16N Flattenpolygon eine feste Unterfläche für solche Bodenpolygone schaffen soll.

Ich erwähnte auch, dass ich im FS2002 damals einen Prioritätsbug bei AREA16N Flattenpolygonen festgestellt habe. Dieser Bug wurde in den FS2004 leider ebenfalls eingeschleppt.

Das bedeutet existiert für ein ADDON wie Mega EDDF welcher ein altes FS2000 AREA16N Flattenpoly nutzt ein weiteres AREA16N Flattenpoly welches tiefer in der Scenerybibliothek angemeldet ist, dann geniesst dieses tiefere durch den Priobug leider unlogischer Weise die höhere Priorität.

Das andere störende AREA16N Flattenpoly kann in einem alten GAP2 EDDF Airport oder einem anderen ADDON enthalten sein.

Ganz dumm daran ist, dass man z.B einen alten tiefer liegenden GAP2 EDDF Airport excludieren kann (solche Excludes sind in den Addons immer enthalten, der alte Airport wird dann nicht geladen). Dieses gilt aber leider nicht für das alte AREA16N Flattenpoly. Flattenpolys kann man man nicht excludieren. Nur eine andere Verteilung also Anmeldung an anderer Stelle in der Scenerybibliothek wäre möglich.

Das bedeutet durch den Priobug bei AREA16N arbeitet Mega EDDF nicht mehr mit seinem eigenen AREA16N Flattenpoly sondern mit dem eines anderen Addons.

Liegt dieses auf anderer Höhe wie das Mega EDDF eigene, dann haben wir ein Höhenproblem. Die Höhe passt nicht zum übrigen Code von Mega EDDF. Diese Problematik gilt übrigens auch für Flatteneinträge die man in der Scenery.CFG machen kann.

Noch lustiger wird das übrigens wenn ein drittes Addon mit alten AREA16N Flattencode existiert.


Ok wir wissen jetzt, dass durch ein anderes EDDF Addon der aktuelle Mega EDDF mit falschen Höhenprofilen hinsichtlich Flatten arbeiten kann.

Das alleine muss noch nicht mal flackern auslösen. Ev. werden jetzt aufgund falscher Höhenprofile andere Texturen an die Oberfläche angehoben.

Dem Anwender fällt das ev. noch nicht mal auf. Erst Vergleichsscreenshots zu anderen Anwendern ohne diese Probleme würden zeigen, dass bei Ihnen Mega EDDF irgendwie hinsichtlich Texturen besser aussieht.



Unten im Anhang sehen wir die Auswirkungen dieses Prio Bugs im FS2004.

Die Mega EDDF Airport Scenery ist hier absolut unverändert. Sie liegt im Default Zustand wie sie geliefert wird vor.

Was ich gemacht habe, ist das ich eine zusätzliche Scenery angemeldet habe. Diese enthält ein LOD 10 Mesh auf -333 Meter welches nur dazu dient die Auswirkungen besser demonstrieren zu können.

Weiterhin enthält die Scenery quasi nur eine Art deckungsgleiche Kopie des Mega EDDF AREA16N Flattenpolygon. Dieses mal allerdings nicht auf der üblichen EDDF Höhe sondern wesentlich tiefer auf 0 Meter Höhe. (wären die Flattenpolys wie in diesem Fall nicht deckungsgleich könnte es weitere Problemstellen geben)

Meine Scenery die das Problem demonstrieren soll, wurde unterhalb von Mega EDDF angemeldet. Von der Logik her dürfte das dortige AREA16N Flattenpoly nicht stören, da es eine vermeintlich niedrigere Priorität geniesst.

Durch den Priobug sieht es leider anders aus.


Siehe Screenshot. Diesen am besten geöffnet lassen.

Wir sehen in diesem Screenshot auf der regulären EDDF Höhe schwebend in der Luft unsere AI Traffic Information. Diese AI Traffic Bezugsinformation wird in der Regel mit dem Tool AFCAD programmiert. Im FS2004 ist diese Information zusätzlich auch gleich sichtbares texturiertes Airportlayout also Taxiways, Taxiwaylinien usw. Diesen Informationen gibt man eigene Höheninformationen bei, deshalb schwebt die Information jetzt unabhängig von meinem tieferen Flattenpoly.

Aus diesem Grund legt man in der Regel optisch bessere Airport Fotosceneryinformation minimal über diese AFCAD Informationen.

Da diese AFCAD Information bei sinnvoller Programmierung immer waagerecht ausfällt, ist hier auch der Knackepunkt, dafür, dass es im FS2004 keine schrägen Airports und Runways gibt. Man kann jederzeit schräge Runways programmieren nur der AI Traffic spielt da nicht mit.

Ok wir sehen der AI Traffic und einige Bodenpolygone schweben in der Luft auf korrekter EDDF Höhe.

Dort oben sollte auch die Fotoscenery bzw. die anderen Objekte liegen. Tun sie aber nicht.

Dadurch, dass sich mein Area16N Flattenpoly aufgrund des Priobugs vordrängelt, werden diese auf mein Area16N Flatten Poly mit 0 Meter Höhe heruntergezogen (hängt auch davon ab wie Objektcode programmiert ist. Er kann eigene Höhen haben oder relative so das er sich auf eine Bezugsfläche absenkt).

Würden die Höhendifferenzen nicht so extrem wie hier ausfallen, dann würde man teilweise je nach Sichtperspektive nur unerwünschte Bodentexturen (AFCAD Layout) bzw. versunkene Objekte sehen.

Weiterhin sehen wir noch mein viel zu tief liegenden Meshboden auf -333Meter. Das ist da wo das gelände im Vordergrung so radikal auf -333 Meter abstürzt. Diese Kante die wir vorne sehen ist die Kante des AREA16N Flattenpoly


Diese Testscenery kann man hier inkl. Flugsituation runterladen, falls man mal das Chaos was im FS entstehen kann selbst nachvollziehen möchte.




Testscenery im Anhang

Wir sehen aber auch, dass es in diesem Fall keine Meshverbindung zu irgendwelchen Codes des Mega EDDF gibt. Es können zwar Höhendifferenzen existieren niemals aber schräge Geländeflanken. In diesem Fall haben wir ev. zwar Prioritätsfehler bei Bodenpolygonen und dessen Texturen aber nur sehr selten Flackerprobleme.

Dieses Bild oben zeigte den Zustand wenn man auf Mega EDDF startet. Dort wurden nur sehr selten Flackerprobleme geschildert.

Sehr oft hörte man von Flackerproblemen wenn man EDDF aus der Ferne anfliegt.

Simulieren wir das und behalten obiges Bild im Hinterkopf. Wir norden falls meine Flugsituation nicht genutzt wird unser Flugzeug mit Sicht auf Mega EDDF aus.

Wir merken uns die Nordkoordinate. Jetzt bewegen wir uns im Slewmodus mit maximaler Geschwindigkeit rückwärts fort. Ca. 300km, auf jeden Fall sollte Mega EDDF nicht mehr sichtbar sein. Wir pausieren den Flug hier. Die Scenery dürfte total verwaschen das Mesh optisch sehr schlecht sein. Wir warten bis sich die Scenery erholt hat. Wer keine Zeit hat, kann die Funktion im FS nutzen und die Scenery per Tastenkombination auffrischen lassen. So ersparen wir uns die Wartezeit.

Ist die Scenery neu aufgebaut fliegen wir im Slewmodus so schnell wie es geht an die gemerkte Koordinate bei EDDF. Wir pausieren hier den Flug und beobachten was genau passiert.

(Achtung auf selbe Flughöhe achten, durch Mesh beim Rückversetzen, kann ma absacken)

Wenn man Glück hat, kann man noch sehen, wie Teile von Mega EDDF wie zuvor schweben.

Aber irgendwann macht es Peng und im Gegensatz zu vorher haben wir diese künstliche Geländeverbindung von Airportcode zu meinem tiefer liegenden Mesh. Es entstehen schräge Gebirgsgeländeflanken.

Siehe das Bild im Anhang

War da nicht was?

Schräge Geländeflanken können Texturflackern auslösen wenn diese Flanken in eine andere Polygoninformation höhentechisch übergehen.

Genau das ist unser Mega EDDF Problem wenn wir den Airport anfliegen. Starten wir auf dem Airport haben wir das Flackerproblem nicht. Der problematische Code hat keine Wechselwirkung zum Mesh. Es gibt diese Geländeverbindung nicht. Fliegen wir ihn an, haben wir eine Wechselwirkung es tritt auf einmal eine schräge Geländeverbindung auf.

Was das ganze noch verrückter macht ist der LOD Level des Meshfiles welches der Anwender nutzt, weiterhin ev. der manipulierte TERRAIN_MAX_VERTEX_LEVEL in der FS9.CFG

Einige dürften wissen, dass manche Addons heimlich an diesem abgekürzt als TMVL bezeichnet herumspielen.

In der Regel haben wir natürlich nicht so krasse Höhenunterschiede wie bei meiner Demo.

Real haben wir hin und wieder nur wenige Zentimeter die solches Flackern auslösen. Das ganze schwankend von LOD Level des Mesh, TMVL, Sichtposition des Anwenders.

Das ganze weiterhin abhängig wo man den FS Flug aufgesetzt hat.



Die wesentliche Frage die sich stellt, warum hat man denn einmal die Geländeverbindung und einmal nicht.

Dazu muss man genauere Kenntnisse der undokumentierten Terrain Engine haben. Die habe ich mir durch Tests erworben (siehe irgendwann Dok).

Die Grundprinzipien sind aber in der Szene die sich damit befasst bekannt. Auch diese Simulation oben hat die Vorgänge schon aufgezeigt.

Man konnte sehen, dass sich unser 3D Gelände dynamisch aufbaut. Legt man urplötzlich im Slewmodus eine weite Strecke zurück und pausiert den Flug dann kann man diese Dynamik sehen.


Das Gelände hat zunächst eine sehr schlechte Auflösung wird dann aber langsam detailierter.

Diesen Aufbau muss man sich vereinfacht vorstellen wie ein neues Laden von Meshinformationen.

Genau das ist hier der entscheidende Punkt bei diesem Bug.


Es gibt beim FS ein logisches Prioritätsverhalten beim Laden unterschiedlicher Sceneryelemente.

Startet man den FS auf einem Airport, dann hat der FS genügend Zeit unter dem Flugzeug sein Mesh im höchsten Detaillevel aufzubauen, bevor man einen Flug beginnen kann.

Hat der FS sein Mesh aufgebaut, wertet er hinsichtlich Priorität erst sehr viel später die AREA16N Flattenpolygonhöhe aus.

Es kommt nicht zu dem Problem.

Was passiert im Anflug auf EDDF.


Der Airport ist sehr weit weg. Unter dem Airport hat das Mesh einen sehr niedrigen Detailgrad. Irgendwann wird der Airport sichtbar das AREA16N Flattenpoly wird geladen und gibt seine Höhe als Bezugshöhe vor. Die AREA16N Information wurde korrekt abgearbeitet. Bis hierhin ist alles noch OK.

Während des Anflugs baut sich das Mesh dynamisch detailierter auf. Das bedeutet wir bekommen nach dem Laden des AREA16N Flattenpoly neue Meshinformation dazu. Das bedeutet kritischer Code ist nicht mehr durch das zuvor geladene bereits abgearbeitete AREA16N Flattenpoly geschützt. Es kommt durch die Meshdynamik zur künstlichen 3D Geländeverbindung. Es flackert.

Das Hauptproblem ist, dass die alten AREA16N Flattenpolys keine Mesh verwandte Technik sind.

Mit dem neueren FS2002 LWM2 Flatten bzw. dem FS2004 Flatten gibt es diese Wechselwirkung nicht.


Von daher sollte man eigentlich nur noch LWM Flattentechik nutzen.

Aber wäre das 100% sicher?

Theoretisch Ja, da es die Wechselwirkung nicht gibt.

Praktisch Nein, da vermutlich aufgrund Abwärts Kompatibilität AREA16N eine höhere Priorität gegenüber anderen aktuellen Flattentechniken im FS2002 / FS2004 geniesst.

Wäre das nicht der Fall würden alte FS Addons im FS nicht einwandfrei funktionieren.

Dumm wie gesagt, dass diese Probleme durch andere Addons mit AREA16N Flatten ausgelöst werden können.

Was hilft bei diesem Problem.

Im Prinzip nur alte störende AREA16N Flattenpolys bzw. Flatteneinträge in der Scenery.cfg zu deaktivieren.

Aber wie findet man andere AREA16N Flattenpolys?

Wurde bei Addon Erstellung das Designtool SCC genutzt findet man immer den Buchstabencode _DEM im Namen der BGL Datei (insofern die Files vom Produzenten nicht umbenannt wurden)

Man kann also diese Files oftmals mit dem Windows Explorer suchen lassen.

Wie das alte Designtool Airport seine AREA16N Flattenfiles nannte weis ich nicht.

Daher habe ich in meine Dok eine Möglichkeit eingebaut wie man nach AREA16N Code unabhängig vom Namen fahnden kann.

Es kann allerdings auch mal ganz dumm ausgehen wie damals bei der ATP2002. Hier gab es auch so einen Störfall in Verbindung zur AA2002. Hier gab es das Problem bei LOWS.

Dumm war es, weil bei der ATP2002 alle AREA16N Flattenpolys der Airports in einem File untergebracht waren. Ein deaktivieren des Files hätte Störungen bei anderen Airports verursacht.

Alternativ könnte man bei Mega EDDF auf anderen Code ausweichen der nicht auf Mesh reagiert.

Da müsste man aber zunächst mal testen ob es aktuellen Code gibt der die vom GAP Team gewünschten Belange unterstützt. Das müsste man prüfen.

In jedem Fall sollte man als Anwender andere EDDF Addons notfalls die BGLs zunächst ganz deaktivieren, weiterhin in der Scenery.CFG kontrollieren ob es dort einen separaten Flattenbefehl für EDDF gibt.

Das dürfte einige potentielle Probleme beseitigen. Es kann wie gesagt weitere Problemauslöser geben.

Was Stefan nun für ein Problem hat dazu möchte ich mich zunächst nicht äußern, da nicht klar ist ob er nun ein Texturflacker oder Texturflimmerproblem hat.

Das wäre im Vorfeld zu klären.