Signalprobleme auf Münster Bremen

    Hallo zusammen,


    ich arbeite derzeit an einem Szenario für den ICE 4 von 3DZug, jedoch habe ich einige Probleme mit dem Dispatcher.


    Im genaueren handelt es sich um die Signale:


    - N3 des Bahnhof Lengerich
    -1A des Bahnhof Hoerne
    -N3 des Bahnhof Hoerne


    @bahnjan Könntest du vielleicht mal gucken?


    Bei der "Signalstörung" im Bahnhof Lengerich kann ich mir noch damit helfen den Zug außerplanmäßig über Gleis 2 fahren zu lassen.
    Diese Trickserei zeigt aber bei den anderen beiden Signalen keine Wirkung.


    Ich habe mehrfach überprüft ob der Fahrweg frei ist, sowie ob alle Weichen richtig liegen oder ob ein Signal nicht auf Sh1 steht, und tatsächlich geht bei der Fahrstraße des Signales 1A das Sperrsignal W3I nicht auf Sh1.
    Ein Sh1 Trigger brachte hier jedoch keinen Erfolg, jetzt sagt das Signal bei TAB zwar das ich eine Zustimmung habe am Signal vorbeizufahren, zeigt aber das Zs7 nicht mehr.


    Jetzt gibt es ja diesen Opt-Trigger, kann ich damit ein Hp1 und einen deaktivierten 2000 Hz Magneten erzwingen?


    Hoffe ihr könnt mir bei diesem Problem ein bisschen weiterhelfen.


    Mfg.
    Trainsa

    Moin,


    die Signale kenne ich gut, die sind hundertmal geprüft worden, weil JTG dortähnliche Probleme hatte. Das Originalszenario ICE nach Bremen läuft inLen auch überGleis 2... Fragen: Hast du schon KI-Züge gesetzt? Welche Zugart hat dein Spielerzug?


    Ich habe im Januar ein Szenariopaket angefangen, dass wegen der S25 wie Blei auf der Platte liegt. Da ist auch eine ICE-Fahrt nach Bremen dirn und ich komme anstandslos in Lengerich und Hoerne durch.


    Winke, Jan

    Die Signale sind meiner Meinung nach nicht das Problem hier. Die funktionierten alle einwandfrei und Einbaufehler sind nach x-maliger Prüfung nicht auszumachen. Ich tippe auf folgendes: seit dem TS2019 gibt der Dispatcher sporadisch nicht immer die besetzen Blöcke frei, wenn ein Zug dort rausgefahren ist. Ist nur eine Vermutung, aber die einzig logische Erklärung für das Verhalten. Daran können wir aber nun mal nichts ändern. Und DTG wird daran wohl nichts ändern, das wissen wir ja. Also müssen wir mit der Kagga halt leben.

    Hallo @bahnjan


    Okay, komisch. Ja, KI-Züge sind schon alle vorhanden, habe aber auch jeden einzelnen KI Zug auf Fahrweg überprüft, er lässt mich auch nach TAB in den Block ein. Der Spielerzug hat die Priorität "Fernzug". Könnte Sonderzug Abhilfe schaffen?


    @Maik Goltz Ja, der Dispatcher ist mit der 64bit echt interessant geworden. Was mich verwundert ist das vorher in dem Bereich kein Zug gewesen ist, daher verwundert es mich warum der Block als belegt anerkannt wird.


    Wäre die Idee mit dem Opt-Trigger denn eine Sache? Ich habe mit Hp0, Zs1 und TAB-Trigger oft gearbeitet aber noch nicht mit dem Opt Trigger.


    Vielen Dank aber schonmal für eure beiden Ideen. :)

    Schon einmal vorbei geschaut? Mein Channel!

    Baureihen: 110, 111, 146.0, 146.1-2, 147, 420, 422, 423, 424, 425, 426, 426.1, 427, 440, 442, 1440, Flirt 3XL

    Wer weis was der Dispatcher da macht. Man kennt den code dahinter ja nicht. Eventuell befreit er alle Blöcke bei der Initialisierung erst und vergisst halt dabei ein paar neuerdings. Test wäre, einen KI Zug reinschicken und rausfahren lassen bevor der Spielerzug einfährt. Möglich, dass der Block dann endlich freigegeben wird.


    Zu den Opt-Triggern kann ich nichts sagen. Da muss Schuster sagen ob das dieses Problem lösen würde. Ich denke eher nicht. Belegter Block ist belegter Block.

    @Maik Goltz


    Danke! Der Block wurde durch den KI Zug freigefahren und stellt sich danach für den Spielerzug ohne Probleme.


    Ob es jetzt das ist oder die Änderung von "Fernzug" auf "International" oder ein Zusammenspiel beider Sachen war, auf alle Fälle vielen Dank @bahnjan und @Maik Goltz.

    Schon einmal vorbei geschaut? Mein Channel!

    Baureihen: 110, 111, 146.0, 146.1-2, 147, 420, 422, 423, 424, 425, 426, 426.1, 427, 440, 442, 1440, Flirt 3XL

    Morgens


    Nachdem ich erst kürzlich etwas mehr Zeit auf der Strecke verbringe (Version 1.1):
    Habe das "Problem", dass bei Fahrtauswertungen zu Szenarios das Überfahren von Halt zeigenden Signalen gemeldet wird, obwohl ich keine Halt zeigenden Signale überfahren habe.


    Nachdem ich das Problem das zweite Mal hatte, habe ich die Einstellung "Fahrtabbruch beim Überfahren von Halt zeigenden Signalen" eingestellt. Aus der Fahrt geflogen bin ich dann, als ich in einem Überholgleis bei der Einfahrt ein Halt zeigendes Signal überfahren habe, welches mit dem Rücken zu meiner Fahrrichtung stand und somit für mich eigentlich keine Bedeutung haben sollte.


    Passiert ist mir das mittlerweile bei einem mit der Strecke mitgelieferten Szenario (Der Lokzug) und bei mehreren Payware-Szenarios von 3D ZUG.


    Die Gefilde von Scripten, Strecken- und anspruchsvollem Szenariobau sind nicht so mein Ding. Falls ein Profi eine Antwort hat, schon mal vielen Dank.


    Gruess
    ricshort

    Ok.


    Zuerst die genau dokumentierte Stelle (gefahren am 19.03.):


    Natrup-Hagen (anlässlich einer Überholung):




    Dann weitere Orte aus der Erinnerung - müsste das Szenario nochmals fahren, um genauer zu dokumentieren:


    - Drentwede >> bei Einfahrt aus Richtung Bremen ins Gleis "Drentwede 05 - Ausweiche" >> zwecks Überholung
    - Münster >> bei der Fahrt von "Muenster 004" nach "Muenster 255 - Abstellung I"
    - Lemförde >> bei der Einfahrt von Seite Diepholz ins Gleis "Lemfoerde 504" >> zwecks Überholung

    Nachdem ich die Probs wieder hatte >> gestern 16.04. die auf virtualTacks angebotene Version 1.1 (Download vom 03.01.2019) nochmals drübergebügelt. Cache geleert.


    Vorhin hab ich "Der Lokzug" nochmals begonnen. Kurz nach Anfang in Osnabrück:



    Bezüglich Installation. Habe jetzt nochmals die Version 1.1 heruntergeladen und werde neu installieren. Bericht folgt.



    Update:


    Das Problem besteht weiterhin. Bisherige Installation sauber deinstalliert. Neu heruntergeladene Installationsdatei von virtualTracks installiert. Cache geleert. "Der Lokzug" begonnen.


    Kurz nach dem links liegenden Sh 0 (welches ja nicht für mich gilt) ...


    … weiter vorne ist das für mich gültige Signal bereits zu sehen …


    … ereilt mich erneut der Rauswurf.



    Es ist wie wenn das Sh 0 - Signal links einen zu grossen "Dunstkreis" (Einflussbereich) hat. Entgegen meiner ersten Annahme, dass ein mit dem Rücken zu mir stehendes Halt zeigendes Signal das Problem verursacht. Solche Sh 0 Signale liegen auch bei den weiter oben genannten Stellen in der Nähe des "Player-Fahrweges".

    Dann hat das Update auf die 1.1 bei euch nicht funktioniert. In der 1.1 ist dieser Fehler nicht vorhanden. Bitte die Strecke mal komplett löschen und dann neu installieren. Scheinbar überschreibt der Installer die nötigen Dateien nicht korrekt.

    Hi,
    ich habe kein Update installiert, sondern die von Aerosoft erhaltenen Version V1.10 (siehe Bild).
    Mit dem Installations-Assistenten entfernt und nochmal neu installiert. Keine Änderung.
    Die Daten im Routes-Ordner haben den Zeitstempel 07.12.2018 11:00


    Ist ja kein Riesen-Problem, muss man halt das Häkchen bei "Fahrtabbruch..." rausnehmen und den schwarzen Fleck in der Auswertung übersehen.


    Schöne (Rest-) Ostern noch.
    Gruß von Kreuzkopf


    Bitte mal die Datei im Anhang tauschen (natürlich vorher entpacken). Liegt unter "....\Assets\virtualTracks\Muenster-Bremen\RailNetwork\Signals\CommonScripts\" .


    Die Datei muss das Datum 19.1.2019 tragen. Allerdings beißt sich das mit dem Installer Datum. Scheint als gab es noch gar kein Update mit der Korrektur. Das dachte ich bisher aber. Die Korrektur hatte ich relativ zeitnah nach Meldung durch die Kunden dargereicht. Irgendwie hier im Forum kann man den Zeitpunkt auch noch nachprüfen. Da hatten wir nämlich schon mal drüber gefaselt.