Overlay Airport

[Holger Racko]

Allerdings sollte der FS, wenn man keine Größe angibt, Spannweite:2 = Radius benutzen, so dass auf einem GA small auch ohne die Angabe kein A321 stehen sollte.

Hier mal ein paar Größenangaben für die Project AI Flugzeuge (jeweils benötigter Radius)..:

A300 : 74ft
A310 : 73ft
A319 : 56ft
A320 : 56ft
A321 : 56ft
A330 : 99ft
A340 : 99ft

737OG: 47ft
737MG: 48ft (-3/4/5)
737NG: 57ft
747OG: 98ft
744 : 106ft
757 : 63ft
767 : 79ft
777 : 100ft

MD80 : 54ft
DC10 : 83ft
MD11 : 85ft

Avro : 47ft
ATR42: 41ft
ATR72: 45ft
CRJ : 38ft
Dash8: 46ft
F50 : 48ft
F100 : 47ft

Unsere Vorschläge für Gate-größen:

Apron-Parkings für Regios : 50ft
Gate Small : 60ft
Gate Medium : 95ft
gate Heavy: : 110ft

[Chris]

Deine Werte decken sich auch in etwa mit meinen Erfahrungen.

Ich habe mir jetzt mal die SDK angeschaut...würde das nun bedeuten, dass ich in jedem Fall die modifizierte (um meine Flieger erweiterte) "AircraftTypes.dat" bzw. "CustomaircraftTypes.dat" mit dem TrafficDatabaseBuilder durchrauschen lassen muss?
Geht da nicht der bisher generierte Traffic flöten?

[Holger Racko]

Ja, leider Das ist ja das große Problem mit den Cargoflugzeugen. Wie gesagt, ohne die Angaben geht er nach dem tatsächliem Radius.

Ich habe oben übrigens eine alte Version der Liste gepostet, die nicht stimmt. Neue kommt nachher.

[Holger Racko]

Richtige ListeProject AI - required Gate Radius

Airbus:

A300 74 ft
A310 73 ft
A319 56 ft
A320 62 ft
A321 74 ft
A330 106 ft
A340 106 ft

Boeing:

B737-100/200 48 ft
B737-300/400/500 60 ft
B737-600/700/800/900 70 ft
B747-100/200/300 116 ft
B747-400 116 ft
B757 80 ft
B767 91 ft
B777 122 ft

MDD/Boeing:

MD-80 74 ft
MD-90 77 ft
DC-10 92 ft
MD-11 101 ft

British Aerospace:

BAe 146 / Avrojet0 52 ft

ATR:

ATR 42 41 ft
ATR 72 45 ft

Canadair:

CRJ 54 ft

DeHavilland:

Dash8 50 ft

Fokker:

F28 45 ft
F50 48 ft
F70 52 ft
F100 59 ft

Embraer:

ERJ-135 44 ft
ERJ-145 49 ft

Saab:

Saab 340 36 ft
Saab 2000 45 ft

http://project-air.deep-ice.com
... bitte nur mit dieser Arbeiten.

[Chris]

Da gibt's im Ansatz bereits eine ähnliche Diskussion in einem anderen Thread, frage aber trotzdem mal hier:

Mit dem AITraffic-Editor möchte ich einen einwöchigen Umlauf einer Maschine nachzeichnen. AITraffic lässt allerdings nicht mehr als 25Legs in einem Umlauf zu, und natürlich bin ich gerade erst bei Mittwoch angekommen.
Mache ich jetzt einen weiteren Flug-Umlauf mit der gleichen Maschine auf und setze die Eintragungen der Legs ab Donnerstag fort, so steht die andere Maschine wohl in jedem Fall dann von Do - So nutzlos rum und der gegenwärtige flieger dann von Mo - Mi.

Gibt's hierfür noch einen 'Workaround'?

P.S.: ...und Danke für die Liste.

[Walter-F]

Ähhm,

ich habe bis hierher andächtig geschwiegen. Aber jetzt wüsste ich doch gerne wovon hier die Rede ist.

snipp----------------

"Ich habe mir jetzt mal die SDK angeschaut...würde das nun bedeuten, dass ich in jedem Fall die modifizierte (um meine Flieger erweiterte) "AircraftTypes.dat" bzw. "CustomaircraftTypes.dat" mit dem TrafficDatabaseBuilder durchrauschen lassen muss? Geht da nicht der bisher generierte Traffic flöten?"

snap---------------------

SDK habe ich noch verstanden. Dann habe ich nach diesen Dateien auf meinem armen Compi gesucht. Gefunden habe ich sie nicht.

Liiiieeeeber Chris, ich weiß ich bin ein unwürdiger Wurm, aber könntest du mich trotzdem aufklären??????

LG Walter

[Chris]

Sorry Walter,

bin gerade erst von unserem phänomenalem FlightSim-Meeting auf und nach der ILA zurück und muss erstmal meine Beine sortieren .

Das "Software Development Kit" findest Du auch nicht auf Deinem Rechner - Du musst es Dir erst bei Microsoft herunterladen (http://zone.msn.com/flightsim/).

In diesen SDK's stehen dann die "Regularien" für diverse Programmelemente und Schnittstellen, u.a. auch für den AI-Traffic.
Es gibt hierzu auch englischsprachige Dokumentationen (in den SDKs enthalten), die genau beschreiben, wie was wofür geändert werden kann.

Ein Teil dieser SDKs betrifft die Aircraft Database, die etwas anderes ist, als das, was TTools aus dem traffic.bgl als aircraft.txt herauscompiliert. Dort lassen sich die Modifikationen verändern, von denen Holger hier sprach.
Um diese wieder als traffic.bgl umzuwandeln, bedarf es aber einer Neucompilierung mit dem im SDK mitgelieferten TrafficDatabaseBuilder, der nun, wie Holger das bestätigt hat, den bisherigen traffic.bgl komplett überswchreiben würde.

Nun klar?

[Walter-F]

Hi!

Danke für die Aufklärung. Ich habe mir den SDK angesehen. Ich glaube es gäbe 2 Wege um die selbstgeformten Flugpläne zu retten. Einen komplizierten der sicher funktioniert und einen einfachen den man mal ausprobieren müsste.
1.) Jemand schreibt ein kl. Progrämmchen, dass die Flugpläne für die CustomRoutes.dat aufbereitet und man schaltet beim compilieren AutoRoute ab oder
2.) Wenn es nur darum geht die AircraftTypes zu spezifizieren (Cargo/Ramp/Gate usw.) dann lässt man den Compiler mal machen hebt sich aber die alte Flightplans.txt auf. Dann decopiliert man in Ttools und compiliert wieder mit den alten Flugplänen. Die Gefahr wäre, dass Ttools diese Spezifikationen überschreibt, was ich nicht weiß. Müsste man halt mal ausprobieren!!! Vielleicht findet sich ein Freiwilliger? Wenn ihr ein paar Wochen Zeit habt kann ich das auch selbst machen, aber bis Ende Juni würde es bei mir dauern. Bis dahin habe ich kaum Luft für längere Tests.

So jetzt zu dem ursprünglichen Thema diese Ordners:
Jetzt kommen ich endlich dazu einen Bericht zu geben was die bisherigen Tests ergeben haben. Nach meinem letzten Erfahrungsbericht habe ich Atlanta auf zwei Flugplätze reduziert KATL (Jets) und 2ATL (Regional und GA). Es Passierte folgendes: Wenn man den Flusi startete stehen alle Flieger dort wo man Sie eingeteilt hat. Also KATL und 2ATL sind getrennt. Die Flieger starten und landen auch auf dem 'richtigen' Airport, aber parken, wenn sie ankommen, nur auf den Plätzen die man für den zweiten, neuen Port (in diesem Fall 2ATL) definiert hat. An diesem Punkt war ich etwas ratlos. Holger hat mich dann mit Thomas Moltor aus dem Forum zusammen gebracht. Er hatte dann die glänzende Idee wie man einen Overlay Airport wirklich unabhängig betreibt. Er ist darauf gekommen den Airport Reference Point zu verändern. Solange die beiden Punkte, also Reference Point von zB KATL und 2ATL, übereinander liegen entsteht das von mir beschriebene Chaos. Jetzt habe ich die ARP verschoben, jeweils zu den Landebahnen hin und damit ist alles in Ordnung. Das bedeutet aber leider gleichzeitig mehr Arbeit, da in AFCAD sämtliche Taxiways (aber nicht die Landebahnen und die Navaids) mitverrutschen. Man sollte also zuerst einen Flieger auf eine markante Node stellen, den ARP verlegen, alles selektieren mit gedrückter Shift - Taste die Landebahnen und die Navaids wieder aus der Selektion herausnehmen und dann mit der Maus die Taxiways mit der markanten Node wieder zum Flugzeug verlegen. Klingt kompliziert und ist es beim ersten Mal auch. Beim 10 Flughafen wird man den Bogen dann raus haben. Jedenfalls bin ich jetzt stolz, dass die Flieger jetzt völlig unabhängig links und rechts landen und starten, alle 4 Bahnen in Betrieb sind und die Flugzeuge beim Parken nicht durcheinander quirln.
Alles toll, das einzige Problem ist, dass ich immer mehr draufkomme, dass mein Rechner zu schwach ist . Durch die vielen Flugbewegungen und die vielen Flugzeuge sackt die Framrate immer mehr in den Keller. Nun nächste Weihnachten kommt bestimmt!!!
ATL muss ich nochmal überarbeiten. Wenn ihr wollt könnt ihr KLAX und 2LAX aus der Beilage herunterladen, den Traffic teilen und es geht schon.
Viel Vergnügen

Walter