der krampf mit den AF2's

[Trippleseven 26]

ich weiss nicht, ob nur mir es so geht: mich ärgert es immer wieder, wenn die guten szenerie-entwickler immer wieder so tun, als wäre eine gewisse 'ordnung' nach parkpositionen vollkommen egal ... ja, vielleicht ihnen - aber sicher nicht den benutzer. die sind oft so geordnet, dass man annehmen muss sie wären wie bei einer lottoziehung entstanden.

egal ob das AF2 von FlyTampa, Aerosoft, Simwings oder sonst wem stammt ...

es ärgert maßlos, dass man dann IMMER selbst noch hand anlegen muss, denn das AF2 gehört auch zum produkt, welches man kauft!

[OPabst 2091]

Hallo Patricia,

warum so agressiv, kenne ich ja garnicht von Dir. Vielleicht gibts ja einen Grund, kann man ja drüber reden.

Zuvor hätte ich aber von Dir gerne gewusst, wie deine "bevorzugte" Reihenfolge ist?

[Trippleseven 26]

ooch Oliver ... mir ist nur der imaginäre kragen kurz geplatzt - als zuerst das war in Antalya mit den nummern wo es in sich nicht stimmt und dann ärgerte ich mich über das flyTampa AF2 von flyVienna (v2). das war der auslöser, aber ich ärgere mich schon oft darüber, dass die gates wie wild in der reihenfolge durcheinanderschiessen bei mehr als ein paar addon und betrifft jeden hersteller.

also mir (und ich denke fast jeden) wäre es recht, wenn es eine gruppierte reihenfolge geben würde - wie z.b. im Antalya-AF, wo die plätze am satelit gruppiert sind, die freien ppos auch usw.

ich hoffe es ist klar geworden wie ich es meine.

[OPabst 2091]

Ok, für die Auswahl gebe ich Dir recht, wäre eine logische Sortierung besser, aber:

Du bist ja nicht ganz unbedarft was AI Traffic angeht. Der FS weist die Gate dem AI Fliegern ja in der Form zu, dass er zunächst die Reihenfolge im Afcad durchläuft und dann die erst Position ohne oder mit passendem Airlinecode und zum Aircraft passendem Radius zuweist.

Sortiert man nun die Gate so, wie es vom Namen oder dem Terminal richtig wäre, dann stehen zum einen ggf. alle Flieger in dieser Reihenfolge oder/und kleine auf großen Positionen, was alles blöd ist.

Daher ordnen wir die Gate zunächst nach der Größe, und "würfeln" dann die Gates innerhalb eines gleichen Radius durcheinander, damit keine aufsteigende Ordnung entsteht.

Das mag nicht immer 100% perfekt sein, aber besser als eine numerisch Sortierung. Es verhindert in der Regel auch, das Regio Flugzeuge auf Positionen landen, die normalerweise nur die großen Jets nutzen.

Also ist die Unordnung durchaus gewollt, wenn auch nicht schön sortiert.

Ich kann jetzt nicht sagen, ob das für alle von Dir genannten Afcad so umgesetzt ist, aber dies ist die Empfehlung an die Macher der Afcad's von Gap und Simwings.

( sorry, hab's im iPad geschrieben, daher Tippfehler vorbehalten )

[rolfuwe 1]

Damit muß man leben. Da ich an meinen Traffic, AI-Aircraft u. Parking codes sowieso herumbastele muß das AFD auch daran angepaßt werden.

[OPabst 2091]

Ich möchte noch ein kleines Beispiel anfügen, das die oben gemachte Aussage bezüglich der "Sortierung" verdeutlicht:

Nehmen wir den A-Finger in Frankfurt. Dort gibt es Postionen von A10-A42, wobei alle >A26 ausschließlich von Type wie B73x oder A32x benutzt werden, im unteren Bereich aber auch Positionen für A33x/A34x oder B747 vorhanden sind. Alle Positionen erhalten Airlinecodes der LH und der Staralliance Partner.

Sind diese nun Alphanumerisch sortiert, und kommen zunächst nur Flieger der 737/A320 Klasse, so würde der FS die Positionen aufsteigen von A10 mit ihnen belegen, da überall der Radius ausreicht für die Klasse und der Airlinecode passt.

Folgt dann eine B747, so sind je nach Trafficaufkommmen ggf. alle Positionen unter A26 bereits belegt, also auch die, welche vom Radius für die B747 passen würde. Die Position >A26 sind aber zu klein, Folge ist, die 747 und andere große Flieger würden in der Regel nur noch Aussenpositionen finden, da diese mit der Vxxx Bezeichnung weit hinten liegen.

Das Verteilungsbild wäre also recht eintönig.

Sortiert man die Gates zunächst nach Radius, finden die kleiner Flieger in der Liste die Positionen zuerst, die für ihre Größe ausreichend sind, somit füllen die B737 Flieger auch zunächst die kleiner Positionen A26-A42, bevor sie bei "Überfüllung" überhaupt zu den großen Positionen am A-Finger kommen.

Wie man dann die Gates innerhalb einer Größe sortiert, ist auch von den Gegebenheiten des Airports abhängig. Zunächst alle Fingerpositionen am Terminal nach oben zu setzen macht sicher auch nicht so viel Sinn, da dann diese alle immer belegt sind, das Vorfeld leer bleibt. Also muss man hier eine gute Durchmissung finden.

Schwieriger wirds dann, wenn man auch den User Aircraft noch berücksichtigen will, da diese vom ATC ja die erste frei Position bekommt, die vom Radius passt, ohne dass dabei der Airlinecode berücksichtig wird. Hier muss man dann ggf. mit der Reihenfolge spielen, so dass ein sinniges Gate für den User frei bleibt, ohne dass es immer das gleiche ist. Das hängt natürlich auch von der Airline des Users ab, wo dieses sinnige Gate liegen kann, somit kann der Afcad Macher hier keine globale richtige Version liefern und der interessierte User muss ggf. eine eigene Variante finden.

PS: Alles setzt natürlich auch voraus, dass die Wahl des Radius einer gewissen Regel folgt, sowohl im Afcad, als auch im AI/User Flieger. Hier ist die gute alte PAI Definition derzeit aber glaube ich immer noch die vernünftigste, da WOAI sie verwendet und dieser Traffic die weiteste Verbreitung haben dürfte, selbst im FSX noch.

[Trippleseven 26]

hallo Oliver!

erstmal vielen dank für deine ausführungen, gegen die man sicher nicht viel einwenden kann. hier gebe ich dir auch recht dass es nicht so einfach bis fast unmöglich ist ein AF2 zu gestalten, das keine wünsche offen lässt.

auch habe ich ja nichts gegen die meisten AF2's und ich verwende ja auch die meisten kommentarlos. nur eben das AF von flyVienna v2 regte mich zusätzlich zu Antalya zuviel auf.

ich machte dann (nach dem schreiben der 2 nachrichten hier) bei flyVienna mal "tabula rasa", griff zum AF2 editor und gruppierte alle ppos schnell:

mal abgesehen von einer Korean B747F am sateliten und einer Austrian B772 bei der Austrian-Technik (die sich dann nach fern-ost ausmachte) sah es gar nicht so übel aus. naja zumindest für meine verhältnisse - du weisst ja wieviel ich mich um passendes umfeld kümmere ... - aber sah es besser aus, als das original (nur bei dem hatte ich eine ATR beim finger!).

tja, so wird es immer beleiben schätze ich mal, dass man das wohl niemanden komplett recht machen kann.

Hier ist die gute alte PAI Definition derzeit aber glaube ich immer noch die vernünftigste, da WOAI sie verwendet und dieser Traffic die weiteste Verbreitung haben dürfte, selbst im FSX noch

also wir bei WoAI machen da nichts rum mit den radien. wir übernehmen die modelle samt aircraft.cfg eigentlich immer so wie sie sind vom hersteller kommt. einziger punkt wenn wir uns einmischen betrifft nur evtl. den 'atc_parking_code' oder 'atc_parking_type', aber die radien lassen wir schön in ruhe.

apropos rumschauen am airport & AES:

da ich einige zeit ein flugzeug am gate hatte und draussen rumsah fiel mir eine kleinigkeit bei AES auf, wo ich nicht weiss ob du das ganz absichtlich so gemacht hast oder evtl. schon bei "AES NG" weg sein wird (wenn es so ist bitte ich um eventuelle korrektur oder implementierung in NG:

mir fiel auf, dass die kofferauslade-gruppe zwar an das flugzeug ran kommt, dann dort aber bleibt, bis man wieder vom gate weg will. kann man das nicht so machen, dass die wieder verschwinden und evtl. wiederkommen, falls man wieder vom gate weg will?

einen schönen So-NM noch und liebe grüsse,

Patricia

[OPabst 2091]

Ok,

wie es Martin von Flytampa macht, dazu kann ich nichts sagen, habe nie mit ihm darüber gesprochen, müsstest Du ihm ggf. mal ansprechen.

Was die AES Cargo/Koffer Lader angeht, da wird sich sicher einiges ändern in NG, aber eigentlich bleiben die Beladefahrzeuge ja während des Umlaufes am Flieger stehen, nur wenn der Flieger abgestellt wird (also über Nacht zum Beispiel, wird alles weggefahren und die "Türen" geschlossen. Dieses "Park" Feature fehlt in AES sicher noch.

Jetzt habe ich aber auch noch eine Bitte: Könntest Du mal deine Kontakte zu WOAI nutzen und darum bitten, dass man mal die Texturenfehler im alten Spainair Packet bei den Fliegern korrigiert und das Packet auf AVSIM/Flightsim austauscht. Es ist ja nun lange bekannt, leider bekommt's nicht jeder mit und die CTD nerven die User, die dann meist erstmal zum Airporthersteller gehen und die Scenery im Verdacht haben (wie bei Barcelona kürzlich), dort entsteht dann unnötiger Supportaufwand um den Usern das Problem zu erklären.

[Trippleseven 26]

Jetzt habe ich aber auch noch eine Bitte: Könntest Du mal deine Kontakte zu WOAI nutzen und darum bitten, dass man mal die Texturenfehler im alten Spainair Packet bei den Fliegern korrigiert und das Packet auf AVSIM/Flightsim austauscht. Es ist ja nun lange bekannt, leider bekommt's nicht jeder mit und die CTD nerven die User, die dann meist erstmal zum Airporthersteller gehen und die Scenery im Verdacht haben (wie bei Barcelona kürzlich), dort entsteht dann unnötiger Supportaufwand um den Usern das Problem zu erklären.

also meine "kontakte" zu WoAI sehen wohl so aus, dass es an mir hängen bleiben wird ein neues pack zu machen, bzw. das alte aufzuschnüren.

ich habe mal das paket von AVSIM runter geladen und schnell mal reingesehen. dabei fielen mir 2 kleine fehler auf, von denen der eine mehr oder weniger egal ist und pkto. texturen entdeckte ich mur eine 32-bit bitmap anstelle einer DXT-3 (~ 3 MB unterschied). in beiden fällen wage ich nicht zu sagen, dass es sich um einen CTD auslösenden fehler handelt. trotzdem gehört aber die bitmap ausgewechselt.

entweder mache ich ein neues pack (Su07 ist eben doch schon recht alt) wenn ich ansprechende flugpläne, modelle und paints habe oder es wird ein kleiner update.

nebenbei: Oliver kannst du mir bitte mal eine email-adi zukommen lassen, damit wir nicht in den foren solche sachen besprechen müssen?

[OPabst 2091]

Ja, genau diese 32 Bit Texturen machen aber das Problem. Ein einfaches Konvertieren via DXTbmp zu DXT3 fix es auch. Würde völlig reichen, diese auszutauschen und das Packet dann so wieder hochzuladen. Spanair wechselt ja derzeit eh das Aussehen, da wird ein vollupdate sicher etwas aufwendiger.

Es gibt da noch das ein oder andere Packet wo so ein Texturenproblem mal auftrat, leider kann ich mich nicht errinnern welche es waren, muss mal Rainer fragen, ob er eine Liste hat.

Gerade beim Spanair Pack ist es aber am auffälligsten, da es fast jeder in Europa hat und so treten die CTD reports halt bei LEMD, LEBL und sogar bei EDDM auf, da der buggy Flieger offensichtlich auch MUC anfliegt. Im Extremfall kann der BUG sogar im Flug auf 30000 feet zum Tragen kommen, wenn man ein "nearby" mit dem Flieger hat.

Da das Thema von öffentliches Interesse ist, kann man schon mal übers Forum diskutieren, aber Du bekommst eine PM.

[Trippleseven 26]

also ich habe jetzt mal einen winterflugplan 10/11 und wenn sich das problem mit einem painter auflöst, gibt es sicher ein neues pack. das aktuelle ist ja schon recht alt und das neue design fällt ja zu diesem zeitpunkt noch nicht wirklich rein (ausserdem gibt's momentan imho auch nur die EC-IPI im anderen paint).

sollten die probleme mit dem painter bestehen bleiben, wird das alte binnen kurzer zeit wohl einfach einen update nekommen.

p.s.: danke für die PM, alles klar!

[Trippleseven 26]

Oliver, ich möchte dir nur mitteilen, dass wir (WoAI) heute Spanair v3 released haben.