Das Problem wird dadurch beschrieben, dass die Erfassung des rückwärtigen Fahrweges scheitert, da die überfahrenen Weichen in ihre Grundstellung zurückgehen.
Also muss man erreichen, dass sie das nicht tun. Und womit?
ANSATZ: Mit dem Pfad eines Blindzuges, der über die gleichen Weichen fährt und die Weichenstellung aktuell hält.
Er darf die Weichen dann gar nicht überfahren, sondern könnte davor anhalten.
Blindzüge haben die Eigenschaft, dass man sie nicht nur nicht sieht, sondern einfach über sie hinweg fahren kann.
Die Blindzüge von GR sind hier nur zu 99 % perfekt. Es kommt zu keinem Kupplungsverhakeln, weil die Blindzüge eine spezielle Kupplung haben, die mit keinem anderen Fahrzeug übereinstimmt.
CouplingUniqueType ( "Blindzug" )
Außerdem kollidiert das Shape eines Zuges i.d.R. nicht mit einem Blindzug, weil dessen Form ganz klein ist und ganz tief in der Mitte zwischen den Gleisen sitzt.
Allerdings ist die Kollision nicht völlig ausgeschlossen. Das wäre sie aber, wenn in der Datei "Blindzug.sd" die Zeile
ESD_Bounding_Box ( -0.3 -1.5 -0.3 0.3 -0.5 0.3 )
eliminiert wird. Danach ist jede Kollision unmöglich.
Jetzt gibt es noch ein logisches Signalproblem. Soll der Spieler über einen Blindzug fahren, belegt der ja zunächst einen Block. Die übliche Signalschaltlogik wehrt sich dagegen. Es lassen sich die Bedingungen für rot aber abmildern, wenn der Block-besetzt-Status entfällt und nur die korrekte Weichenschaltung abgefragt wird, dann kann der Spieler über das Asig des Überholgleises fahren, obwohl der kurze Block zwischen diesem und dem Asig des Hauptweges durch den Blindzug besetzt ist.
Im entsprechenden Script statt
if ( ..... block_state() !=# BLOCK_CLEAR .....
kommt
if ( ..... block_state() ==# BLOCK_JN_OBSTRUCTED .....
Das Asig des Überholgleises schaltet auch dann nicht auf rot, wenn der Spieler den Signalkopf erreicht, da der Besetzt-Status belanglos geworden ist. Hier kommt nun ein Verzögerungstrick zum Einsatz. Ein beliebiges Signal, das nicht »normal« sein braucht, und das zwischen dem Asig und der nächsten Weiche stehen muss, bewirkt beim Überfahren, dass das zurückliegende »normal«e Signal in den Not-enabled-Zustand gesetzt wird, und eben genau dann schaltet das Asig leicht zeitlich weil räumlich verzögert auf Rot - durch die Abfrage des enabled-Flags.
So, das war es eigentlich schon, verstanden, noch Fragen? - keine - gut!
Das nicht »normal«e Hilfs-Schalt-Signal sollte so weit entfernt vom Asig stehen, dass der Blindzug hier zwischen am besten an einem Wartepunkt halten kann. Dies müsste der Aufgabenersteller einigermaßen bequem einrichten können. Wie erklärt hält der Blindzug die Weichenstellung aktiv, während der Spieler über das Geschehen hinwegrollt. Soll zu einem späteren Zeitpunkt in derselben Aufgabe, man wendet, fährt zurück, die Signalstellung aus der Warte des Hauptgleises möglich werden, muss sich der Blindzug in der Zwischenzeit in Luft aufgelöst haben, daher die beste Variante, die nur mit BIN geht, ihn an einem Wartepunkt halten zu lassen, was eine breite Zeitspanne abdecken kann, um ihn danach aber doch relativ zügig zum bitteren Ende seines Pfades gelangen zu lassen.
Er darf sich zuvor ja nicht oder nicht schnell bewegen, da er die Weichen, deren Stellung er halten soll, nicht überfahren darf.
»normal« bezieht sich immer auf die Funktion SIGFN des Signalkopfes. Das nicht »normal«e Hilfs-Schalt-Signal könnte mit einem rückwärtigen Signalkopf mit dem Wegemarker für die Kennung des Überholgleises kombiniert werden. Die Signallogik des ersteren ist komplett belanglos; bloß das Überfahren eines Signals beliebigen Typus bewirkt,
dass das letzte »normal«e Signal in den not-enabled-Zustand versetzt wird. Diese Schaltfolge ist im MSTS immer so.
Gruß Hehl
P. S.: Ich sehe kaum eine bessere Möglichkeit der Lösung. Sie setzt die konzertante Aktion zwischen Signalbauer, Streckenbauer und auch Act-Bauer voraus. Fehlt der passende Blindzug in der Aufgabe, passiert kein Unglück, aber beide Asig zeigen auf der Überholspur nacheinander dann den Signalbegriff.
Im Erkundungsmodus ist es ebenso.