Doppelte AFCAD-Einträge (Landeprozeduren) durch MyTraffic, VFRG, GAF, GAP

[BB-17 1]

Hallo alle zusammen,

mir ist vor kurzem aufgefallen, dass ich bei den Flugplätzen von GAF1/2 und GAP2 im FSX doppelte Einträge bei den im GPS angebotenen Landeprozeduren habe (jede Prozedur ist exakt zweimal aufgeführt). Dies kann ich definitiv von EDXW und EDDG sagen, da habe ich das heute nochmal überprüft, ich meine aber, dass ich das schon bei anderen dieser Flugplätze auch gesehen habe.

Ich habe MyTraffic X, VFR Germany 1+2, German Airfields 1+2 und auch German Airports 2 X installiert und habe vermutet, das da irgendeine von den AFCAD-Dateien doppelt ist.

Und tatsächlich (Beispiel EDDG):

Unter Aerosoft\AFD\Scenery gibt es die Datei AF2_eddg.bgl und außerdem die Datei BR2_EDDG.off (die also unwirksam ist).

Aber unter MyTraffic\scenery gibt es nochmal die Datei BR2_EDDG.BGL.

Beide enthalten offenbar Daten über die Landeprozeduren, denn wenn ich die Datei unter MyTraffic\scenery in *.off umbenenne, dann sind die doppelten Landeprozedur-Einträge weg. Alle sind dann brav nur noch einmal vorhanden...

Nun meine Frage: It's a bug or it's a feature? Oder hat da mal wieder irgendein Installer was vermasselt?

Überhaupt verstehe ich das ganze Konzept nicht so ganz: Die BR2_xxx-Dateien sind doch die MyTraffic-Dateien (Burkhard Renk), oder? Was hat dann eine BR2_xxx-Datei zusätzlich unter Aerosoft\AFD zu suchen? Kommt die von VFR Germany? Das Umbenennen der Datei im MyTraffic\scenery-Verzeichnis kann aber ja wohl auch nicht die Lösung sein. Was ist, wenn ich Szenerien deaktiviere, also z.B. VFRG und GAP. Dann würden MyTraffic bei dieser Methode die AFCAD-Daten fehlen.

Es gibt in den XML-Dateien für die Airport Facility Daten doch "Delete"-Einträge (z.B. <DeleteAirport deleteAllApproaches = "TRUE"/>). Sollte man nicht mit diesen Einträgen arbeiten, oder wurde das einfach nur vergessen?

Konkret für diesen Fall: Hätte beim Erstellen der AF2_eddg.bgl eine entsprechende "Delete"-Anweisung in der XML-Quelldatei für den Flughafen EDDG stehen müssen/sollen und fehlt diese Anweisung?

Vielleicht hängt ja auch das Flackern der Info-Seite bei FSMap mit den doppelt vorhandenen Informationen zusammen?

Grüße

Bernd

[BB-17 1]

Vielleicht hängt ja auch das Flackern der Info-Seite bei FSMap mit den doppelt vorhandenen Informationen zusammen?

Hallo,

diese Vermutung ist sicherlich nicht richtig, denn ich hatte das Flackern der FSMap Info-Seite auch auf amerikanischen Flughäfen...

...die keine doppelten Einträge haben.

Grüße

Bernd

[BB-17 1]

Hätte beim Erstellen der AF2_eddg.bgl eine entsprechende "Delete"-Anweisung in der XML-Quelldatei für den Flughafen EDDG stehen müssen/sollen und fehlt diese Anweisung?

Hallo alle zusammen,

ich hatte das Problem (die doppelt vorkommenden Landeprozedur-Einträge) jetzt auch auf einem amerikanischen Flughafen (konkret: KYUM, Yuma).

Also sind VFRG, GAF und GAP definitiv aus dem Spiel. Yuma hat aber auch eine MyTraffic BGL (MyTraffic\scenery\BR2_KYUM.BGL). Wenn man diese Datei mal in *.off umbenennt, dann sind die doppelten Landeprozedur-Einträge verschwunden. Also sieht es danach aus, dass der Fehler bei MyTraffic liegt.

Hier hat man als Anwender aber natürlich keine Chance mehr, den Fehler selbst zu umgehen, denn wenn man die BR2_xxx.BGL-Dateien umbenennt/löscht, dann gehen MyTraffic die Parkpositionen aus...

...andererseits sind die vielen Landeprozedur-Einträge bei den etwas größeren Flughäfen aber auch nervig bis verwirrend.

Vielleicht könnte Burhard Renk ja mal was dazu sagen...

Grüße

Bernd

[Sasa 921]

Konkret für diesen Fall: Hätte beim Erstellen der AF2_eddg.bgl eine entsprechende "Delete"-Anweisung in der XML-Quelldatei für den Flughafen EDDG stehen müssen/sollen und fehlt diese Anweisung?

Tun sie auch. Ich bin gerade wieder für VFR Germany 3 dabei, 350 an das Luftbild angepasste AFCADs für den Ordner AFD zu erstellen. Selbst AFCADs, deren Airports vorher gar nicht im FSX drin waren (z.B. Segelflugplätze), bekommen sicherheitshalber eine Delete-Anweisung.

Ehrlich gesagt höre ich zum ersten Mal, dass durch neue AFCADs etwas doppelt erscheint - was ja aufgrund der Delete-Anweisungen gar nicht sien dürfte. Ich denke, dass es sich hierbei eher um ein Feature/Bug des FSX handelt, der es wohl schafft, nebeneinander existierende AFCADs richtig anzuzeigen (Prio 1 am höchsten - klar), aber die Landeprozeduren doppelt übernimmt.

Grüsse

Sascha

[BB-17 1]

Tun sie auch. Ich bin gerade wieder für VFR Germany 3 dabei, 350 an das Luftbild angepasste AFCADs für den Ordner AFD zu erstellen. Selbst AFCADs, deren Airports vorher gar nicht im FSX drin waren (z.B. Segelflugplätze), bekommen sicherheitshalber eine Delete-Anweisung.

Ehrlich gesagt höre ich zum ersten Mal, dass durch neue AFCADs etwas doppelt erscheint - was ja aufgrund der Delete-Anweisungen gar nicht sien dürfte. Ich denke, dass es sich hierbei eher um ein Feature/Bug des FSX handelt, der es wohl schafft, nebeneinander existierende AFCADs richtig anzuzeigen (Prio 1 am höchsten - klar), aber die Landeprozeduren doppelt übernimmt.

Grüsse

Sascha

Hallo Sascha,

vielen Dank für Deine Antwort. Vielleicht hast Du meinen letzten Post nicht gelesen, denn inzwischen ist es klar, dass der Fehler bei MyTraffic liegen muss (oder beim FSX, wie Du vermutest). Eventuell fehlen die "Delete"-Anweisungen ja bei den MyTraffic BGLs...

Grüße

Bernd

[wmackenbrock 1]

einen derartigen Fehler hatte ich bei der Software LSGG von FSDreamteam. Da waren Parkpositionen und Bodenmarkierungen völlig falsch und auf meine Reklamation bei Dreamteam wurde mir empfohlen, in MyTraffic/scenery nach afcad-Duplikaten BR2_LSGG.BGL zu suchen und die zu deaktivieren. Der Rat war gut, danach war alles in Ordnung.

Bei EDLP im FSX fällt mir in letzter Zeit auf, daß mein final approach nahezu regelmäßig nicht klappt und schnell manuell korrigiert bzw. übernommen werden muß. Hängt das damit vielleicht auch zusammen?

[BB-17 1]

einen derartigen Fehler hatte ich bei der Software LSGG von FSDreamteam. Da waren Parkpositionen und Bodenmarkierungen völlig falsch und auf meine Reklamation bei Dreamteam wurde mir empfohlen, in MyTraffic/scenery nach afcad-Duplikaten BR2_LSGG.BGL zu suchen und die zu deaktivieren. Der Rat war gut, danach war alles in Ordnung.

Hallo Werner,

ich vermute, dass das beschriebene Verhalten bei Dir eine Folge der falschen Szenerie-Reihenfolge war.

MyTraffic bringt eigene AFD-Dateien für sehr viele Airports weltweit mit (da hat sich Burkhard Renk wirklich viel Arbeit gemacht). Dies ist nötig, damit die betreffenden Flughäfen genug Parkpositionen bekommen, um die Maschinen der MyTraffic-Flugpläne auch irgendwo abstellen zu können . Die Standard-Flugplätze vom FSX (auch die vom FS9) haben häufig nicht genug Parkpositionen für ein etwas stärkeres Flugverkehrsaufkommen. Soweit so gut. Wenn man MyTraffic installiert, dann wird es ganz oben in der Szeneriereihenfolge platziert. Dies ist auch völlig OK, wenn sonst noch keine Airport-Szenerien installiert sind. In dem Moment, wo aber schon welche da sind, die ihre eigenen AFD-Daten mit entsprechenden Parkpositionen haben, dann "überschreibt" MyTraffic diese Parkpositionen mit den eigenen, da MyTraffic dann in der Szenerie-Hierarchie höher angeordnet ist.

Den Effekt hatte ich auch schon mal. Ich hatte damals FSDT Zürich und hab' dann MyTraffic installiert und siehe da: Parkpositionen und Taxiways passten überhaupt nicht zusammen...

Nachdem ich die Reihenfolge dann geändert hatte, war wieder alles in Ordnung.

Grüße

Bernd

[Burkhard 23]

Ich schau mir das mal an...

Die VFR-Germany Germany enthält von den Fugplätzen im Gebiet, die auch in MyTraffic eigene Dateien haben, Kopien dieser Dateien, die Sascha überarbeitet hat, indem er etliche Taxiways den drunterliegenden Luftbildern angepasst hat - da waren die Jeppensen-Daten, auf denen ja die FSX airports beruhen, nicht genau genug.

Burkhard

[wmackenbrock 1]

Hallo Bernd,

Danke für Deinen Tipp. In dem von mir geschilderten Fall erfolgte der Ablauf jedoch anders: MyTraffic (noch einmal ein großes DANKESCHÖN! an Burkhard, der hier anscheinend mitliest!) war Monate vor LSGG installiert und schon länger nicht mehr angerührt worden.

Mit dem Anflug auf EDLP Rwy 24 (IPLW) hatte ich vorhin - wie inzwischen jedes Mal - Ärger mit dem Final. Ein Fluchzeug, das ich neu installiert habe (die FSD Commander) wollte ebenso wenig wie ihre Vorgänger per IFR-Approach auf den Asphalt sondern lieber raus irgendwo ins Grüne.

[RemarkH 80]

Hallo miteinander,

ich habe keinen "traffic" und mache gerade meine ersten "Gehversuche" mit ADE. Dabei habe ich folgenden Hinweis erhalten (siehe Foto):

Wenn ich das richtig verstanden habe, bleiben beim Löschen der Originallandebahnen (zumindest bei ADE) eventuell vorhandene Original-Localizer erhalten.

Im SDK habe ich dafür allerdings keinen Hinweis gefunden (was nichts heißt, das ist ja ziemlich dick und manchmal trotzdem etwas knapp )

Hat MS da vielleicht "ein Bein gestellt"?

Servus,

Remark

PS Entschuldigung, falls ich hier "Wasser in die Isar getragen" haben sollte;

bin, wie gesagt, "newbee" auf diesem Gebiet.

[horst18519 231]

Wasser in die Isar trägst Du dabei sicherlich nicht. In diesen "AFCAD"-Dateien (besser "AFD-Dateien") sind etliche Informationen gespeichert, die oft nicht beachtet werden, zum Beispiel Outer Markers oder Wegpunkte für den Approach. Die werden in der Regel wieder in das bearbeitete File gespeichert, wodurch nicht das Problem besteht, dass im FSX auf einmal Anflüge fehlen. ADE ist nun einfach clever genug den User auf diese Dinge aufmerksam zu machen.

Dass es etwas mit den beschriebenen Problemen zu tun hat denke ich nicht. Es dürfte eher ein Prioritätenproblem sein.

[RemarkH 80]

Wasser in die Isar trägst Du dabei sicherlich nicht. In diesen "AFCAD"-Dateien (besser "AFD-Dateien") sind etliche Informationen gespeichert, die oft nicht beachtet werden, zum Beispiel Outer Markers oder Wegpunkte für den Approach. Die werden in der Regel wieder in das bearbeitete File gespeichert, wodurch nicht das Problem besteht, dass im FSX auf einmal Anflüge fehlen. ADE ist nun einfach clever genug den User auf diese Dinge aufmerksam zu machen.

Dass es etwas mit den beschriebenen Problemen zu tun hat denke ich nicht. Es dürfte eher ein Prioritätenproblem sein.

Danke für die Antwort!

Der Ausgangspunkt von Bernd (alias BB-17) war allerdings nicht, dass Anflüge fehlen, sondern dass Anflugverfahren im GPS doppelt vorhanden sind. Aber außer Logik braucht man zur Löung solcher Probleme halt auch eine Menge Erfahrung mit den Eigenheiten des FS.

Servus,

Remark

[BB-17 1]

Hallo alle zusammen,

ich hab' da noch ein paar Bemerkungen zu den Dingen, die hier inzwischen besprochen worden sind:

Die doppelten Einträge, die ich habe, sind Approaches, also Landeprozeduren, keine Navaids wie Localizer. Approaches haben aus FSX-Sicht nichts mit Navaids wie Localizer zu tun, sie sind separate Ressourcen (auch wenn man beim Fliegen einer Landeprozedur natürlich Navaids wie Localizer benötigt).

Approaches können (zumindest laut FSX-SDK) gelöscht werden. Hier der Auszug aus dem SDK mit der kompletten Delete-Anweisung:

<DeleteAirport
      deleteAllApproaches = "TRUE"
      deleteAllApronLights = "TRUE"
      deleteAllAprons = "TRUE"
      deleteAllFrequencies = "TRUE"
      deleteAllHelipads = "TRUE"
      deleteAllRunways = "TRUE"
      deleteAllStarts = "TRUE"
      deleteAllTaxiways = "TRUE"
      deleteAllBlastFences = "TRUE"
      deleteAllBoundaryFences = "TRUE"
      deleteAllControlTowers = "TRUE"
      deleteAllJetways = "TRUE"/>

Navaids, wie z.B. Localizer sind hier aber nicht aufgeführt und können offensichtlich auch nicht gelöscht werden. Im Forum von FSDeveloper.com (wo auch der Entwickler vom ADE, "ScruffyDuck" Jon Masterson häufig Kommentare gibt), habe ich einen Thread gefunden, der sich mit dem Thema (Löschen von kompletten Airports einschließlich Navaids) beschäftigt. Jon Masterson hat darin bestätigt, dass man Navaids wohl nicht so ohne weiteres löschen kann...

ADE ist übrigens ein tolles Tool. Ich hab' selbst mal angefangen, sowas ähnliches zu programmieren, da ja Lee Swordy sein AFCAD-Tool wohl nicht mehr weiter entwickelt und zu dem Zeitpunkt nichts anderes für den FSX verfügbar war. Dabei habe ich allerdings den bgl2xml-Decompiler von Jon Masterson als Basis verwendet, um die vorhandenen BGL-Dateien in XML-Dateien zu konvertieren und damit zu arbeiten.

Als ich soweit war, dass man sich die vorhandenen Airports grafisch ansehen konnte und auch immerhin schon Parkpositionen und Taxiways grafisch verändern und hinzufügen konnte, veröffentlichte Jon Masterson sein ADE... ...und ich hab' seitdem an dieser Funktionalität nicht weitergearbeitet.

Grüße

Bernd

[BB-17 1]

Hallo, schon wieder ich...

ich weiß nicht wieso ich nicht schon länger auf die Idee gekommen bin? Ich hab' jetzt mal eine von den MyTraffic Flughafen BGLs (als Beispiel BR2_EDLP.bgl) mit Jon Mastersons Decompiler in eine XML-Datei verwandelt (das kann man mit meinem selbstgestrickten Tool sehr einfach für jeden Flughafen per Knopfdruck). Folgende Delete-Anweisung ist vorhanden:

      <DeleteAirport
         deleteAllControlTowers="TRUE"
         deleteAllRunways="TRUE"
         deleteAllStarts="TRUE"
         deleteAllHelipads="TRUE"
         deleteAllFrequencies="TRUE"
         deleteAllTaxiways="TRUE"
         deleteAllJetways="TRUE"
         deleteAllAprons="TRUE"
         deleteAllApronLights="TRUE"
         deleteAllBoundaryFences="TRUE"
         deleteAllBlastFences="TRUE"
         deleteAllApproaches="FALSE"/>

Die Approaches werden also explizit nicht gelöscht! Es sind aber noch Approach-Anweisungen in der BGL-Datei vorhanden, z.B.:

      <Approach
         type="ILS"
         runway="06"
         designator="NONE"
         suffix="0"
         gpsOverlay="FALSE"
         fixType="TERMINAL_WAYPOINT"
         fixRegion="ED"
         fixIdent="FI06"
         altitude="914.4M"
         heading="56.7099990844727"
         missedAltitude="914.4M">
         <ApproachLegs>
            <Leg
               type="IF"
               fixType="TERMINAL_WAYPOINT"
               fixRegion="ED"
               fixIdent="KOMIL"
               theta="236.8"
               rho="15560.78M"
               altitudeDescriptor="+"
               altitude1="914.4M"
               altitude2="914.4M"
               />
            <Leg
               type="CF"
               fixType="TERMINAL_WAYPOINT"
               fixRegion="ED"
               fixIdent="FI06"
               flyOver="FALSE"
               theta="236.8"
               rho="10003.36M"
               magneticCourse="56"
               distance="5742.67M"
               altitudeDescriptor="+"
               altitude1="914.4M"
               altitude2="618.744M"
               />
            <Leg
               type="CF"
               fixType="RUNWAY"
               fixRegion="ED"
               fixIdent="RW06"
               flyOver="FALSE"
               theta="236.8"
               rho="2593.46M"
               magneticCourse="56"
               distance="7409.9M"
               altitudeDescriptor="A"
               altitude1="228.905M"
               />
         </ApproachLegs>
         <MissedApproachLegs>
            <Leg
               type="CF"
               fixType="TERMINAL_WAYPOINT"
               fixRegion="ED"
               fixIdent="LP028"
               flyOver="TRUE"
               recommendedType="VOR"
               recommendedRegion="ED"
               recommendedIdent="WRB"
               theta="300.1"
               rho="32418.29M"
               magneticCourse="56"
               distance="8521.38M"
               altitudeDescriptor="+"
               altitude1="334.975M"
               />
            <Leg
               type="DF"
               fixType="NDB"
               fixRegion="ED"
               fixIdent="PAD"
               flyOver="FALSE"
               altitudeDescriptor="A"
               altitude1="914.4M"
               />
         </MissedApproachLegs>
         <Transition
            transitionType="FULL"
            fixType="NDB"
            fixRegion="ED"
            fixIdent="PAD"
            altitude="914.4M">
            <TransitionLegs>
               <Leg
                  type="FC"
                  fixType="NDB"
                  fixRegion="ED"
                  fixIdent="PAD"
                  flyOver="TRUE"
                  recommendedType="VOR"
                  recommendedRegion="ED"
                  recommendedIdent="WRB"
                  theta="292"
                  rho="35197.0M"
                  magneticCourse="255"
                  distance="17969.0M"
                  altitudeDescriptor="+"
                  altitude1="914.4M"
                  />
               <Leg
                  type="CF"
                  fixType="TERMINAL_WAYPOINT"
                  fixRegion="ED"
                  fixIdent="KOMIL"
                  flyOver="FALSE"
                  turnDirection="L"
                  theta="236.8"
                  rho="15560.78M"
                  magneticCourse="56"
                  distance="3704.95M"
                  altitudeDescriptor="+"
                  altitude1="914.4M"
                  />
            </TransitionLegs>
         </Transition>
      </Approach>

Damit, denke ich wenigstens, ist der Grund für die doppelten Landeprozeduren gefunden und Burkhard kann vielleicht im nächsten Update diese kleine Unschönheit korrigieren...

Grüße

Bernd

[RemarkH 80]

Hallo Bernd und alle, die das interessiert,

klingt logisch. Was ist dann aber mit den verbleibenden Stock-Navaids?

Werden die von der Priorität geschluckt oder geistern die trotzdem noch irgendwie umeinander, wie "Scruffy Duck" auf seinem Warnhinweis in ADE angibt

(siehe Foto in post 10)?

Servus,

Remark

[BB-17 1]

Hallo Bernd und alle, die das interessiert,

klingt logisch. Was ist dann aber mit den verbleibenden Stock-Navaids?

Werden die von der Priorität geschluckt oder geistern die trotzdem noch irgendwie umeinander, wie "Scruffy Duck" auf seinem Warnhinweis in ADE angibt

(siehe Foto in post 10)?

Servus,

Remark

Hallo Remark,

wie gesagt, hier geht es um Approaches, nicht um Navaids...

...Jon Masterson meint damit (denke ich mal) Folgendes:

Die Navaids (Localizer usw.) hängen im FSX als Objekte "unterhalb" eines Runway-Objekts (der "Runway"-Knoten ist in der XML-Datei der Elternknoten seines "ILS"-Knotens z.B.). Wenn Du die komplette Runway weglöscht, dann verschwinden auch die Navaids aus der ADE-XML-Datei. Gelöscht werden können die Navaids aber nicht (siehe weiter oben die Delete-Anweisung). Du hast dann zwar die Runway gelöscht (sie existiert dann im FSX nicht mehr, auch wenn sie in der Stock-BGL-Datei noch da ist), die Navaids sind aber weiterhin vorhanden (es gibt also z.B. noch ein ILS zu der nicht mehr existenten Runway).

Wenn Du also mit ADE einen Stock-Airport verschönern willst (das hab' ich auch schon mal "versucht" ), dann solltest Du die Runway nicht löschen und wieder neu aufbauen, sondern lieber die bestende Runway verändern...

Grüße

Bernd

[horst18519 231]

Ah, jetzt verstehe ich worauf Du hinaus willst, Bernd. Du meinst die Entwickler haben im Falle der doppelten Approaches die Runway in der AFD-Datei gelöscht und wieder eine neue erstellt? Damit wären dann in der neuen AFD-Datei die doppelten Approaches drin. Das kann natürlich sein und würde tatsächlich bedeuten, dass die Entwickler da etwas vorsichtiger vorgehen sollten.

[RemarkH 80]

Hallo Remark,

wie gesagt, hier geht es um Approaches, nicht um Navaids...

...Jon Masterson meint damit (denke ich mal) Folgendes:

Die Navaids (Localizer usw.) hängen im FSX als Objekte "unterhalb" eines Runway-Objekts (der "Runway"-Knoten ist in der XML-Datei der Elternknoten seines "ILS"-Knotens z.B.). Wenn Du die komplette Runway weglöscht, dann verschwinden auch die Navaids aus der ADE-XML-Datei. Gelöscht werden können die Navaids aber nicht (siehe weiter oben die Delete-Anweisung). Du hast dann zwar die Runway gelöscht (sie existiert dann im FSX nicht mehr, auch wenn sie in der Stock-BGL-Datei noch da ist), die Navaids sind aber weiterhin vorhanden (es gibt also z.B. noch ein ILS zu der nicht mehr existenten Runway).

Wenn Du also mit ADE einen Stock-Airport verschönern willst (das hab' ich auch schon mal "versucht" ), dann solltest Du die Runway nicht löschen und wieder neu aufbauen, sondern lieber die bestende Runway verändern...

Grüße

Bernd

Hallo Bernd und alle, die so'n Zeuch interessiert,

irgendwie verstehe ich das nicht ganz, vielleicht kann mir ja jemand aud die Sprünge helfen;

schließlich macht der "Durchblick" fast ebenso viel Spass wie das Fliegen selbst.

Ich versuche mal die Frage so genau zu formulieren wie mir das meine Kenntniss der Materie erlaubt:

Voraussetzungen

1.

Der "Approach" ist eine Anweisung wie man (oder der Autopilot) sich von Navaid zu Navaid zum Landepunkt hangelt.

Ohne Navaids (waypoints, NDB, ILS-Localizer) gibt's auch keinen Approach.

2.

Bei jedem Anpassen von ungenau plazierten "Stock-Runways" an Fotoszenerien werden Stock-Runways gelöscht (besser: deaktiviert?).

Siehe AF2-Dateien von Aerosoft. Dort steht regelmäßig in der zugehörigen XML-Datei:

deleteAllRunways="TRUE"

und neue Runways werden mit den zugehörigen ILS, NDB definiert.

3.

Beim Löschen (Deaktivieren?) von Stock-Runways bleiben die zugehörigen Navaids irgendwo in den Tiefen des FS erhalten.

"Scruffy Duck" warnt deshalb in ADE vor dem Löschen von Stock-Runways.

Fragen

1.

Was tun die verbliebenen Stock-Navaids, wenn man die zugehörige Stock-Runway löscht (deleteAllRunways="TRUE"),

durch eine neue Runway ersetzt und neue Navaids (mit gleicher Frequenz?) definiert?

Falls die Stock-Navaids dann lediglich in den Tiefen des FS inaktiv vor sich hinschlummern, könnten sie einem ja gleichgültig sein,

und man müsste nicht von dem Löschen der Stock-Runways abraten, wie dies zB "Scruffy Duck" in ADE tut.

Eine Anweisung, dass für die neue Runway auch neue Navaids erstellt werden müssen (wenn man solche wünscht) wäre völlig ausreichend.

Die Warnung in ADE ist also entweder überzogen oder "S.D." hat einen weitergehenden Grund.

2.

Was tun die verbliebenen Stock-Navaids, wenn man die zugehörige Runway lediglich verschiebt

und neue (passende) Navaids (mit gleicher Frequenz?) definiert?

Sind die "in's Dunkle verbannten" Stock-Navaids dann restlos deaktiviert

(oder sinnen sie dort auf Rache und betreiben möglicherweise Sabotage )?

Vielleicht stehe ich ja irgendwo ganz heftig auf der Leitung.

Wäre schön, wenn mir da jemand runterhelfen könnte.

Servus,

Remark

[Sasa 921]

Die Approaches werden also explizit nicht gelöscht!

Das scheint in der Tat das Problem zu sein. Der Befehl "deleteAllApproaches" Burkhard als auch mir bis jetzt vollkommen unbekannt gewesen. Soll heißen: Er kam erst ohne jegliche Hervorhebung beim FSX SP2 bzw. AccPack hinzu und das Fehlen dessen ist bis auf dir bisher niemandem aufgefallen.

Jetzt haben wir das Problem: Ohne SP2 führt das Ganze unter Umständen zu Abstürzen, mit dem SP2 braucht man den Befehl zwangsläufig. Es ist mal wieder zum Mäusemelken!

Wir werden sehen, was wir hier machen können. Vermutlich wird es in Zukunft also nur noch SP2/AccPack-kompatible Addons wenn es um AFCADs geht.

Grüsse

Sascha

[Burkhard 23]

Das scheint in der Tat das Problem zu sein. Der Befehl "deleteAllApproaches" Burkhard als auch mir bis jetzt vollkommen unbekannt gewesen. Soll heißen: Er kam erst ohne jegliche Hervorhebung beim FSX SP2 bzw. AccPack hinzu und das Fehlen dessen ist bis auf dir bisher niemandem aufgefallen.

Jetzt haben wir das Problem: Ohne SP2 führt das Ganze unter Umständen zu Abstürzen, mit dem SP2 braucht man den Befehl zwangsläufig. Es ist mal wieder zum Mäusemelken!

Wir werden sehen, was wir hier machen können. Vermutlich wird es in Zukunft also nur noch SP2/AccPack-kompatible Addons wenn es um AFCADs geht.

Grüsse

Sascha

Sascha, wenn Du irgendwo die Liste der Airports hast, die in VFR 1 2 3 AF-Dateien haben, kann ich dann sehen, welche BR2... Dateien es dazu gibt, kann nicht jeweils mehr als eine Handvoll sein, die man, hat man das Problem, löschen kann, dann sollte das Problem gelöst sein. Können wir auch eine bat - Datei für schreiben, die das dann macht...

[BB-17 1]

Sascha, wenn Du irgendwo die Liste der Airports hast, die in VFR 1 2 3 AF-Dateien haben, kann ich dann sehen, welche BR2... Dateien es dazu gibt, kann nicht jeweils mehr als eine Handvoll sein, die man, hat man das Problem, löschen kann, dann sollte das Problem gelöst sein. Können wir auch eine bat - Datei für schreiben, die das dann macht...

Hallo Burkhard,

so einfach ist das leider nicht, denn es betrifft nicht nur Airports, die es auch in VFRG gibt, sondern alle Airports, für die es in MyTraffic BR2_xxx.bgl-Dateien gibt. Und das sind erstens sehr viele und zweitens braucht MyTraffic schließlich die zusätzlichen Parkpositionen, wie ich weiter oben ja schon mal erwähnt habe...

...oder?

Grüße

Bernd

[Sasa 921]

Sascha, wenn Du irgendwo die Liste der Airports hast, die in VFR 1 2 3 AF-Dateien haben, kann ich dann sehen, welche BR2... Dateien es dazu gibt, kann nicht jeweils mehr als eine Handvoll sein, die man, hat man das Problem, löschen kann, dann sollte das Problem gelöst sein. Können wir auch eine bat - Datei für schreiben, die das dann macht...

Genau. Viele betroffene Airports wird es in der VFR Germany-Serie nicht geben. Zumindest im Verhältnis zu den hunderten Kleinflugplätzen gesehen.

Wir machen hierfür bei Gelegenheit ein kleines Update (die SDK-Dateien mit Batch kann man ja nicht so einfach verteilen) - kann allerdings noch ein Weilchen dauern.

Grüsse

Sascha

[BB-17 1]

Genau. Viele betroffene Airports wird es in der VFR Germany-Serie nicht geben. Zumindest im Verhältnis zu den hunderten Kleinflugplätzen gesehen.

Wir machen hierfür bei Gelegenheit ein kleines Update (die SDK-Dateien mit Batch kann man ja nicht so einfach verteilen) - kann allerdings noch ein Weilchen dauern.

Grüsse

Sascha

Hallo Sascha, hallo Burkhard,

vielen Dank für Eure Antworten und Euer Interesse an dem Thema.

Der Fehler ist natürlich nicht wirklich schlimm, aber es ist dennoch unübersichtlich mit den vielen (doppelten) Landeprozeduren. Ich benutze dieses Feature im Sandard-GPS vom FSX doch recht häufig...

Hier nochmal eine kurze Zusammenfassung, damit keine Unklarheiten entstehen:

- Wenn jemand MyTraffic installiert hat (unabhängig davon, welche anderen Add-Ons er noch so hat), dann sind von den doppelten Landeprozeduren alle Airports betroffen, zu denen es eine BR2_xxxx.bgl-Datei im MyTraffic\scenery Verzeichnis gibt (das sind über 1800).

- Wenn jemand VFR Germany 1 oder 2 installiert hat (unabhängig davon, ob auch noch MyTraffic installiert ist), dann sind davon (mindestens) alle Airports betroffen, für die im Aerosoft\AFD\scenery Verzeichnis eine BR2_xxxx.bgl-Datei existiert (das sind natürlich deutlich weniger).

Grüße

Bernd

[BB-17 1]

Hallo Bernd und alle, die so'n Zeuch interessiert,

irgendwie verstehe ich das nicht ganz, vielleicht kann mir ja jemand aud die Sprünge helfen;

schließlich macht der "Durchblick" fast ebenso viel Spass wie das Fliegen selbst.

Ich versuche mal die Frage so genau zu formulieren wie mir das meine Kenntniss der Materie erlaubt:

Voraussetzungen

1.

Der "Approach" ist eine Anweisung wie man (oder der Autopilot) sich von Navaid zu Navaid zum Landepunkt hangelt.

Ohne Navaids (waypoints, NDB, ILS-Localizer) gibt's auch keinen Approach.

2.

Bei jedem Anpassen von ungenau plazierten "Stock-Runways" an Fotoszenerien werden Stock-Runways gelöscht (besser: deaktiviert?).

Siehe AF2-Dateien von Aerosoft. Dort steht regelmäßig in der zugehörigen XML-Datei:

deleteAllRunways="TRUE"

und neue Runways werden mit den zugehörigen ILS, NDB definiert.

3.

Beim Löschen (Deaktivieren?) von Stock-Runways bleiben die zugehörigen Navaids irgendwo in den Tiefen des FS erhalten.

"Scruffy Duck" warnt deshalb in ADE vor dem Löschen von Stock-Runways.

Fragen

1.

Was tun die verbliebenen Stock-Navaids, wenn man die zugehörige Stock-Runway löscht (deleteAllRunways="TRUE"),

durch eine neue Runway ersetzt und neue Navaids (mit gleicher Frequenz?) definiert?

Falls die Stock-Navaids dann lediglich in den Tiefen des FS inaktiv vor sich hinschlummern, könnten sie einem ja gleichgültig sein,

und man müsste nicht von dem Löschen der Stock-Runways abraten, wie dies zB "Scruffy Duck" in ADE tut.

Eine Anweisung, dass für die neue Runway auch neue Navaids erstellt werden müssen (wenn man solche wünscht) wäre völlig ausreichend.

Die Warnung in ADE ist also entweder überzogen oder "S.D." hat einen weitergehenden Grund.

2.

Was tun die verbliebenen Stock-Navaids, wenn man die zugehörige Runway lediglich verschiebt

und neue (passende) Navaids (mit gleicher Frequenz?) definiert?

Sind die "in's Dunkle verbannten" Stock-Navaids dann restlos deaktiviert

(oder sinnen sie dort auf Rache und betreiben möglicherweise Sabotage )?

Vielleicht stehe ich ja irgendwo ganz heftig auf der Leitung.

Wäre schön, wenn mir da jemand runterhelfen könnte.

Servus,

Remark

Hallo Remark,

ich bin zwar kein Airport-Designer oder Szenerie-Entwickler, versuche aber mal, die Sache so zu schildern, wie sie mir bekannt ist. Ich fang' mal ganz von vorne an (auch wenn Du das vielleicht alles schon weißt):

Die Daten zu den Airports werden in den vielen, vielen *.bgl-Dateien abgelegt, die man im scenery-Verzeichnis des Flusis und in den scenery-Verzeichnissen von Add-Ons findet. Die Daten liegen darin in binärer Form vor, damit sie der Flusi möglichst schnell laden und lesen kann. Erstellt werden diese Dateien mit Hilfe des BGL-Compilers, der beim SDK des Flusis dabei ist. Die Quelldatei ist dabei eine Datei in XML-Form, deren Inhalt auch (mehr oder weniger genau) im SDK beschrieben wird.

Dabei werden alle möglichen Eigenschaften der Airports als Knoten im XML-Dokument repräsentiert. Die Knoten sind hierarchisch angeordnet. So müssen die Knoten, welche Airport-Eigenschaften beschreiben, immer Kindknoten des entsprechenden Airport-Knotens sein. NDB-Knoten hängen dabei z.B. direkt unter einem Airport-Knoten, genau wie dessen Runway-Knoten. ILS-Knoten jedoch gehören zu "ihrer" Runway, hängen also nicht direkt unterhalb des Airport-Knotens, sondern unterhalb eines Runway-Knotens. Diese Struktur wird vom BGL-Compiler so vorgeschrieben. Hält man sie nicht ein, dann kann der Compiler keine BGL-Datei erzeugen...

Jon Masterson (und auch andere) haben nun einen Decompiler programmiert (Hut ab vor dieser Leistung, denn soviel ich weiß, gibt es keine Beschreibung des binären Aufbaus der BGL-Dateien), der aus den vorhandenen BGL-Dateien "rückwärts" wieder die zugrundeliegenden XML-Quelldateien erzeugt. Diesen Decompiler von Jon Masterson verwende ich auch für mein selbstgestricktes Tool zum Anzeigen der Airport-Pläne und auch das ADE verwendet es (dafür hat's Jon Masterson programmiert).

ADE baut sich am Anfang eine Datenbank auf, mit deren Hilfe zu jedem Flughafen die BGL-Datei gefunden werden kann, in der seine Eigenschaften definiert sind. Mit den Informationen erzeugt dann ADE die XML-Quelldatei, die sämtliche Eigenschaften des "Stock"-Airports enthält, den man ausgewählt hat (oben z.B. EDLP). Dies ist also zunächst mal eine Kopie des Originals. Zusätzlich enthält die XML-Datei eine Delete-Anweisung, die ich schon mal erwähnte, wodurch der Flusi später angewiesen wird, die entsprechenden Eigenschaften aus der vom ADE erzeugten BGL-Datei zu nehmen und die Eigenschaften aus den anderen BGL-Dateien, die den gleichen Airport beschreiben, zu vergessen (zumindest wenn die ADE-BGL-Datei eine höhere Priorität hat).

Leider können (aus welchen Gründen auch immer), die Navaids, wie z.B. ILS nicht gelöscht werden, dafür gibt es keine Delete-Anweisung. Löscht man jetzt mit ADE eine komplette Runway, dann muss ADE zwangsläufig auch dessen ILS-Knoten mit löschen, da er unterhalb des Runway-Knotens hängt. Da ADE eine Delete-Anweisung für diese Runway eingefügt hat, ist sie damit später dann komplett weg (auch wenn sie in der Original-BGL-Datei noch existiert).

Das ILS dieser Runway ist aber noch vorhanden, wie auch immer sich das auswirken mag (vielleicht wird das auf irgendeiner Karte oder in irgendeiner Liste angezeigt, zumindestens aber wird man die NAV-Frequenz einstellen können und auch ein Signal empfangen, wenn man in der Nähe ist, auch wenn keine Runway weit und breit zu sehen ist...).

Nun zu den Approaches. Approaches haben ebenfalls XML-Knoten, die auch unter dem Airport-Knoten hängen (siehe als Beispiel meinen Post weiter oben). Jede Landeprozedur hat einen eindeutigen Namen, unter dem sie auch im Flusi-GPS aufgeführt wird. Aber wie Du siehst, wird in den Daten des Approach-Knotens nirgendwo ein ILS z.B. erwähnt, es werden nur "Legs" beschrieben (Anfangspunkt, Richtung, Länge usw.), die zusammengenommen dann den "Pfad" beschreiben, der im GPS angezeigt wird, wenn man einen Approach ausgewählt hat. Zum Anfliegen braucht man dann natürlich die entsprechenden Navaids, zur Beschreibung des Approaches im XML-Dokument sind diese aber nicht erforderlich...

Ich hoffe, diese länglichen Ausführungen haben ein bisschen für Erhellung gesorgt und nicht noch mehr Verwirrung gestiftet...

Grüße

Bernd

[Sasa 921]

Kurz noch zur Info: Da dieser Befehl erst still und heimlich mit dem SP2 dazu gekommen ist, kann es durchaus sein, dass 99% aller Szenerien, die in der Standardversion des FSX schon Approaches haben, betroffen sind. Also nicht nur Aerosoft-Szenerien. Wir werden sehen, was wir machen können.

Grüsse

Sascha