AI-Traffic Experten gerfragt
 

Zwischen Kos und Mazedonien verabschiedet sich der FS regelmässig mit einer fe.dll Meldung. Ich kann das soweit eingrenzen als dass ich mit Sicherheit sagen kann, dass es am AI-Traffic liegt. Filemon brachte nichts zutage, aber der FS läuft sonst sehr stabil und flüssig, und ich habe nichts am FS geändert, bin halt nur zum ersten Mal dort unten in der Ecke geflogen. In anderen Regionen - auch in Europa - passiert das nicht.

Was kann Ursache dafür sein? wie erkenne ich fehlerhafte Texturen an AI-Flugzeugen? Kann es sich dabei um ein kaputtes Voicepack handeln, das der Rechner abschmiert wenn der FS versucht, ein bestimmtes callsign auszusprechen? Wobei der Fehler aber nicht unbedingt mit Sprachausgabe zusammen auftritt. Als AI-Traffic nutze ich Traffic 2005 mit sämtlichen Zusatzpaketen.

Wie erkenne ich die Ursache? Welchen Kriterien müssen Texturen entsprechen, damit sie so etwas verursachen?

Hm... ob der AI-Traffic das auslöst? Ich dachte, wenn dort ein Fehler auftritt, dann wird der entsprechende Flieger/Flugplan einfach ausgelassen.

Mesh und Landclass sind als Fehlerquelle auszuschließen? Oder sonst eine Zusatzszenerie, die eventuell genau in dieser Region ab einem Punkt geladen wird?

Laut Internet treten solche Fehler häufig durch fehlerhafte Texturen an AI-fliegern auf. Wie erkenne ich eine fehlerhafte Texturdatei?

Der Fehler tritt nur mit AI-Traffic auf und nur innerhalb des Korridors Kos-Mazedonien, dort befindet sich nur Standardszenerie (Ausnahme: Aerosoft Kos, aber die funktioniert ohne Probleme).

Muss ich jetzt etwa so lange Testflüge in der Region machen und per Radar alle potenziellen Übeltäter notieren? Und wenn ich potenzielle habe, wie überprüfe ich die Texturen?

ich würde sagen (Konjunktiv):
fehlerhaften (AI) Aircraft Texturen sind auszuschließen,
fehlerhafte oder fehlende LC- bzw. Scenery-Texturen sind nicht auszuschließen.

Da war doch auch mal etwas???

alle zusätzlichen Module abschalten???

Wie gesagt, im Netz ist man vielerorts der Meinung, dass es defekte Texturen ("corrupt textures") auf AI-Flugzeugen sein könnten - nur finde ich nirgends, wie man solche Texturen definiert.

Der Fehler tritt nur auf jenem Airway auf und nur mit AI-Traffic, das untermauert den Standpunkt für mich deutlich. Ich müsste also wissen, welche AI-Flüge zu dieser Zeit in jener Gegend mit welchen Flugzeugen unterwegs sind, und da würde ich jetzt mal ganz Laienhaft über TCAS und Funk alles notieren, was in der Gegend rumschwirrt. Das hatte ich auch schon getan, und es waren 4 Flugzeuge, deren Rufzeichen ich habe (nebst Uhrzeit und Datum). Aber wie testet man Texturen auf ihre Konformität?

Sonst läuft der FS saumäßig gut, stabil und ohne Macken, deswegen wird es wohl kein Modul sein, das immer geladen ist.

AddOn-Szenerien habe ich in dem Gebiet auch keine.

Wie konfiguriert man die Filtereinstellungen für Filemon optimal, um FS-Problemen auf die Schliche zu kommen?

Bin natürlich über jede Hilfestellung dankend erfreut :-)

...ich hab ja schon an anderen Stellen gepostet (siehe zB "zu wenig Arbeitsspeicher..."), daß es mit AI-Fliegern/Texturen (unabhängig von der AI-Dichte) offensichtlich ganz gemeine Probleme geben kann. Bei mir ist es defintiv so, nur leider ist's mir bei der Vielzahl der a/c (IVAO-MTL, PAI, WoAI, ARNZ...) bislang unmöglich gewesen, die Verursacher zu finden. Ich kann dich, Nick, aber soweit bestätigen, daß ich auch CTD's habe, die bei mir

a) ganz ausschließlich in Europa vorkommen ab 25% AI.
In USA habe ich auch Riesen-AI-Dichte allein durch UA, AAL, UPS, FDX, DAL, ACA + regionaler Traffic und VFR - aber noch nie einen CTD deswegen gehabt. FlyTampa-Airports kann ich zur Rush-Hour mit 100%-AI problemlos anfliegen (Anflug KSFO, in der Gegend lt. Traffic Explorer 123 aktive AI-Flugzeuge, fps: 14-20). Wenn's nicht eine fehlerhafte Textur ist, dann liegt's vielleicht nicht an der bloßen Anzahl der a/c, sondern an der Anzahl unterschiedlicher Liveries? Die ist bei mir auf europäischen Airports natürlich deutlich höher als in USA.

b) manchmal unmittelbar mit Beginn einer FS-ATC-Message.
Die Fehlermeldung gibt dann immer die ntdll.dll an, was eine viel zu allgemeine Angabe ist; hilft so nicht weiter.

Leider...
a) sagt 25%AI gar nichts aus (Viele Installer installieren AI mit 1%)
d.h. ein %-Filter z.B. in AITM bringt nichts, es sind (bei mir) immer noch zu viele a/c, die man untersuchen müsste
b) hört man die ATC-Msg nie lange genug um das Callsign mitzukriegen.
c) mittels TrafficExplorer (MAP-Funktion, also so ne Art Radar) ging bislang auch nicht, weil der Absturz so schnell geht, daß man nichts mehr entdecken kann. Auch filemon hilft hier nicht, weil bei mir darin nur Verweise auf dxdiag zu sehen sind (was meinen Verdacht hinsichtlich der Texturen bestätigt), nicht aber auf irgendeine a/c-file.

Das einzige, wessen ich mir sicher bin ist, daß die AI-bedingten Abstürze mit dem Aufspielen/Updating von Flightplans für Frühjahr/Sommer 07 begannen. Da kamen u.a. eine Menge neue a/c dazu (da ich auch vile neue Airlines aufgespielt habe) und ich habe - zum Ausmisten des aircraft-ordners - etliche PAI-Flugzg durch Flgzge aus der IVAO-MTL ersetzt.
In einem oder beiden Dingen muß bei mir die Ursache liegen.

Habe auch das ausgezeichnete Tool ACA2005 (Aircraft Analyzer, Peter van der Veen), das viele Errors im AI findet. Alle vorgenommenen Fixes waren aber bislang erfolglos.

Ich müsste jetzt aus der flightplan.bgl mittels AITM jede einzelne Airline extrahieren und als eigenen Flightplan abspeichern. Dann nach und nach aktivieren und sehen, wann der Fehler auftritt. Dies ist aber schlechterdings wenig hilfreich und eigentlich unmöglich, da man
a) nicht weiß, ob das fehlerhafte a/c zur aktuellen zeit am aktuellen ort gerade aktiv ist
b) sich bei "gefühlten" 200 airlines unweigerlich daran erinnert, daß es noch ein Leben neben dem FS gibt...


Macht nicht viel Mut, gelle? Man muß halt in Europa gaaanz vorsichtig fliegen (oder AI aus).

Mein Erholungsvorschlag: Tongass + Glacier Bay + Columbia River + Portland und mit der Beech18 ab in's Unterholz...

wolfgang

...fliege jetzt mal Kos-Mazedonien...

Wolfgang

Hier wäre der Flugplan Kos-Zagreb, mit dem das bei mit passiert: Abflug LGKO um 12.08, das Problem tritt etwa 70nm vor FSK auf. Achtung, GS490kts, FL430 (Citation).

...Wochentag Sonntag (wichtig, wenn du auch Traffic 2005 mit den AddOns verwendest)

Ich habe keinen wild zusammengebastelten AI-Traffic, eben ganz einfach aus dem Grund weil ich da zu blöd und zu faul zu bin. Ich nutze ausschließlich die enthaltenen Traffic 2005 Pläne und Flugzeuge (inklusive aller PlusPacks).

ich habe jetzt mal ein paar Livery-Updates von denen installiert, vielleicht bringt es ja was, teste das jetzt mal...

...problemlos...

wolfgang

Ich habe es soeben nochmal probiert und bin inzwischen fast schon amüsiert, was wohl auch daran liegt dass ich eigentlich nie in der Gegend zu tun habe und ganz froh bin, dass es nur dort passiert.

Während des Fluges habe ich auf einem Notebook FS Commander im Map-Modus laufen. Doch dazu später.

Ich bin also wieder an einem Sonntag, um kurz nach 12h GMT auf Kos gestartet, alles verläuft normal bis zum Einflug in die "Danger Zone" :D

Dann passiert wieder das gewohnte: Aussensicht wird schwarz, Panel bleibt sichtbar, Fehlermeldung fe.dll blablabla. Wenn ich dann per AL-TAB auf den Desktop wechsle und die Fehlermeldung und damit den FS NICHT schließe, sehe ich auf dem Notebook, wie das Flugzeug weiter seiner Route folgt. Hahre ich am Quadranten die Störklappen aus, so sehe ich auch auf dem Notebook eine Veringerung der Speed. Der FS läuft also tatsächlich weiter und reagiert auch auf Steuerimpulse.

Per ALT-TAB zurück in den Sim, und oh wunder (die Fehlermeldung ist noch immer offen) die komplette Sicht ist wieder da, eine ATC meldung auf dem Schirm, Buttons reagieren auf Mausklicks. Ein Wechsel in die Aussensicht gelingt aber nicht, nun wird alles schwarz, lediglich Textmeldungen (SPOT) (COCKPIT) etc. sowie die ATC-Meldung werden angezeigt.

Bestätige ich nun die Meldung, ist BAFF - alles wieder weg.

Der FS "fliegt" dennoch weiter, wie das Notebook verrät.

Was soll uns das jetzt sagen?

1) es liegt ein Fehler vor. :D

2) es kann doch nur etwas mit AI-Traffic zu tun haben?!
- ohne AI-Traffic kein Fehler
- eine bestimmte ATC-Meldung, aller Wahrscheinlichkeit nach ein AI-Callsign, lassen den FS das erste Mal wegknicken
- bestätigt man die Meldung später, wird ja wieder das ATC-Sprachausgaben-Modul aktiv (ich nenn das jetzt mal so), und ZACK, wieder alles weg.

Wäre es irgend etwas anderes (Szenerie, Gauge) würde doch der FS nicht "normal" weiterlaufen, oder? AI-Traffic ist so ziemlich das einzige, das den eigenen Flieger nicht direkt beeinflusst.

Naja, mal was anderes einem problem auf die Spur gehen zu wollen, weil es interessant ist und nicht weil es unbedingt stört. Nicht auszudenken, wenn das über Südwesteuropa oder Alaska passieren würde

:rolleyes:

Hat einer 'ne Idee?

...ja, ich: vielleicht ein defektes Voicepack?

Wie könnte man das beheben?

Ganz blöde Idee:

Ich hatte mal Probleme mit den sound-Dateien eines Fliegers. Ich habe einige neue Dateien in den Ordner kopiert, mit dem Ergebnis, dass sich der Flusi abmeldete. Diese Dateien ließen sich auch im wave_editor (wavelab lite von Steinberg) auch nicht öffnen. Anscheinend ist wav nicht gleich wav. Vielleicht liegt ja hier ein ähnlicher Fehler vor?

Gruß R.

Hi,

Wenn es sich um eine fehlerhafte Texturdatei handelt würde ich folgendermassen vorgehen:

• Überprüfen aller Airlines für den Zielflughafen. Also welche Airlines fliegen die Umgebung des 'Absturzortes" an. Dazu kann man am besten meiner Meinung nach ACA2005 benutzen
• Dann bei genau den Aircrafts mittels FS-Repaint (leider Payware aber schon ab 9,99 bei 1,2,3,meins zu haben) bei den Airlines die Texturen überprüfen
• Bei fehlerhafenten Texturen diese ersetzen (falls möglich) oder mal temporär ganz löschen bzw umbenenen und nochmal testen.
• Alternative 1: alle(n) Traffic (bgl´s umbennen) rausschmeissen und nochmal den Absturzort anfliegen.
• Alternative 2: ich kann Dir mal meinen händisch generierten Traffic senden.

ACA2005 stürzt bei mir immer ab, wenn ich die Flugplanfunktion aufrufe (siehe anderer Thread zur Software)

FS-Repaint habe ich sogar, wie überprüfe ich damit denn Texturen?

Hallo holu,

Punkt 1 ist so nicht richtig: Falls ein a/c stört, ist es nicht allein maßgebend, daß es einen Flughafen in der Nähe des "Absturzortes" anfliegt. Es muß zur fraglichen Zeit in der eigenen Flugumgebung aktiv (sleep eingeschlossen) sein. Bezogen auf Meatwater heißt das, es kann ein AI-a/c sein, daß von Kairo nach London fliegt (nehmen wir mal an, das Routing geht über Mazedonien/FISKA).

Sowas findest du mit ACA nicht raus. Alle aktuell aktiven a/c während des Fluges findet man nur mit einem tool wie TrafficToolbox.

Da aber der FS im Moment des Aufrufs des fehlerhaften a/c abnippelt, hast du auch so keine Chance es zu erwischen.

Bevor hier eine Behauptung zum Selbstläufer wird, bleibt festzuhalten:

1. Ob ein fehlerhaftes a/c überhaupt ursächlich für das Problem ist, wissen wir immer noch nicht. Ich vermute es zwar auch, aber bewiesen ist's noch nicht.

2. Wenn dem aber so sein sollte, müßte man wissen,
- welche Art von Textur den FS killt oder
- welche Anzahl aktiver und verschiedener Texturen vielleicht zum Problem führen
-was eine fehlerhafte Textur ausmacht
- ob es vielleicht zwar am AI-a/c, aber nicht an der Textur, sondern an etwas anderem liegt. Was weiß ich: air-file, mdl-file, falsche sounddatei, irgendwelche effect-Einstellungen. Gefühlte 10K-Möglichkeiten...

Also Nick: Die Mühe, den landing/departing-Traffic in der Umgebung von FISKA abzusuchen, kannst du dir IMHO sparen.

Falls du Traffic Toolbox nicht hast, gucksdu hier:

Microsoft have a tool called Traffic Toolbox for FS9. This is a Software Development Kit used for develpoping the way AI traffic works but it has a useful tool called Explorer included with it, this allows you to see a list of ALL AI traffic that is in the area around your aircraft, also by clicking on an aircraft in the list you can see an external view of it.

This a a very useful tool for seeing what is happening to your AI traffic, in real time.

You will find it here http://www.microsoft.com/games/fligh...dk.asp#traffic

To install, run the install.exe file and then copy the TrafficToolbox.dll into your Flight Simulator\MODULES folder.

The next time you run FS9 you will see an extra item on your toolbar, TOOLS, click this then select EXPLORER this will open a new window with a list of ALL AI aircraft in you area.


a3g
wolfgang

@Nick
Frage: Wann genau bricht ACA ab?
Wenn du auf den Button "Flightplans, Timetable..." klickst oder wenn du danach im rechten Fenster eine bgl aufrufen willst?

Und meine Frage aus dem anderen thread nochmal:
Wenn du einen fp mit TTools.exe direkt kompilierst, kriegst du dann eine Fehlermeldung? Wenn ja, welche?


a3g
wolfgang

ACA bricht in dem Moment ab, in dem ich auf "Flightplans..." klicke.

TrafficToolbox habe ich

Wenn ich direkt kompiliere muss ich einen fehlerhaften Flugplan aus 150 erwischen, was mir noch nicht gelungen ist. Direktes kompilieren funktioniert soweit, ist aber nicht Sinn der Sache

...also ich gehe dann davon aus, daß du bei 150 Flugplänen auch evtl. 150 bgl's hast? Könnte das für ACA zuviel sein? Schmeiß doch mal 140 raus, sodaß ACA nur ein paar bgl finden muß...

wolfgang

Nein. 150 txt Dateien aus denen erst durch TTools eine (1) bgl wird

...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

@MeatWater
Sag mal: Funktioniert ACA2005 jetzt bei Dir? Mich würde da nämlich mal ein Vergleich zwischen meinem händisch erstellten Traffic und Deinem Payware Traffic interessieren.

Nö, tut's nicht, gleiche Fehlermeldung.

Guten Tag,

also der deaktivierte AI-Traffic brachte bei mir nichts.

Scheinbar erfolgreich war aber das Abschalten von Online-Updates bei ActiveSky 6.5. Allerdings müßte ich das noch mehr testen.

Bliebe dann die Frage, was bei ActiveSky 6.5 "kaputt" sein könnte; lief in der Vergangenheit sonst völlig problemlos.

Gruß

Arndt