Personenzug 523 (LzSuO)

    • Offizieller Beitrag

    Hallo Norbert,


    das freut mich sehr, wenn es Dir gefallen hat.

    Und danke für die Bilder - klasse! :love:

    "Stimmiger KI-Verkehr" - Gut ich gebe zu, daß ich bei manchem Fahrzeug ein Auge zugedrückt habe.

    Die Hardcore-Kenner der Bahngeschichte werden mich hier überführen.

    Aber ich habe mir gedacht: "Schade um manches schöne Repaint, was die fleißigen Kollegen für uns erstellt haben und was vielleicht nie in einer Aufgabe eingesetzt wird."


    Grüße Cris

  • Hallo Cris,

    vielen Dank für diese kurzweilige Aufgabe! Ich bin nun endlich auch virtuell mit der P8 in Richtung Pasewalk gereist. In den 2 1/2 Stunden ist wahrlich keine Langeweile aufgekommen, gab es doch immer wieder Rangier- sowie Durchfahrten zu beobachten - insgesamt sehr atmosphärisch gestaltet. Kurzum: So wird der Begriff "Simulation" mit Leben erfüllt!


    Gruß EGZ

  • Lieber Cris, liebe 523-Fahrer!


    Bis kurz vor dem Bahnsteig in Angermünde kann ich die voranstehenden Aussagen nur bestätigen und unterstreichen.

    Wieso nur bis da?

    Ich bin die Aufgabe mit der Version ORNYMG 147 gefahren und erhalte leider an der angegebenen Stelle folgende Meldung mit integriertem Absturz der Aufgabe:


    Error: System.ArgumentException: Illegales Zeichen im Pfad.

    bei System.IO.Path.CheckInvalidPathChars(String path, Boolean checkAdditional)

    bei System.IO.Path.Combine(String path1, String path2)

    bei Orts.Common.ORTSPaths.GetFileFromFolders(String[] pathArray, String branch) in F:\ADRIANA\Carlo\OR_Work\Git_ORTS_source_mio\Source\Orts.Simulation\Common\ORTSPaths.cs:Zeile 63.

    bei Orts.Viewer3D.ORTSSoundPlayCommand.GetNextFile() in F:\ADRIANA\Carlo\OR_Work\Git_ORTS_source_mio\Source\RunActivity\Viewer3D\Sound.cs:Zeile 2361.

    bei Orts.Viewer3D.ORTSStartLoopRelease.Run() in F:\ADRIANA\Carlo\OR_Work\Git_ORTS_source_mio\Source\RunActivity\Viewer3D\Sound.cs:Zeile 2120.

    bei Orts.Viewer3D.SoundSource.InitInitials() in F:\ADRIANA\Carlo\OR_Work\Git_ORTS_source_mio\Source\RunActivity\Viewer3D\Sound.cs:Zeile 938.

    bei Orts.Viewer3D.SoundSource.Update() in F:\ADRIANA\Carlo\OR_Work\Git_ORTS_source_mio\Source\RunActivity\Viewer3D\Sound.cs:Zeile 952.

    bei Orts.Viewer3D.Processes.SoundProcess.Sound() in F:\ADRIANA\Carlo\OR_Work\Git_ORTS_source_mio\Source\RunActivity\Viewer3D\Processes\SoundProcess.cs:Zeile 185.

    bei Orts.Viewer3D.Processes.SoundProcess.DoSound() in F:\ADRIANA\Carlo\OR_Work\Git_ORTS_source_mio\Source\RunActivity\Viewer3D\Processes\SoundProcess.cs:Zeile 116.


    Information: Game.PopState()


    Mit welcher Openrails-Version seid ihr denn gefahren? Ich werde die dann mal ausprobieren.


    Eine angenehme Woche wünscht


    Meinhard

  • Guten Abend miteinander!


    Nö, mit der Version 1.5.1 kommt dasselbe Problem.

    Es liegt wohl daran, dass die Aufgabe für die LzSuO-Version mit tdb = 4240 gebaut ist, meine Strecke aber nur tdb = 3566 ist.

    Ich habe leider keinen blassen Schimmer, mit welchem Update die 4240 installiert wird.


    Eine gute Nacht wünscht


    Meinhard


  • Guten Abend Meinhard,


    diese Info mit der TDB Nummer macht mich etwas stutzig, hast du die Updates vom Hersteller bei deiner Strecke eingepflegt?


    https://www.halycon.de/downloads/eurotrainsim---legenden-zwischen-spree-und-oder---addon-fuer-ms-train-simulator/legenden-zwischen-spree-und-oder---saemtliche-updates/103.html


    Grüße und einen schönen Abend dir


    DR Hennes

  • Liebe Füchse!


    Ich habe mir dann mal den Spielerpfad im PATH-Ordner angeschaut, ob ich da sowas wie ein illegales Zeichen finde.

    Da stand ganz am Ende Folgendes:


    TrPathNode ( 00000000 4294967295 4294967295 89 ) [Das ist die viertletzte Zeile im Spielerpfad] [Hervorhebung von mir]

    TrPathNode ( 79ef0002 56 4294967295 90 )

    TrPathNode ( 7a150002 73 4294967295 91 )

    TrPathNode ( 7a660002 91 4294967295 92 )

    )

    )

    Dieser Eintrag erscheint mir fragwürdig, weil er sich von allen anderen Zeilen deutlich unterscheidet.

    Wie sollte das denn korrekt aussehen?

    Ich habe mal den Versuch einer Änderung gestartet:


    TrPathNode ( 00000000 96 4294967295 89 ) [Die 96 deshalb, weil in der Zeile davor 95 steht]

    TrPathNode ( 79ef0002 56 4294967295 90 )

    TrPathNode ( 7a150002 73 4294967295 91 )

    TrPathNode ( 7a660002 91 4294967295 92 )

    )

    )


    Allerdings muss ich noch prüfen, in welchen anderen KI-Pfaden ich diese Änderung auch vornehmen muss, denn ohne diese Prüfung lädt OpenRails die Aufgabe nicht.


    Habt ihr eventuell andere Tipps für mich?


    Einen - trotz dieser Anfrage - angenehmen Abend wünscht


    Meinhard

  • Noch mal einen guten späteren Abend, liebe Füchse!


    Nein, das kann es doch nicht gewesen sein, denn die viertletzte Zeile taucht in allen Pfaden, auch anderer Strecken auf.

    Da muss ich versuchen, den Fehler anderweitig zu finden.


    Gute Nacht wünscht


    Meinhard

  • Hallo Meinhard,

    nur ein paar unfertige Gedanken meinerseits…


    Wenn es Zweifel an den Pfaden gibt (ich glaube allerdings eher nicht daran! Eine abweichende Version der Schienendatenbank muss nicht zwingend aus einer Änderung der Gleisverlaufs resultieren - es reicht schon das Markieren eines Gleises und ein anschließendes Speichern im MSTS-Streckeneditor…), dann könnte es vielleicht helfen im OpenRails-Startfenster unter Werkzeuge den Open Rails Track Viewer aufzurufen, darin Strecke und Aufgabe einzuladen und dann unter Path Editor die Funktion Auto-fix all broken paths auszuführen. Zumindest könnte man dem Ergebnisfenster entnehmen, ob überhaupt ein Pfad vom Programm als fehlerhaft identifiziert wurde, so jedenfalls meine Annahme. Definitiv sollte vorher vom Pfad-Ordner ein Backup angelegt werden.


    Ich würde - wiederum nach entsprechenden Backup - einmal schauen, ob für den Fehler einer der eingebunden Verkehrszüge verantwortlich ist. In der Aufgabe den gesamten Absatz Traffic_Definition entfernen und die dazugehörige .trf-Datei umbenennen. Sollte die Aufgabe so funktionieren, wird es zeitaufwändig, den verursachenden Zug zu finden - dann würde ich durch Herauslösen einer Teilmenge des Traffics jeweils feststellen, ob der Störenfried im noch eingebundenen reduzierten Verkehr enthalten ist.


    Grundsätzlich würde ich auf einen Zusammenhang zu irgendeinem Fahrzeug in Deiner Installation tippen, denn die Aufgabe selbst ist allgemein lauffähig (wen wundert es? - wird doch nicht ungetestet online gestellt! … ;) ) und die Strecke war sicherlich auch bei Dir bisher unauffällig und lauffähig.


    Aber möglicherweise liege ich auch völlig falsch - denn: Grau ist alle Theorie!


    Viel Erfolg wünscht Dir

    EGZ

  • Guten Abend, lieber Ralph!


    Danke für Deine Gedanken.

    In den Track Viewer habe ich schon hineingeschaut, aber noch nicht die "broken path" Funktion aufgerufen.

    Ja, die Strecke ist - immer noch - funktionsfähig, nur beim 523 bricht die Aufgabe gaaanz kurz vor Erreichen des Bahnsteigs in Angermünde ab, und zwar wegen eines "illegalen Zeichens" im Pfad (was immer das sein mag.)


    Ich werde da mal geduldig dran bleiben und hoffe, eine Lösung zu finden. Das Problem muss irgendwo in meinem System versteckt sein, da ja andere Trainsimmer die Aufgabe erfolgreich abschließen konnten.


    Einen schönen, entspannten Abend wünscht


    Meinhard

  • Hallo Meinhard,

    noch eine kleine Anmerkung meinerseits: Du beziehst Dich sicherlich auf die Meldezeile:


    Error: System.ArgumentException: Illegales Zeichen im Pfad.


    Ich würde das nicht auf einen Pfad eines Zugverbandes beziehen - ich würde es als eine unzulässige Pfadangabe im Dateisystem interpretieren. Also beispielsweise eine fehlerhafte Syntax eines Cabview- oder Soundpfades in einer Fahrzeugdatei, die nicht zulässige Zeichen enthält.


    Wenig später heißt es dann auch:


    bei Orts.Common.ORTSPaths.GetFileFromFolders(String[] pathArray, String branch) in …


    Gruß EGZ



  • Hallo und guten späteren Abend, lieber Ralph!


    Ja, Wörter können verschiedene Bedeutungen haben, Du könntest recht haben, dass sich das nämlich auf einen fehlerhaften DATEIPFAD bezieht.

    Auf die Idee bin ich gar nicht gekommen.

    Das ist aber insofern plausibel, da ja andere die Aufgabe beenden konnten.

    Da werde ich beim Suchen sicherlich einige Zeit benötigen.


    Ein ruhiges Wochenende wünscht


    Meinhard

    • Offizieller Beitrag

    Guten Morgen,


    häufig lese ich, wie pflegeleicht der OR sei und was er alles toleriere.

    Das stimmt aber nur zum Teil.

    Bei Streckensoundfehlern ist der OR eine totale Mimose und stürzt gern und häufig ab.

    Gerade bei dieser Strecke und bei der Oberlausitzbahn ist mir das passiert.

    meinhard , arbeite doch mal in der Logdatei alle Punkte, die den Sound betreffen, ab.


    Grüße Cris

  • Hallo und guten Tag, lieber Cris!


    Ich werde Deinem Rat folgen und mal sehen, was er (LogFile) so (Strecken)soundmäßig bemängelt. Bei Fahrzeugsounds bin ich schon fleißig dabei.


    Bis später, liebe Grüße


    Meinhard

  • Guten Morgen, liebe Füchse!


    Habe für verschiedene Aufgabe auf der Strecke die LogFiles studiert und keine Warnungen/Hinweise zu fehlendem Streckensound gefunden. Diejenigen zu Fahrzeugsounds habe ich "abgearbeitet."

    Allerdings sind andere Warnungen vorhanden, mit denen ich leider nicht viel anfangen kann, wie z.B:


    Warning: Signal referenced in .w file -5572 14981 as TrItem 1733 not present in .tdb file



    Warning: Expected 1 geometry node map elements; got 2 in sub-object 0 in distance level 0 in shape f:\msts\routes\lzsuo 4240\shapes\barkasb1000.s



    Warning: w-005543+015005.w scenery object 74 with StaticFlags 00030DF4 references non-existent F:\MSTS\routes\LzSuO\shapes\DynaTrax-1003.s


    Run AI : 128 Warning: Train 0 service PLAYER, reversal or end point off path; reversal point considered remote


    Warning: Missing UV index in vertex 0 in sub-object 0 in distance level 0 in shape f:\msts\trains\trainset\bd_blind\bd_blind.s



    Vielleicht (eher bestimmt) sind unter euch OpenRails-Spezialisten, die mir zu den obigen Warnungen Tipps geben können.


    Mit bestem Dank im Voraus wünsche ich euch einen schönen Sonntag.


    Liebe Grüße


    Meinhard

    • Offizieller Beitrag

    Guten Morgen Meinhard,


    also eins vorab: ich bin OR-Nutzer, aber kein OR-Spezialist.

    Ich schreibe aber trotzdem etwas dazu. ;)


    Was er da zu gurgeln hat mit dem Barkas, einfach prüfen, ob das Shape vorhanden ist - wenn nicht, ergänzen.

    Dasselbe mit dem DynaTrax-Shape.

    Das Mecker bezüglich des Blindzugs erzeugt bei mir ein Lächeln.

    Diesen verwende ich schon ewig gehäuft in jeder Aufgabe.

    Ich weiß nicht, was dort ausgerechnet bei Dir zum Absturz führen soll.


    Tut mir leid, daß ich nicht mehr beitragen kann.

    Grüße Cris

  • Guten Morgen Meinhard,



    Das "Warning: w-005543+015005.w scenery object 74 with StaticFlags 00030DF4 references non-existent F:\MSTS\routes\LzSuO\shapes\DynaTrax-1003.s" ist Dein Problem.

    Du solltest die Dateien DynaTrax-1003.s und .sd auf Deiner Platte suchen und in den angegebenen Pfad einfügen.


    Wenn das erfolgt ist, sollte sich der nächste Fehler "Run AI..." dann auch in Luft auflösen und die Aufgabe sauber laufen.


    Der fehlende UV-Index und die ersten beiden Fehlermeldungen sind nach meinen Erfahrungen nicht besonders kritisch.


    VG

    Frank

  • Moinsen zusammen!


    Hallo, lieber Cris und lieber Frank!


    Beim Barkas muss ich noch schauen, habe ich übersehen.


    Alle Dynatrax s und sd sind da. Muss ich da etwas in den angegebenen world-Dateien ändern?

    By the way: Die Warnung bezüglich der dynatrax-Geschichten taucht im LogFile sind zahlreich, allerdings mit anderen world-files, anderen scenery objects und anderen Dynatrax-Nummern. Die StaticFlags 00030DF4 sind jedoch in allen Fällen identisch.


    Dass der Blindzug Ärger macht, glaube ich auch nicht. Ich habe nur mal die Meldung mit eingestellt.


    Lasst euch das Mittagessen scchmecken!


    Liebe Grüße


    Meinhard

  • Hallo Meinhard,

    ich halte es genauso wie Cris: OR-Spezialist mitnichten… - insofern alle Aussagen "ohne Gewähr" :)


    Die im log-File vorhandenen "Warnungen" sollten auch nur als Warnungen zu verstehen sein, also nicht absturzrelevant sein! So sind irgendwelche fehlerhaften Parameter in den shapes nicht spielentscheidend und können im Maximalfall die Nichtdarstellung eines Objekts zur Folge haben. Meiner Meinung nach führt das Fehlen eines statischen Dynatrax-Gleises lediglich zu einer optischen Lücke im Gleisbild - die Fahrtroute der Züge bezieht sich auf die Schienendatenbank und führt ggf. auch "über Stock und Stein". Im konkreten Fall stimmen möglicherweise die Pfadangaben in den .w-Dateien nicht… Vielleicht ist auch das StaticFlag nicht zutreffend. Bei mir sehen solche Einträge folgendermaßen aus:


    FileName ( "..\\..\\routes\\LzSuO\\shapes\\DynaTrax-277.s" )

    StaticFlags ( 00200180 )


    Wie gesagt, ich halte das alles nicht unbedingt für ursächlich - konkret hattest Du einen "Crash", also einen von OR unvorhergesehenen Absturz: Ich rechne nicht damit, dass dazu im log-File eine "Vorankündigung" zu finden ist, sonst hätte OR wohl eine ordnungsgemäße Programmbeendigung realisiert. Vergleichen würde ich das Ganze bspw. mit einer Division durch Null, in diesem Fall deutet aber alles auf ein unzulässiges Zeichen für eine Dateioperation. Beim Absturz tauchte öfter der Begriff "Sound" auf. Insofern wäre das unverändert meine Forschungsrichtung: Entweder der von Cris erwähnte Streckensound (dann dürften Abstürze an jenem Ort auch mit anderen Aufgaben erfolgen) oder Fahrzeugsound (dann müssten zur Analyse Zugverbände temporär deaktiviert werden).


    Die erwähnte Fehlertoleranz des OR dürfte weniger eine beabsichtigte Logik sein als aus den Eigenschaften der verwendeten Programmiersprache bzw. des Compilers resultieren. Immerhin gibt es 100% mehr Fehlerprotokoll als im MSTS … :)


    Gruß EGZ

  • Hallo, lieber Ralph!


    Nochmals Danke für Deine Ausführungen.

    In "meinem" worldfile w-005543+015005.w ist für dynatrax-1003 (ich habe vorerst nur diesen File angeschaut) ebenfalls StaticFlags ( 00200180 ) angegeben. Da nehme ich nun an, dass bei mir die entsprechenden Shape-files nicht in Ordnung sind.


    Wo finde ich denn in den s-files die Angabe(n) über die StaticFlags, damit ich vergleichen und ggf. ändern kann?


    Liebe Grüße


    Meinhard

  • Hallo Meinhard,

    das StaticFlag findet m. W. nur in den .w-Dateien Verwendung. U. a. erfolgt damit eine automatische Adressierung von Unterverzeichnissen: So werden Gleisstücke mit dem hier genannten Code eigentlich im Unterordner SHAPES des GLOBAL-Verzeichnisses gesucht. Deshalb sind auch die längeren Pfadzeilen für die Dynatrax-Shapes erforderlich…


    Mit dem genannten StaticFlag ist alles in Ordnung: Der gemeldete Wert 00030DF4 ist der Hexadezimalwert von 00200180… Die Angabe dieses Werts in der Warnmeldung hat also nur informativen Charakter, ebenso wie die Angabe scenery object 74, die der UiD des Eintrags in der .w-Datei entspricht. Entscheidend ist das non-existent F:\MSTS\routes\LzSuO\shapes\DynaTrax-1003.s - OR findet die Datei nicht!


    Aber wie bereits im vorangegangenen Beitrag erwähnt, vermute ich eine andere Fehlerursache…


    Zum Vergleich mein kompletter Eintrag:


    TrackObj (

    UiD ( 74 )

    SectionIdx ( 1003 )

    Elevation ( 0 )

    CollideFlags ( 551 )

    FileName ( "..\\..\\routes\\LzSuO\\shapes\\DynaTrax-1003.s" )

    StaticFlags ( 00200180 )

    Position ( -196.43 9.4669 -745.801 )

    QDirection ( 0 0.619329 0 0.785132 )

    VDbId ( 4294967294 )

    )


    Gruß EGZ

  • Lieber Ralph, lieber Cris, liebe andere Mitdenker!


    Ich rutsche zutiefst gebeugt vor euch auf den Knien, Vergebung und Verzeihung erbettelnd, weil ich euch so auf Trab gehalten habe.

    Schluchz, wein, händering.

    Ich hätte erstens ja auch mal über das Zahlenformat nachdenken können, aber, ob ich auf die Idee gekommen wäre, die Hexadezimalangabe in eine Dezimalangabe umzurechen, ist fraglich. Ja, ja, die Mathemagie!

    Ich hätte zweitens die "non-existent"-Meldung genauer interpretieren MÜSSEN. Dann wäre mir aufgefallen, warum OR die Dateien nicht findet: Ich hatte hinter den Ordnernamen LzSuO zur Unterscheidung der verschiedenen Versionen noch als Zusatz die Version angegeben. Das wird mir sicher nicht wieder passieren.

    Ich werde bei passender Gelegenheit den 523er nochmal fahren und schauen, ob mir OR wieder am Bahnsteiganfang von Angermünde abschmiert.

    Melde mich dann wieder zu diesem Thema.


    Einen schönen Abend bzw. eine gute Nacht wünscht


    Meinhard

  • Guten Abend, liebe Problemlösungsbeiträger, guten Abend, liebe Füchse!


    In Kurzform: Fehlerhaften Service gefunden und das Geschehen im Bahnhof Angermünde endlich gebührend bewundert und genossen.


    Wie schön, dass man in OR den Automatikmodus und die Zeitrafferfunktion hat!


    Ich habe nach und nach Services päckchenweise aus der Aufgabe genommen und bin dann die Aufgabe viele Male gefahren.

    Dabei habe ich den Übeltäter, der sich in meinem System herumtreibt, ausmachen können: Es ist der "523 Lz ab BwAng," der mich zankt (andere lässt er ja in Ruhe.) Der zugehörige Consist 50 3116.con bereitet keine Probleme, der OR-LogFile hat sich dazu ja auch nicht geäußert.


    Es scheint dann doch ein illegales Zeichen in der Path-Datei zu sein, nachstehend der Inhalt von 523 Lz ab BwAng.pat.


    Serial ( 2 )

    TrackPDPs (

    TrackPDP ( -5552 15002 -604.413 1.25751 665.578 1 1 )

    TrackPDP ( -5552 15002 -612.256 1.25751 581.724 2 0 )

    TrackPDP ( -5552 15002 -616.559 1.2575 551.93 2 0 )

    TrackPDP ( -5552 15002 -626.829 1.25751 447.325 2 0 )

    TrackPDP ( -5552 15002 -623.274 1.25751 417.432 2 0 )

    TrackPDP ( -5552 15002 -622.874 1.25751 415.473 2 0 )

    TrackPDP ( -5552 15002 -606.335 1.25751 334.404 2 0 )

    TrackPDP ( -5552 15002 -605.935 1.25751 332.444 2 0 )

    TrackPDP ( -5552 15002 -605.571 1.25751 646.473 1 1 )

    TrackPDP ( -5552 15002 -590.156 1.25751 284.944 2 0 )

    TrackPDP ( -5552 15002 -563.263 1.25751 231.078 2 0 )

    TrackPDP ( -5552 15002 -548.582 1.25751 193.869 2 0 )

    TrackPDP ( -5552 15002 -535.253 1.25751 166.878 2 0 )

    TrackPDP ( -5552 15002 -360.35 1.25751 -681.539 1 1 )

    TrackPDP ( -5552 15002 -358.668 1.25751 -636.658 1 1 )

    )

    TrackPath (

    TrPathName ( "523 Lz ab BwAng" )

    TrPathFlags ( 00000020 )

    Name ( "523 Lz ab BwAng" )

    TrPathStart ( BwAng )

    TrPathEnd ( Ang )

    TrPathNodes ( 15

    TrPathNode ( 00000000 8 4294967295 0 )

    TrPathNode ( 00000000 2 4294967295 1 )

    TrPathNode ( 00000000 3 4294967295 2 )

    TrPathNode ( 00000000 4 4294967295 3 )

    TrPathNode ( 00000000 5 4294967295 4 )

    TrPathNode ( 00000000 6 4294967295 5 )

    TrPathNode ( 00000000 7 4294967295 6 )

    TrPathNode ( 00000000 9 4294967295 7 )

    TrPathNode ( 00dc0002 1 4294967295 8 )

    TrPathNode ( 00000000 10 4294967295 9 )

    TrPathNode ( 00000000 11 4294967295 10 )

    TrPathNode ( 00000000 12 4294967295 11 )

    TrPathNode ( 00000000 14 4294967295 12 )

    TrPathNode ( 00000000 4294967295 4294967295 13 )

    TrPathNode ( 02580002 13 4294967295 14 )

    )

    )


    Ich habe die Zeile hervorgehoben, die mir problematisch erscheint [ der Dezimalwert der ersten Zahl beträgt 14417922].

    Allerdings habe ich keine Ahnung, welch anderer Wert dorthin gehört, falls die hervorgehobene Angabe tatsächlich falsch ist.


    Hätte da jemand einen Hinweis für mich/uns? Danke im Voraus.


    Einen entspannten Abend mit einem leckeren Getränk wünscht


    Meinhard

  • Hallo Meinhard,

    ich versuche mich an einer (Teil-)Interpretation der markierten Zeile:


    00dc0002 ist hälftig (IT-chinesisch: in zwei Halbwörtern) zu lesen: Die letzten vier Stellen sagen etwas über den Typ des Eintrags aus:

    • 0000 = Start- oder Endpunkt des Abschnitts
    • 0001 = Wendepunkt
    • 0002 = Wartepunkt

    Die ersten vier Stellen geben beim Wartepunkt die Wartezeit in Sekunden als Hexadezimalwert an.


    Die markierte Zeile beschreibt einen Wartepunkt mit einer Wartezeit von 220 Sekunden.


    So jedenfalls mein spärliches Wissen dazu. Die Zeile scheint mir unkritisch zu sein.


    Gruß EGZ


    P.S.: Inhaltlich stimmen alle von Dir genannten mit meinen vorhandenen Einträgen überein - alles andere hätte mich auch verwundert… Die .con-Datei selbst ist sicherlich nicht entscheidend - interessanter können die Dateiverweise in der .eng-Datei (Achtung: zur Aufgabe wird eine gesonderte OR-Variante mitgeliefert!) und die .wag-Datei ein. Und von dort aus sind dann auch noch die Inhalte der .sms-Dateien prüfungsrelevant, da diese wiederum die .wav-Dateien aufrufen. Einfacher wäre es wohl eine der anderen (funktionierenden) BR50-Loks in die .con-Datei einzutragen: Stürzt die Aufgabe erneut ab, dann liegt es nicht an der .con-Datei.

    Einmal editiert, zuletzt von EGZ ()

  • Guten Abend, lieber Ralph!


    Danke für diese Informationen!

    Da habe ich wieder ein wenig hinzugelernt. Nach Deiner Erklärung ist die Zeile wohl tatsächlich unkritisch.


    Könnte jemand, der Die Aufgabe erfolgreich absolviert hat, einmal nachschauen, wie die 523 Lz ab BwAng.pat bei ihm aussieht und das Ergebnis des Vergleiches mitteilen?

    Danke!


    Gute Nacht wünscht


    Meinhard