|
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 ;)
|
Zitat:
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. |
Ich habe in Fly Tampa Dubai habe ich in der Aussenansicht mit der geilen PMDG 747-400 um die 15-25 Frames.Mit 100 % Traffic usw. alle Regler rechts.
Werde ich in Fra zirka auch soviele haben??? |
Altes vs neues
Hi Leute !
Ich hab den Mega Airport gewonnen. (Ob der auf meiner Gurke läuft ist erst mal ein anderes Problem :rolleyes: ) Meine Frage wäre, wie läuft das mit dem alten EDDF von GAP, hab GAP 1-4 installiert, kann/muss man die Szenerie von Frankfurt irgendwie deaktivieren oder muss ich das ganze Produkt deinstallieren... ? Hmm, hab wirklich keinen Schimmer...:confused: |
Re: Altes vs neues
Zitat:
Bernd |
Na super ! Danke fur deine Antwort ! :-)
|
Hallo zusammen,
möchte den Thread aus nachfolgendem Grund gern nochmal vorholen: Ich habe kürzlich den Treiber für meine ATI 9800Pro von Version 5.4 auf 6.1 aktualisert. Seit dem plagen mich in der Mega EDDF-Szenerie Probleme mit "explodierenden" Polygonen, die sich aber nicht unbedingt mit den hier beschriebenen Texturflimmereien beschreiben lassen: http://www.viprip.de/pic_div/eddf_ati.jpg Ich habe alle Treiberversionen bis zur 5.6 ausprobiert und z.T. Komplett-Abstürze des Flusis in EDDF erlebt. Die erst kürzlich erschienene 6.2 läuft nun soweit stabil, aber das Problem ist weiterhin vorhanden, auch wenn es nur noch bei bestimmten Sicht-Blickwinkeln - und wenn der Horizont ebenfalls im Blickfeld ist - auftritt. Eine ältere GAP2-Version hatte ich im FS04 bislang nicht drauf; Alternativ-AFCAD-Files für Frankfurt sind allesamt deaktiviert. Ich möchte eigentlich ungern wieder auf eine niedrigere Treiberversion zurück, da ich mit den Versionen ab 5.7 bei bestimmten Fliegern endlich auch Gauges im Fenster auf einen zweiten Bildschirm auslagern kann, ohne dass es hierbei zu Problemen kommt (Mausflackern, etc.). Weiß jemand, womit dies nun zusammenhängt und wie man es ggf. beseitigen kann? Wohlgemerkt, bis zur Treiberversion 5.4 hatte ich in EDDF keine Probleme. |
AFCAD und AF2-Dateien haben damit absolut nichts zu tun.
Es ist leider das Zusammenspiel zwischen Hardware (Board und GraKa), Treiber-Settings, Operating System und FS Settings, z.B. in der FS9.cfg. Ein neuerer Treiber ist (wie inzwischen leider mehrfach bewiesen) längst nicht mehr die Lösung von Problemen, sondern sehr häufig eher Ursache für Verschlechterungen. ATI und NVidia stehen sich hier übrigens um nichts nach, falls es Dich beruhigt. Du kannst nur verschiedene Kombinationen von Einstellungen probieren, um wenigstens einen Kompromiss zu finden und Dich parallel dazu an ATI wenden. Vielleicht ist es denen wichtig genug. Bei NVidia hat's jedenfalls schon mal geholfen. Sorry :( |
Hallo Dieter,
vielen Dank für Deinen Hinweis. Das ist ja wenigstens ein (ehrliches) Statement. So brauche ich ja hier nicht weiter zu verzweifeln, sondern kann mir überlegen, eventuell doch wieder auf den 5.6 zurückzukehren, weil ich auch nicht mehr weiß, was ich hier noch alles einstellen soll. |
Zitat:
da sind wir ja Leidensgenossen. Genau diesen Effekt habe ich auch und inzwischen ebenfalls erfolglose Versuche mit verschiedenen Treiberversionen gemacht. Dann stieß ich auf einen Artikel, der dieses Problem genau beschreibt im Zusammenhang mit zu hohen Temperaturen der Grafikkarte. Darauf hin habe ich die Temperatur der GK mal untersucht. Ergebnis: Der Effekt tritt in der Tat auf bei hoher Belastung der Grafikkarte, bei mir im Betrieb mit zwei Bildschirmen. Die Temperatur steigt dann von 48 °C im Normalbetrieb auf ca. 66 °C im ´strengen´ Flusibetrieb. Vielleicht ist das auch Dein Problem und tritt jetzt mehr zufällig nach Installation von EDDF auf. Prüf einfach mal die Temperatur der GK. Ich habe mir einen anderen Lüfter für die GK bestellt, der eine größere Luftmenge direkt aus dem Gehäuse bläst. Installation wahrscheinlich noch heute. Schaun mer mal. |
Hallo Wolfgang,
anfangs ging meine Vermutung auch in diese Richtung, zumal ich seit wenigen Wochen ebenfalls im Zwei-Monitor-Betrieb arbeite. So recht glauben wollte ich daran halt nur nicht, weil es ja mit den älteren Treiberversionen bis Version 5.6 ohne Probleme funktioniert hat und die danach auftretenden Erscheinungen alle plötzlich den gleichen Charakter aufwiesen. Anscheinend muss die Last in EDDF höher sein, als ich bislang angenommen habe. Blöde Frage meinerseits: welches Tool verrät mir jetzt besten die Temperatur der GraKa? Das CCC sagt ja darüber nichts. |
Moin Chris,
ich hab im Gegensatz zu Dir eine NVIDIA, und da gibt es die Temperaturanzeige im Menü für die Treibereinstellungen. Bei der ATI kenn ich mich nicht aus, aber ich könnte mir vorstellen, dass es dort ähnlich ist. Google mal, schau in die Suchfunktion oder öffne einen neuen Thread zu dem Thema, weil das hier nicht unbedingt passt. Würde mich auch mal interessieren. |
Ich hatte selbige Probleme. Daraufhin u. um den schnellsten ATI-Treiber (für mein System) zu ermitteln, hatte ich damals alle Versionen von 5.1 bis 5.8 systematisch getestet.
Der klare Sieger war der catalyst-5.1 :-). Inzwischen hab ich alle neueren bis zum 6.2 installiert. Auch neuere Omegas hab ich ausprobiert. Der schnellste ist und bleibt der 5.1. Fehler produziert er auch keine bei meinem Setup. Ich kann diesen "alten" (naja von Anfang 2005) Treiber für den FS 9.1 nur empfehlen. |
;) Jaja, eine neuere Version der Treiber ist schon lange nicht mehr gleich zu setzen mit besser oder schneller oder stabiler.
|
AFCAD für Aerosoft EDDF (Frankfurt) mit Crossing Runway
Hallo Zusammen
Wer kennt sich mit AFCAD und Crossing Runaways aus? Weil ich mich genervt hatte dass kein AI Traffic auf der 18/36 ist und dazu noch jede Menge Lufthansa Flieger sich dem Terminal D/E gedockt haben, habe ich das AFCAD fuer Aerosoft für Frankfurt mit Crossing Runaways versehen mit dem Erfolg dass wirklich jeder Flieger auf der Startbahn 18 abgeht. Nun habe ich aber das Problem, egal woher der Wind kommt dass alle ankommenden Flieger nur aus Richtung Osten anfliegen parallel auf der 25R und/oder 25L und vereinzelt ganz selten meint einer noch immer er müsse auf der 18/36 landen. Aber warum landen die Flieger nicht mehr aus Richtung Westen her kommend? Dies ist am AFCAD noch der einzige kleine Schönheitsfehler. http://www.aitraffic.ch/af2_eddf_gap-team.zip Hier noch ein paar Screenshots dazu http://www.aitraffic.ch/screenshots/eddf/1.jpg (Terminal E) http://www.aitraffic.ch/screenshots/eddf/2.jpg (Terminal B/C) http://www.aitraffic.ch/screenshots/eddf/3.jpg (Terminal A) http://www.aitraffic.ch/screenshots/eddf/4.jpg (Richtung Starbahn 18 West) http://www.aitraffic.ch/screenshots/eddf/5.jpg (Starbahn 18 West) http://www.aitraffic.ch/screenshots/eddf/6.jpg (Parallel Landing von Condor + Lufthansa) |
Hallo,
Zitat:
Deine neue Zuteilung der Parkpositionen sieht genial aus. Mich stört es auch, dass am Terminal 2 fast nur Lufthansa Flugzeuge stehen. |
Zitat:
Und zum LH-Traffic: Das tritt immer und völlig logisch und konsequent auf, wenn man seinen AI-Traffic (insgesamt bzw. für LH) auf 100% regelt. AI-Flugpläne sind nicht wirklich völlig real, weil sich keine Airline an die Rahmenbedingungn des FS hält - warum auch ;). Wer also nicht maximal Wochenzyklen fliegt, dessen Flüge müssen irgendwie anders in den FS gebracht werden. Was zu mehr führt, als tatsächlich vorhanden. Wir haben in EDDF darauf verzichtet, feste Zuordnungen zu machen, weil es sich sonst nicht vermeiden lässt, dass kleine Commuter (Bombardiers, ATRs etc.) an den Jumbo-Gates parken. Stichwort Air France oder British Airways. Ach ja, und außerdem muss man dem FS natürlich seine halbe Stunde geben, damit sich der AI-Traffic normalisiert. Danach sind (je nach Uhrzeit) viele der LH-Maschinen weg und es sieht "realer" aus. |
Zitat:
|
Einseitig sperren funktioniert mit AFCAD nicht zuverlässig. Solltest Du wissen...
Logisch kann man eine Bahn für Landung sperren, aber für Takeoff erlauben. Ich habe nichts anderes gesagt! Allerdings geht das nur beidseitig, aber nicht einseitig. Aber wenn Du eine funktionierende Version hast, die EDDF halbwegs real abbildet, also mit teilweise Start-Traffic auf der 18 aber ohne Landungen, sowie Start und Landung parallel dazu auch auf 07/25 und zwar L/R - dann bin ich der Erste, der HURRA jubelt und Dich in den Himmel lobt ;). Nur möchte ich diese AFCAD gerne mal sehen. Bisher haben sich alle Varianten immer als entweder so oder so entpuppt. Und ich habe mich mit EDDF jetzt seit 2 1/2 Jahren beschäftigt und alle Techniken und Varianten ausprobiert. Also her damit, zeig was Du kannst, überzeuge uns davon, dass ich falsch liege und "Blödsinn" erzähle... Ich gebe jeden Fehler gerne offen zu. |
Nu den hanky panky siehe dir mal mein afcad an
http://www.aitraffic.ch/af2_eddf_gap-team.zip alle flugzeuge starten sauber auf der 18 und landen parallel dazu auf der 25r und 25l. ich habe mich ebenfalls stundenlang mit dem afcad fuer eddf von aerosoft beschaeftigt. war ja voll muehsam wie die immer warten mussten auf der 07 bis wieder einer landet. und die startbahn 18west liegt brach. darum habe ich das afcad von eddf voll neu erstellt. eine mordsarbeit. nun aber eben moechte ich von einem der crossing runways versteht wissen warum diese nicht auf der 07 landen... ok vereinzelt landet mal einer auf der 18 oder versucht es jedenfalls. aber das bekomme ich auch noch hin.... |
Was noch in Frankfurt interessant ist wie die Gatebelegungen sind. Im AFCAD von Aerosoft liegen die irgendwo.
Auf meinem AFCAD habe ich zwei Wochen lang die realen Flugpläne von der Seite http://www.airportcity-frankfurt.de/...e_abfluege.htm in mein AFCAD übertragen. Auch musste ich die DLH 747 Gates teils anpassen am Terminal A weil die nicht freigegeben waren. Wenn jemand eine Liste hat von allen 110 Airlines die in Frankfurt landen mit den jeweiligen Gate Belegungen dann bitte her damit. Es gibt noch viel Arbeit. Wo steht z.b. Royal Jordanian? Das habe ich noch nicht rausbekommen. |
Ich habe deine mal getestet.Es landen Flugzeuge auf den beiden parallelen Bahnen.ABER kein Flugzeug startet mehr.Ich werd deine A. Datei wieder entfernen müssen...
|
Hallo Flieg
Das finde ich ja komisch. Wo stehen die Flugzeuge denn weil diese nicht starten? Bei mir taxeln sie so schoen zur Startbahn 18. Kann das noch jemand anders mal testen, ob diese auch nicht starten? Würde mich echt interessieren wie es bei euch ist. Ich habe das ganze auf zwei PCs installiert und es funktioniert bestens dass die Flieger auf der 18 abheben und auf der 25r und 25l gleichzeitig landen. |
Es lösen sich mnache Flieger dann wie von Geisterhand auf...manchmal die landenden,manchmal die an den Gates.
|
Zitat:
Die habe ich nämlich schon wieder gelöscht. EDIT: Ein Blick ins ZIP und auf das Datum und ich habe alles wieder gelöscht, was ich eben geschrieben habe. Die AFCAD hat Dir sicher viel Arbeit gemacht, aber sie ist untauglich. Cargo parkt an Gate, Pax geht auf Cargo, kleine Airbusse, Boeings und CRJ belegen Jumbo-Pätze. Der komplette Start-Traffic wandert zur 18, auf 7/25 wird nur noch gelandet. Und noch landende Maschinen auf der 18, die 36 wird als aktive Startbahn zugewiesen. Nee danke. Mir ist es lieber, wenn Cargo bei Cargo bleibt, Pax bei Pax, Commuter auf die kleinen Plätze gehen, und die Jetways von den Großen genutzt werden. Ob ne Cathay nun an 7 andockt, weil 8 durch Verspätung noch belegt ist, entspricht mehr der Realität als in Deinem AFCAD-Approach. Wem's gefällt - bitte, kann sich jeder so installieren, das ist persönliche Freiheit. Aber es hat nichts mit dem Großflughafen EDDF und wenigstens ansatzweiser Realität zu tun. Die Frage bzw. Aufforderung war und ist ganz klar: Ein EDDF mit ausschließlich Start-betrieb auf der 18, aber keine Landungen und 36 komplett zu für beides. Und gleichzeitig dazu Landung und Start auf 7/25 parallel - so wie es in Frankfurt abläuft. Starttraffic auf die 18 umzuleiten ist banal und keine Besonderheit. Und Parkingassignments zu setzen lediglich Fleissarbeit. Aber dabei die "Kleinen" sicher und verläßlich auf's Vorfeld zu bekommen, die Großen an die Jetways, Cargo nach Cargo - darin liegt die Gesellenaufgabe. Und dazu noch die 18 zu aktivieren. Und auch noch kompatibel zu sein zu jeder Art AI-Traffic (Payware und Freeware)... Naja, den Versuch war's wert ;) Hätte ja sein können, dass Du einen Ansatz gefunden hättest, intelligente AFCAD Techniken auf eine Art miteinander zu verbinden, auf die sonst noch keiner gekommen ist. Aber wer die crossing Technik auf EDDF anwenden will, hat nicht mal den crossing Ansatz richtig verstanden - Nichts für ungut ;), ich schätze Deine Arbeit durchaus, aber etwas neues ist nicht darin zu finden und auch keine "Verbesserung", sorry. |
Naja ich habe nie behauptet dass ich alles weiss. Und eben ich habe das afcad file als download angeboten, damit mir jemand helfen kann der sich mit crossing runways auskennt, da ich ja zuvor geschrieben habe, dass einiges noch nicht funktioniert.
aber meiner meinung nach ist es alleweil besser als das Original AFCAD von Aerosoft. Ein AFCAD wie du es suchst, wird es wohl erst im FS2006 geben...wenn ueberhaupt. Aber ich bin für jede Anregung dankbar und auch Kritik ist ok. In dem Sinn machen wir weiter... Schöne Ostern |
Hi,
ich habe das Problem mit dem Patch, der das Flimmern beseitigen soll. In der Hauptsache ist es das Objektflimmern. Mein Problem ist, dass der Patch nicht installiert werden kann, es kommt die Meldung: Es soll die Originalinstallation verwendet werden. Kann mir wer bitte diesbez. einen Rat geben? Installiert auf E:\FS9 Aerosoft |
Moin Helmut,
Du meinst sicher das Service Pack 1 von Aerosoft. Ich hab es gerade installiert nach NeuAufsetzen des Flusi. Ging einwandfrei. Der Pfad von EDDF (bei mir N:/FS9/Aerosoft/EDDF_2005) wird automatisch erkannt. |
An den Ecken des Luftbilds sind keine Bäume,und keine Häuser.Ich werde diese mit EZ-Szenery machen und dann hier rein stellen.
|
Zitat:
Du kannst mit einer AFCAD nicht die fest in DLL's codierten Grundregeln "Kürzeste Distanz" und "Windrichtung" aushebeln, das geht nicht. Und Du kannst mit AFCAD nur beide Enden einer Runway entweder öffnen oder schließen, aber nicht einseitig. Wenn Du Anregungen oder Tipps möchtest, hier sind Zwei: - Erweitere Deine AFCAD um "plumbing" für einzelne Parkpositionen - Editiere die AF2 manuell in XML, wenn Du mit AFCAD fertig bist und kompiliere sie anschlließend mit BLGCOMP. Die Kombination aus crossing und plumbing könnte ein realistischeres Bild von EDDF bringen, kostet aber einen Riesenhaufen Arbeit. Deswegen habe ich es bisher nicht versucht. Viel Erfolg und Dir auch schöne Ostern!!! |
Vielen Dank, Wolfgang, dass Du mir wieder aus der Patsche geholfen hast. Jetzt funktioniert es:-) .
Ich wünsche Dir noch ein sehr schönes Osterfest! |
Hallo,
ich habe das gleiche Problem, das Service Pack 1 erkennt den Pfad nicht, wo Frankfurt installiert ist und es gibt auch keine Möglichkeit,ihn manuel einzustellen. Was kann man da tun? Gruß Steffmann |
| Alle Zeitangaben in WEZ +2. Es ist jetzt 01:33 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag