...nachdem Traffic Editor 2005 daraus eine Flightplans.txt gemacht hat

hi,

@ Wolfgang27
Mit den Anmerkungen zu den Aircrafts (Punkt 1) hattes du natürlich Recht. Diesen Punkt hatte ich gar nicht bedacht.
Obwohl: Wenn der Absturz des Systems zu unterschiedlichen Tageszeiten vorkommt, kann es doch durchaus Sinn machen, die Fehlersuche bei lokal vorkommenden Airlines zu beginnen

Ich habe zur Zeit mehr als 400 händisch erstellte Traffic - BGLs und die schluckt ACA2005 problemlos.

@MeatWater
Der Fehler, den ACA2005 generiert ist eindeutig nachvollziehbar. Bei mir tritt er auf, wenn ein 'AC#'-Eintrag syntaktisch fehlerhaft zum Flugplan ist. Ich würde daher den fehlerhaften Flugplan suchen und decompilieren. Bei 150 BGLs kann das schwierig werden.

In dem Fall würde ich erstmal alle Traffic_BGLs aus dem FS -Verzeichnis ausschneiden und wegsichern. Dann mit 10 BGLs anfangen und ACA starten. Bei dem Fall dürfte ACA auch erst dann anfangen Fehler zu werfen, wenn sich eine fehlerhafte BGL im Verzeichnis befindet. So könntest Du das leichter eingrenzen.

FS Repaint zeigt im übrigen nur die Texturen. Eine fehlerhafte Texture wird dann grau angezeigt und der FS macht das genauso. Die fehlerhafte Textur wird meines erachtens nach ignoriert und es rollt eine grauer Flieger übers Vorfeld. ist der ganze Flieger fehlerhaft (mdl - File beschädigt o.ä.) wird das Flugzeug im FS (und in FS Repaint) erst gar nicht angezeigt. Das dürfte nicht zum Absturz führen.

ACA krepiert an der Stelle auch dann, wenn gar keine Traffic.bgl vorhanden sind

.Net Framework 2.0 haste aber installiert?

Das Supportforum gibt diesbezüglich keinerlei Anmerkungen aus:( Evtl da mal eine Anfrage stellen denn der Entwickler dürfte evtl besser wissen wo der Fehler liegt?

Soooo, (sehr!) erleichtert kann ich nun zu 99% behaupten, das Problem gelöst zu haben - etwas Murphy ist ja beim FS immer dabei :rolleyes:

Also: was genau die ursache war, kann ich nicht sagen, da ich gleich mehrere Fehler aufgedeckt und beseitigt habe. Erfreuliches Beiwerk: es hat Performancemässig auch noch einmal einen satten Sprung nach vorne gemacht :-)

Ich war ja anfangs davon überzeugt, dass fehlerhafte AI-Flieger verantwortlich seien, woraufhin ich auf alle mir bekannten Arten den AI-verkehr auseinandergenommen hatte. Irgendwann merkte ich dann, dass ein Teil der Abstürze mit dem aufpoppen einer ATC-Meldung zusammenhing. In Editvoicepack überprüfte ich daraufhin stichprobenartig Sounddateien, die mit GROUND und DEPARTURE zu tun hatten, denn die meisten der neu hinzugekommenen CTDs (!) ereigneten sich zu Zeiten zu denen ich mit diesen Stellen in Verbindung stand. Und siehe da, beim Aufruf einiger Sequenzen gab es auch in EditVP einen CTD. Von den vielen hundert Fitzelchen innerhalb der großen ATC-Datei waren also einige beschädigt und für die CTDs verantwortlich. Ich erstellte dann eine komplett neue Datei, und die CTDs waren weg.

Nicht aber die fe.dll, g2d.dll und g3d.dll Probleme.

Die einzige Art "Szenerie" im gebiet um Kos waren LTU 2005 und AES. Eine neuinstallation von LTU 2005 brachte nichts, auch eine korrigierte AFCAD Datei nicht. So war ich denn wirklich soweit, den FS (160GB) neu zu installieren...FSX, das wäre deine Chance gewesen. ich begann dann, Sicherungen anzufertigen, und meine DAT-DDateien von AES waren das erste. Und da kam mir die Idee, AES einfach nochmal neu zu installieren.

Tja, und seitdem rennt er wieder :aio:

....erstens: Großer Indianerglückwunsch!
Zweitens: Es bestätigt die in mehreren posts geäußerter Vermutung, daß es mit dem Traffic zusammenhängt.
Drittens: Die Idee, übers VoicePack zu checken ist super.

Frage: Wie hat sich denn das VoicePack "verabschiedet"? Und was wurde aus den .dll_Problemen?

a3g
Wolfgang

Bin gerade auf FL310 mit der CLS DC-10 unterwegs und feier die Angelegenheit (kein Witz) mit einem Glas Sekt :D (naja, war' n Rest der eh wegmusste aber immerhin!). Bin wirklich sehr froh darüber, es sind inzwischen satte 140GB FS die dann über'n Jordan gewesen wären. Da er jetzt so gut läuft wie nie zuvor erwäge ich den Kauf einer weiteren externen HD um dieses Monstrum endlich mal zu sichern.

Das es etwas mit den Voicepacks zu tun haben könnte dachte ich schon recht früh, da ich aber noch nie von einem solchen Fall gehört hatte zögerte ich, dem auf die Spur zu gehen. EditVP verabschiedete sich beim Versuch, die kaputten Files abzuspielen genauso, wie der FS: Paff, CTD, keine Fehlermeldung. Beide nutzen die Direct Sound Schnittstelle zur Ausgabe, die sich in diesem Falle verabschiedete, deswegen wohl das gleiche Verhalten. Bei anderen Spielen konnte ich so auch schonmal die Ursache für einen CTD finden. Dies ist vielleicht ein nützlicher Hinweis für CTD-geplagte.

Die dll Probleme wurden durch die Neuinstallation von AES sowie vermutlich durch das Überspielen mit "heilen" Dateien anderer Forumskollegen (hier nochmal danke denen die mir so schnell die dll geschickt hatten) gelöst werden. Ich habe diese "gesunden Dateien" jetzt zu einem "FS-Rescue-Kit" gebündelt, den ich mir für solche Fälle warm halten werde.

Defragmentieren, ausmisten überflüssiger Gauges und alter dll Dateien im Modules Verzeichnis sowie das Aufspielen des aktuellen Catalyst haben dann den Rest besorgt :karate:.

:bier: :bier: :bier: :bier: :bier: :bier: :bier:

na denn - cleared for take-off!

Wolfgang

Ich habe seit ca 3 Wochen auch das Problem mit mit völlig überraschenden Abstürzen des FS9 (über Süddeutschland/Österreich).

AES benutze ich nicht. Daran kann es also nicht liegen.

EditVoicepack habe ich als Teil von MyTraffic 4.1. Wie kann ich denn die Datei neu erstellen, um diese mögliche Fehlerquelle auszuschließen?

Gruß

Arndt

Deaktiviere erst mal den AI-Traffic und schau, ob das Problem dann noch auftritt