Open Rails Zugbetrieb

Beachten Sie, dass dieses Dokument nur das Verhalten im Einzelspielermodus beschreibt. Für den Mehrspielermodus können abweichende Regeln gelten.

Eine vollständige Liste der Parameter finden Sie unter Entwickeln von OR-Inhalten – Parameter und Token

11.1 Open Rails-Aktivitäten

OR hat das Ziel, die meisten für MSTS geschriebenen Aktivitäten auf kompatible Weise auszuführen.

Außerdem können Aktivitäten speziell für den OP-Bereich erstellt werden, indem die zusätzlichen Funktionen des OP-Bereichs genutzt werden, wie z. B. Extended AI Shunting. Diskussionen zur Ausführung einiger Funktionen in ORTS und MSTS finden Sie hier.

11.1.1 Spielerpfade, KI-Pfade und wie Wechsel gehandhabt werden

Wenn der Spielerpfad erfordert, dass ein Schalter in beide Richtungen ausgerichtet ist, wird die letzte Ausrichtung auf dem Pfad verwendet. Wenn ein KI-Zug den Spielerweg kreuzt, bevor der Spielerzug dort ankommt, lässt der KI-Zug die Weichen auf der Hauptstrecke ausgerichtet (die Standardeinstellung für die meisten Weichen).

Wenn Sie einen Schalter betätigen, um auf ein Abstellgleis zu fahren, ist der Schalter am anderen Ende des Abstellgleises so ausgerichtet, dass Sie es verlassen können, wenn Ihr Zug das Abstellgleis zum ersten Mal belegt. Danach wird die ursprüngliche Einstellung jedoch nicht mehr wiederhergestellt. Wenn der Schalter in die andere Richtung umgelegt wird, können Sie das Abstellgleis mit falsch ausgerichtetem Schalter verlassen. Wenn Sie den Zug abkuppeln und wieder ankuppeln, während er sich auf der falsch ausgerichteten Weiche befindet, wechselt das hintere Ende des Zugs die Gleise.

11.2 Open Rails AI

Grundlegende KI-Funktionalität

• OR unterstützt KI-Züge. Das KI-System wird mit neuen Funktionen immer fortschrittlicher.

• OR unterstützt zwei unterschiedliche Arten der Zugsteuerung: Es unterstützt traditionelle Aktivitäten in Kompatibilität mit MSTS und unterstützt auch den Fahrplanmodus. Beachten Sie, dass verschiedene Optionen und Einstellungen manchmal entweder auf den Aktivitäts- oder den Zeitplanmodus beschränkt sind.

• KI-Züge können sich treffen, wenn auf beiden Gleisen Überholabschnitte am selben Ort definiert sind oder wenn ihre Gleise sie zu unterschiedlichen Gleisen am Treffpunkt führen.

• Wartepunkte und Umkehrpunkte funktionieren. Umkehrpunkte können sowohl im Aktivitäts- als auch im Fahrplanmodus verwendet werden, während Wartepunkte nur im Aktivitätsmodus verwendet werden können.

• KI-Züge betätigen nicht richtig ausgerichtete Weichen, bevor sie diese betätigen.

• Im Aktivitätsmodus können KI-Züge Rangieraktionen durchführen.

• Prioritäten: KI-Züge sollten wie geplant starten, solange sich kein anderer KI-Zug bereits auf einem Konfliktpfad befindet.

11.3 Steuermodus

Der Steuerungsmodus definiert, welche Interaktionen zwischen dem Spieler und dem Steuerungssystem bestehen und wie stark der Spieler Signale und Schalter kontrolliert. Es gibt zwei Grundmodi: Auto-Modus und manueller Modus. Verwenden Sie die Taste <Strg+M>, um zwischen diesen Modi umzuschalten.

11.3.1 Auto-Modus

Im Auto-Modus stellt das Steuerungssystem den Weg und die Signale des Zuges ein, und der Spieler kann die Einstellung der Weichen nicht ändern oder die Freigabe gefährdeter Signale anfordern. Die Route des Zuges wird von der Trasse übernommen, die im Aktivitätseditor oder in der Fahrplandefinition definiert ist, und das System versucht, die Route vor dem Zug entsprechend den Signalisierungsregeln und der Interaktion mit anderen Zügen freizumachen.

In der Rückwärtsrichtung wird keine Strecke freigegeben, da davon ausgegangen wird, dass der Zug nicht rückwärts fährt. Die Auswahl einer Rückfahrkabine oder die Änderung der Position des Umkehrers ändert nicht die Richtung der Route. Tatsächlich wird die Route nur an Umkehrpunkten, die in der Zugtrasse definiert sind, umgekehrt. An diesen Umkehrpunkten wird die Strecke automatisch umgekehrt, sobald der Zug hält.

Wenn der Zug versehentlich rückwärts fährt, z.B. B. aufgrund von Ausrutschen oder Zurücksetzen nach Überschreiten eines Bahnsteigs, werden nur Sicherheitskontrollen für das hintere Ende des Zugs in Bezug auf Signale, Weichenausrichtung, andere Züge und Gleisende durchgeführt. Es gibt keine Geschwindigkeitskontrolle hinter dem Zug.

Das Setzen von Schaltern über das F8-Fenster oder <G>/<Umschalt+G> ist nicht zulässig. Das Setzen von Weichen mit Alt+linker Maustaste ist möglich, für Weichen im Zugweg jedoch nicht zulässig. Allerdings werden alle manuell eingestellten Weichen automatisch von einem herannahenden Zug entsprechend der Strecke dieses Zuges zurückgesetzt. Im Auto-Modus kann der Zug daher nicht von der definierten Strecke abweichen.

Eine Anforderung zum Löschen eines Signals vor dem Zug mit dem Tab-Befehl ist nur zulässig, wenn das Gleis vor dem Zug von einem anderen stillstehenden Zug belegt ist und wenn dieses Gleis in der Fahrstraße des Zuges liegt. Eine Aufforderung zur Freigabe eines Signals, das den Zug von seiner Strecke abbringen würde, ist nicht zulässig. Eine Aufforderung zur Freigabe eines Signals hinter dem Zug per Umschalt+Tab ist ebenfalls nicht möglich.

Der Auto-Modus ist für den normalen Betrieb unter Kontrolle von Signalen oder Verkehrskontrolle vorgesehen. Rangierfahrten können durchgeführt werden, wenn sie vollständig im Zugweg definiert sind, unter Verwendung von Umkehrpunkten usw.

Details zum Auto-Modus: Auto-Signal und Auto-Knoten

Es gibt zwei Untermodi zum Auto-Modus: Auto Signal und Auto Node.

Auto Signal ist der normale Modus auf signalisierten Routen. Die Strecke des Zuges wird grundsätzlich von Signal zu Signal freigegeben. Nur in speziell definierten Situationen können Routen kurz vor einem Signal freigegeben werden, wie unten beschrieben.

Auto Node wird gesetzt, wenn der Zug noch keine Signale angetroffen hat, z.B. auf nicht signalisierten Strecken oder am Streckenanfang, wenn entlang der Trasse des Zuges kein Signal vorhanden ist, soweit es geräumt werden kann – z.B. in Bahnhöfen, in denen der Zug startet, aber noch keine klare Route zum ersten Signal hat.

Auto Node kann auch eingestellt werden, wenn die vor Ihnen liegende Route bis zum nächsten Signal nicht vollständig freigegeben werden kann und eine teilweise Freigabe zulässig ist.

Abhängig vom Grund für die Beendigung der Freigabe werden im Auto-Knoten eine Reihe von Unterzuständen definiert. In der folgenden Liste gibt (A) einen Untertyp an, der auftreten kann, wenn noch kein Signal angetroffen wurde, und (B) gibt einen Untertyp an, wenn eine Route von einem Signal teilweise freigegeben ist.

Folgende Zustände sind möglich:

• (A) Die vor Ihnen liegende Route ist bis zur maximalen Entfernung, für die die Strecke frei ist, frei. Der Steuermodus ist auf Auto Node – Max Distance eingestellt.

• (A) Die vorausliegende Strecke ist an einer Weiche blockiert, die für einen anderen Zug ausgerichtet und von diesem besetzt oder reserviert ist. Der Steuermodus ist auf Auto Node – Misaligned Switch eingestellt.

• (A)(B – nur wenn das Signal den Zugang zum besetzten Gleis ermöglicht oder nach dem <Tab>-Befehl) Die vor Ihnen liegende Strecke ist von einem stehenden Zug oder einem Zug, der sich in die gleiche Richtung bewegt, besetzt. Der Steuerungsmodus ist auf Auto Node eingestellt

– Trainieren Sie voraus.

• Beachten Sie, dass es bei (A) nicht möglich sein sollte, dass die vor Ihnen liegende Strecke von einem Zug besetzt ist, der in die entgegengesetzte Richtung fährt. In diesem Fall sollte sich immer eine falsch ausgerichtete Weiche in der Trasse des Zuges befinden.

• Bei (B) wird ein Signal niemals gelöscht, wenn der vorausfahrende Zug in die entgegengesetzte Richtung fährt, und die Tab-Anfrage wird auch nicht gewährt.

• (A)(B) die festgelegte Trasse des Zuges endet kurz vor dem nächsten Signal, oder es gibt einen Umkehrpunkt kurz vor dem nächsten Signal und es gibt mindestens eine Weiche zwischen diesem Punkt und dem nächsten Signal. Der Steuermodus wechselt zu Auto Node – End of Path. Beachten Sie, dass die Strecke automatisch bis zum nächsten Signal verlängert wird, wenn zwischen dem End- oder Umkehrpunkt und dem nächsten Signal keine Weiche erfolgt.

• (A)(B) Der Zug hat das letzte Signal vor dem Gleisende passiert oder der Zug hat das Gleisende erreicht, ohne auf ein Signal zu stoßen. Der Steuermodus wechselt zu Auto Node – End of Track.

Der Wechsel von Auto Node zu Auto Signal und umgekehrt erfolgt automatisch und kann vom Spieler nicht beeinflusst werden.

11.3.2 Manueller Modus

Wenn es erforderlich ist, dass ein Zug seinen definierten Weg verlässt, kann ein Spieler seinen Zug in den manuellen Modus schalten. Dadurch kann der Spieler Schalter setzen und anfordern, Signale von seinem Weg zu entfernen. Beim Fahren eines Zuges im manuellen Modus gibt es jedoch eine Reihe von Einschränkungen.

Im manuellen Modus wird eine Fahrstraße vom Zug in beide Richtungen, vor und hinter dem Zug, freigegeben. Die Route wird im Vergleich zum Auto-Modus auf einer kürzeren Distanz freigegeben und nach dem ersten Signal nie automatisch freigegeben. Wenn ein Zug fährt und ein Signal in die entgegengesetzte Richtung passiert, fährt die Strecke hinter dem Zug automatisch auf dieses Signal zurück, da dies nun das nächste Signal in der Rückwärtsstrecke ist. Die gleichen Einschränkungen gelten für die vorausfahrenden Signale, wenn der Zug rückwärts fährt.

Die Streckenausrichtung ändert sich nicht, unabhängig davon, in welche Richtung der Zug fährt. Es ist auf die Ausrichtung der Route fixiert, wie sie war, als der Spieler in den manuellen Modus wechselte. Der Wechsel zu einem rückwärts gerichteten Führerstand oder die Änderung der Position des Umkehrers der Lok ändert also nicht die Richtung der Streckenausrichtung. Dies stellt keine Einschränkung für das Verhalten des Zuges dar, da die Fahrwege immer in beide Richtungen geräumt werden. Es wirkt sich jedoch auf die Anzeige der Fenster F4 und F8 aus, da die Richtung oben/unten dieser Fenster mit der Streckenrichtung verknüpft ist und sich daher nicht ändert, wenn der Zug rückwärts fährt. Um dem Spieler bei der Orientierung zu helfen, in welche Richtung sich der Zug bewegt, wurde diesen Anzeigen ein „Auge“ hinzugefügt, das die Richtung der Führerstandsansicht symbolisiert, und ein „Pfeil“ wurde hinzugefügt, um die Richtung des Umkehrers zu symbolisieren.

Der Spieler kann alle Weichen im Zugweg mit dem F8-Fenster oder den Tasten <G>/<Umschalt+G> einstellen. Mit der G-Taste stellen Sie die erste Weiche vor dem Zug ein (wie durch die Routenrichtung definiert), Umschalt+G stellt die Weiche hinter dem Zug ein. Es ist auch möglich, Schalter nach Bedarf mit dem Befehl Alt+Linke Maustaste zu setzen. Weichen können auch dann gestellt werden, wenn sie sich im Zugweg befinden und über diesem Weg ein Signal freigegeben wurde. Weichen können natürlich nicht gesetzt werden, wenn sie bereits als Teil einer freigegebenen Strecke für einen anderen Zug eingestellt sind.

Für die Einstellung von Schaltern gelten folgende Regeln:

• Alle Weichen bleiben in der Position, in der sie vom letzten über diese Weiche fahrenden Zug eingestellt wurden. Wenn noch kein Zug über die Weiche gefahren ist, befindet sie sich in ihrer Grundstellung.

• Im manuellen Modus werden die hinteren Weichen nicht automatisch auf den herannahenden Spielerzug ausgerichtet, außer:

• Wenn eine Fahrstraße im manuellen Modus durch ein Signal freigegeben wird, werden alle nachgestellten Weichen im Zugweg bis zum Ende der Autorität (z. B. nächstes Signal) ausgerichtet. Beachten Sie, dass in diesem Fall Schleppschalter im durch das Signal freigegebenen Pfad nicht mehr zurückgesetzt werden können. Signale, denen sich der Zug nähert, werden nicht automatisch gelöscht. Der Spieler muss die Freigabe aller angetroffenen Signale anfordern, indem er die Tasten <Tab> oder <Umschalt+Tab> verwendet.

Die <Tab>-Taste löscht das Signal vor dem Zug (je nach Streckenrichtung), die <Umschalt+Tab>-Taste löscht das Signal hinter dem Zug. Wiederholte Verwendung von (<Umschalt> + )<Tab>`` löscht das nächste Signal nach dem ersten gelöschten Signal usw., jedoch nur bis zur maximalen Löschentfernung.

Signale werden immer auf Anfrage freigegeben, es sei denn, der Abschnitt unmittelbar hinter dem Signal ist bereits für einen Zug aus der Gegenrichtung freigegeben. Die normalen Einschränkungen bei der Routeneinstellung usw. werden ignoriert. Das Signal wird nur bis zum ersten verfügbaren, restriktivsten Aspekt über Stop freigegeben.

Beachten Sie, dass im Gegensatz zur Situation im Auto-Modus das Signal auch dann freigegeben wird, wenn die gesamte Strecke hinter dem Signal nicht verfügbar ist. Ein freigegebenes Signal ist kein Hinweis auf die freigegebene Entfernung hinter diesem Signal. Es kann sein, dass die erste Weiche hinter dem Signal bereits für einen anderen Zug freigegeben ist. Daher ist es im manuellen Modus wichtig, das F4-Fenster oder das Dispatcher-Fenster zur Überprüfung der Routenverfügbarkeit zu verwenden, wenn Sie in einem Gebiet mit KI-Verkehr fahren.

Im manuellen Modus ist die Deadlock-Verhinderung ausgeschaltet. Dies liegt daran, dass die im manuellen Modus wahrscheinlich auftretenden Änderungen der Route und Richtung des Zugs die Stabilität der Deadlock-Verarbeitung gefährden könnten. Daher ist Vorsicht geboten, wenn Sie den manuellen Modus in einem Gebiet mit KI-Verkehr verwenden, insbesondere auf eingleisigen Abschnitten.

Der Wechsel vom automatischen Modus in den manuellen Modus kann bei stehendem oder fahrendem Zug erfolgen. Die Taste <Strg+M> schaltet zwischen dem automatischen Modus und dem manuellen Modus um. Beim Wechsel vom Auto-Modus in den manuellen Modus werden alle bereits gelöschten Signale zurückgesetzt und neue Fahrstraßen werden vor und hinter dem Zug möglichst für die maximale Entfernung bzw. bis zum ersten Signal freigegeben.

Um vom manuellen Modus in den automatischen Modus zurückzukehren, muss sich die Vorderseite des Zuges auf der im Aktivitätseditor definierten Strecke befinden. Wenn der Pfad Umkehrpunkte enthält, muss sich der Zug zwischen denselben Umkehrpunkten befinden wie beim Umschalten in den manuellen Modus (d. h. auf demselben Unterpfad).

Bewegt sich der Zug in die vom Fahrweg vorgegebene Richtung, kann während der Zugfahrt zurück in den AutoMode gewechselt werden. Die Rückseite des Zuges muss nicht auf der definierten Strecke liegen, sondern nur die Vorderseite.

Fährt der Zug in die entgegengesetzte Richtung, muss er stillstehen, um wieder in den Auto-Modus zu wechseln. Wenn die Ausrichtung der Zugroute irgendwie umgekehrt wurde (z. B. durch Bewegung durch eine Ballonlinie oder einen Y-Abschnitt) und von der Richtung im definierten Pfad abweicht, müssen sich sowohl die Vorder- als auch die Rückseite auf dem definierten Pfad befinden. In dieser Situation ändert sich die Ausrichtung wieder in die im Pfad definierte Richtung.

11.3.3 Außer-Kontroll-Modus

Dies ist ein spezieller Modus. Normalerweise sollte sich der Spielerzug nicht in diesem Modus befinden. Der Außer-Kontroll-Modus wird aktiviert, wenn der Spieler gegen eine Sicherheitsregel verstößt. Solche Vorfälle sind:

• wenn der Spielerzug ein Gefahrensignal (SPAD) passiert;

• wenn der Spielerzug über eine falsch ausgerichtete Weiche fährt;

• wenn der Spielerzug über das Ende des genehmigten Weges hinausfährt.

Durch diese Aktionen gerät der Zug des Spielers außer Kontrolle. In dieser Situation wird die Notbremse aktiviert und bis zum Anhalten des Zuges aufrechterhalten. Der Spieler hat keine Kontrolle über seinen Zug, bis dieser stillsteht.

Sobald der Zug angehalten hat, kann der Spieler in den manuellen Modus wechseln, um zu versuchen, in die richtige Situation zurückzukehren (z. B. bei Gefahr wieder vor das Signal, auf autorisierten Weg usw.). Sobald eine normale Situation wiederhergestellt ist, kann der Spieler wieder in den Auto-Modus wechseln. Wenn die Aktion den Zug des Spielers auf einen Gleisabschnitt geführt hat, der bereits für einen anderen Zug freigegeben ist, wird dieser Zug ebenfalls angehalten.

11.3.4 Explorer-Modus

Wenn OR im Explorer-Modus statt in einer Aktivität gestartet wird, wird der Zug in den Explorer-Modus versetzt. Der Spieler hat die volle Kontrolle über alle Schalter. Signale werden wie gewohnt gelöscht, aber Signale können über Routen, die normalerweise nicht verfügbar sind, mit den Befehlen <Tab> oder <Umschalt+Tab> gelöscht werden.

11.4 Track-Zugriffsregeln

Alle Züge räumen ihren eigenen Weg frei. Im Auto-Signal-Modus wird ein Teil dieser Funktion auf die Signale übertragen.

Im Auto-Node-Modus räumen Züge ihren Weg bis zu 5.000 Metern oder der in 2 Minuten zurückgelegten Strecke mit der maximal zulässigen Geschwindigkeit frei, je nachdem, welcher Wert größer ist. Im Auto-Signal-Modus wird die Anzahl der vor dem Zug freigegebenen Signale aus dem Wert des Parameters SignalNumClearAhead ermittelt, der in der Datei sigcfg.dat für das erste Signal vor dem Zug definiert ist.

Im manuellen Modus beträgt die zurückgelegte Distanz maximal 3000 Meter oder ist durch Signale begrenzt.

Die Entfernungen im Explorer-Modus ähneln denen im Auto-Modus.

Wenn ein Zug an einem Signal anhält, kann er das Gleis vor ihm beanspruchen, um sicherzustellen, dass er als nächster Zug auf diesem Abschnitt Vorrang hat. Um jedoch eine unnötige Blockierung anderer möglicher Strecken zu vermeiden, wird kein Anspruch erhoben, wenn der vorausfahrende Zug ebenfalls angehalten wird.

Es gibt keine Unterscheidung zwischen Zugtypen und keine Vorrangregelung.

11.5 Deadlock-Verarbeitung

Wenn ein Zug gestartet wird, vergleicht er seinen Weg mit allen anderen Zügen (einschließlich derer, die noch nicht gestartet sind). Wenn ein Abschnitt gefunden wird, auf dem dieser Zug und der andere Zug in entgegengesetzter Richtung verkehren, werden die Grenzen dieses gesamten gemeinsamen Abschnitts bestimmt und an diesen Grenzen werden Deadlock-Fallen für jeden Zug in der entsprechenden Richtung gesetzt. Diese Grenzen sind immer Schaltknoten. Wenn ein Zug einen Knoten passiert, der über eine Deadlock-Falle für diesen Zug verfügt, wird die Falle ausgelöst. Wenn sich ein Zug einem Knotenpunkt nähert, an dem ein aktiver Deadlock vorliegt, hält er an diesem Knotenpunkt oder am letzten Signal vor ihm, falls vorhanden. Dieser Zug wird nun auch seine Blockaden auslösen und den gesamten gemeinsamen Abschnitt dieser Blockade beanspruchen, um sicherzustellen, dass er der nächste Zug ist, der diesen Abschnitt betreten darf. Die Deadlock-Fallen werden entfernt, wenn ein Zug den Endknoten eines Deadlock-Abschnitts passiert.

Wenn ein Zug gestartet wird und die Trasse des Zuges einen oder mehrere Umkehrpunkte enthält, werden Deadlocks nur für den Teil der Trasse bis zum ersten Umkehrpunkt überprüft. Beim Stornieren werden Deadlocks für den nächsten Teil überprüft usw.

Deadlock-Fallen werden entfernt, wenn ein Zug in den manuellen Modus wechselt. Wenn der Zug wieder in den Auto-Modus wechselt, wird die Deadlock-Prüfung erneut durchgeführt.

Im Explorer-Modus gibt es keine Deadlock-Prüfungen, da es in diesem Modus keine KI-Züge gibt.

Wenn ein alternativer Pfad definiert ist (unter Verwendung der Passing Path-Definition im MSTS-Aktivitätseditor) und der Zug eine Route zum Startknoten dieses alternativen Pfads festlegt, prüft er, ob für den zugehörigen Endknoten ein Deadlock gesetzt ist. Wenn dies der Fall ist und der Ausweichweg frei ist, wird er den Ausweichweg nehmen, sodass der andere Zug den Hauptweg nutzen kann. Wenn die alternative Trasse bereits belegt ist, wartet der Zug kurz vor dem Knotenpunkt, an dem die Trasse beginnt (oder vor dem letzten Signal davor, falls vorhanden); Dadurch soll verhindert werden, dass beide Gleise blockiert werden, wodurch der Gegenzug nirgendwo hingehen kann.

Weitere Regeln für die Nutzung alternativer Wege:

• Züge aus beiden Richtungen müssen den gleichen Hauptweg durch das Gebiet haben.

• Wenn nur für einen Zug eine alternative Trasse definiert ist und die Züge passieren sollen, wird dieser Zug immer die alternative Trasse benutzen; Der andere Zug wird immer die Hauptstrecke benutzen, unabhängig davon, welcher Zug zuerst ankommt.

• Wenn für beide Züge eine alternative Trasse definiert ist und die Züge passieren sollen, nimmt der erste Zug, der seine Route freigibt, die alternative Trasse. Beachten Sie, dass dies nicht immer der erste Zug sein muss, der ankommt – es kann sein, dass der Zug, der als erster seinen Weg frei macht, viel länger braucht, um tatsächlich die Ausweichschleife zu erreichen.

11.6 Umkehrpunkte

Wenn ein Umkehrpunkt definiert ist, wird der Weg über diesen Punkt hinaus bis zum Ende des Abschnitts verlängert, d. h. bis zur nächsten Weiche oder dem nächsten Signal bzw. dem Gleisende.

Der Diverging-Punkt wird bestimmt – das ist der Switch-Knoten, an dem die Reverse-Route von der eingehenden Route abweicht. Von diesem Punkt aus wird nach dem letzten Signal in Gegenrichtung gesucht, das so positioniert ist, dass der gesamte Zug zwischen das Signal und das Ende des Gleises passt. Wenn ein solches Signal vorhanden ist, wird dies zum divergierenden Punkt. Damit ein Zug rückwärts fahren kann, muss sich das Ende des Zuges von diesem Divergenzpunkt fernhalten.

Die Umkehrung für KI-Züge erfolgt wie in MSTS; Das heißt, wenn der erste Wagen des KI-Zugs den Umkehrpunkt erreicht. Wenn das Ende des Zuges zu diesem Zeitpunkt die Weichenstelle noch nicht verlassen hat, erfolgt die Umkehr später, wenn die Weichenstelle freigegeben ist.

Bei Spielerzügen kann die Umkehr ab 50 Meter vor dem Umkehrpunkt erfolgen, sofern der Weichenpunkt geräumt wird. Die Farbe des Umkehrpunktsymbols im TrackMonitor ist grün, wenn der Abweichungspunkt gelöscht wurde (d. h. der Spielerzug kann bereits umkehren, auch wenn er den Umkehrpunkt noch nicht erreicht hat), im umgekehrten Fall ist es weiß (Das bedeutet, dass der Zug des Spielers weiter in Richtung des divergierenden Punktes fahren und ihn schließlich erreichen muss, wenn die Farbe nicht auf Grün wechselt, bevor er zurückfährt.)

Wie bei MSTS können doppelte Umkehrpunkte genutzt werden, um nach solchen Umkehrpunkten ein Signal auf Rot zu setzen. Hierfür werden jedoch Wartepunkte empfohlen, wie im nächsten Absatz erläutert.

11.7 Wartepunkte

11.7.1 Allgemeines

Wartepunkte (WP), die in einem von einem KI-Zug genutzten Weg festgelegt werden, werden vom Zug regelmäßig respektiert und ausgeführt, wenn der Zugkopf den WP erreicht.

Anders als bei MSTS haben Wartepunkte keinen Einfluss auf die Länge des reservierten Pfades, es sei denn, dem WP folgt ein Signal im gleichen Gleisabschnitt (keine Knoten – also Weichen – dazwischen).

WPs, die in einem von einem Spielerzug genutzten Gleis platziert sind, haben keinen Einfluss auf die Zugfahrt, außer – wiederum – wenn dem WP ein Signal im selben Gleisabschnitt folgt. In solchen Fällen wird das Signal sowohl für KI-Züge als auch für Spielerzüge auf Rot gesetzt, wenn sich der Zug dem WP nähert.

Bei KI-Zügen wechselt das Signal eine Sekunde nach Ablauf des WP wieder auf Grün (sofern die Blockbedingungen nach dem Signal dies zulassen).

Bei Spielerzügen wechselt das Signal 5 Sekunden nach Ablauf der WP wieder auf Grün.

Befinden sich in dem Gleisabschnitt, in dem sich das Signal befindet, mehrere WPs, beeinflusst nur der letzte das Signal. Wartepunkte können im Fahrplanmodus nicht verwendet werden.

11.7.2 Absolute Wartepunkte

Wartepunkte mit einer Wartezeit zwischen 30000 und 32359 werden als absolute Tageszeitwartepunkte im Format 3HHMM interpretiert, wobei HH und MM die Stunden und Minuten des Tages in der Standard-Dezimalschreibweise sind.

Wenn der KI-Zug den WP vor dieser Tageszeit erreicht, läuft der WP um HH:MM ab. Wenn der KI-Zug später das WP erreicht, ist das WP bereits abgelaufen. Dieser WP-Typ kann auch in Verbindung mit einem Signal im gleichen Gleisabschnitt verwendet werden, wie im vorherigen Absatz erläutert.

Auch hier haben solche Wartepunkte keine Auswirkung auf einen Spielerzug, wenn es im selben Abschnitt kein Signal gibt; Liegt stattdessen ein Signal vor, bleibt es rot, bis der WP abgelaufen ist.

Absolute Wartepunkte sind eine komfortable Möglichkeit, den Zugbetrieb zu synchronisieren und zu planen.

11.8 Signale an Bahnsteigen

Wenn die experimentelle Option „Erzwungenes Rot an Haltestellen“ ausgewählt wurde und sich am Ende eines Bahnsteigs ein Signal befindet, wird dieses Signal bis zu 2 Minuten vor der gebuchten Abfahrt gefährdet gehalten. Wenn der Bahnhof weniger als 2 Minuten dauert, wird das Signal gelöscht, wenn der Zug zum Stehen kommt. Dies gilt sowohl für KI-Züge als auch für Spielerzüge.

Wenn die Bahnsteiglänge jedoch weniger als die Hälfte der Zuglänge beträgt, wird das Signal nicht gehalten, sondern normal gelöscht, damit sich der Zug richtig am Bahnsteig positionieren kann. Signale, die nur die Gleise schützen, werden ebenfalls nicht gehalten.

In manchen Bahnleitsystemen erhalten Züge am Bahnhofsanfangssignal kein rotes Signal, wenn sie in diesem Bahnhof anhalten müssen. In diesen Fällen muss die obige Option deaktiviert werden.

11.9 Durch Signale festgelegte Geschwindigkeitsmarkierungen und Geschwindigkeitsbegrenzungen

Geschwindigkeitsbegrenzungen, die die zulässige Geschwindigkeit erhöhen, wie sie durch Geschwindigkeitsmarkierungen oder Signale festgelegt werden, werden erst gültig, wenn das Ende des Zugs die Position der Geschwindigkeitsmarkierung oder des Signals passiert hat.

Wenn eine durch ein Signal festgelegte Geschwindigkeitsbegrenzung niedriger ist als die durch den letzten Geschwindigkeitsmesser festgelegte Geschwindigkeitsbegrenzung, wird die Geschwindigkeitsbegrenzung auf den niedrigeren Wert gesetzt. Wenn jedoch eine durch ein Signal festgelegte Geschwindigkeitsbegrenzung höher ist als die aktuelle Geschwindigkeitsbegrenzung, die durch die letzte Geschwindigkeitskontrolle festgelegt wurde, wird die durch die Geschwindigkeitskontrolle festgelegte Grenze beibehalten. Wenn aufgrund einer durch ein anderes Signal festgelegten Grenze eine niedrigere Geschwindigkeitsbegrenzung galt, wird die zulässige Grenze auf die durch den Geschwindigkeitspfosten festgelegte Grenze gesetzt.

Wenn im Fahrplanmodus eine Geschwindigkeitsmarkierung eine Grenze festlegt, die höher ist als die durch das letzte Signal festgelegte Grenze, wird die durch das Signal festgelegte Grenze außer Kraft gesetzt und die zulässige Grenze wird auf die durch die Geschwindigkeitsmarkierung festgelegte Grenze gesetzt.

Im Aktivitätsmodus gilt im vorherigen Fall der niedrigere der beiden Grenzwerte.

11.10 Weitere Features von AI Train Control

• KI-Züge fahren immer im automatischen Steuerungsmodus.

• KI-Züge ignorieren alle manuellen Weichenstellungen und setzen alle Weichen entsprechend ihrer Route zurück.

• AI-Züge halten an Bahnhöfen und halten sich nach Möglichkeit an die gebuchten Bahnhofsabfahrtszeiten.

• KI-Züge halten an einem Bahnsteig, sodass sich die Zugmitte in der Mitte des Bahnsteigs befindet. Wenn der Zug länger als der Bahnsteig ist, ragen sowohl die Vorder- als auch die Rückseite des Zuges über den Bahnsteig hinaus. Wenn der Bahnsteig am Ende ein Signal hat und dieses Signal gefährdet ist (siehe weiter oben) und der Zug zu lang für den Bahnsteig ist, hält er am Signal. Wenn die Zuglänge jedoch mehr als das Doppelte der Bahnsteiglänge beträgt, wird das Signal nicht gehalten.

• KI-Züge halten sich an die Geschwindigkeitsbegrenzungen.

• KI-Züge halten etwa 30 m entfernt an einem Signal. im Fahrplanmodus kurz vor einem gefährdeten Signal und im Aktivitätsmodus in einer kürzeren Entfernung.

• Wenn es KI-Zügen erlaubt ist, anderen Zügen im selben Abschnitt zu folgen, indem sie zulässige Signale passieren, passt der Zug seine Geschwindigkeit an die des vorausfahrenden Zugs an und folgt ihm in einem Abstand von ca. 50 cm. 300 m. Wenn der vorausfahrende Zug angehalten hat, wird der nachfolgende Zug auf eine Entfernung von etwa 50 m heranfahren. Wenn jedoch der vorausfahrende Zug in einem Bahnhof angehalten wird und der nachfolgende Zug ebenfalls zum Halten an diesem Bahnhof angemeldet ist, fährt der Zug bis zu einem Abstand von einigen Metern hinter den ersten Zug auf.

• Die Steuerung von KI-Zügen vor Beginn einer Aktivität ähnelt der normalen Steuerung während einer Aktivität, mit der Ausnahme, dass die Aktualisierungsfrequenz von der normalen Aktualisierungsrate auf nur einmal pro Sekunde reduziert wird. Aber alle Regeln bezüglich Geschwindigkeitsbegrenzungen, Haltestellen, Staus und Interaktion zwischen KI-Zügen (Signale usw.) werden eingehalten. Die Position aller KI-Züge zu Beginn einer Aktivität ist daher so nah wie möglich an der Position, die sie gehabt hätte, wenn die Aktivität zum Startzeitpunkt des ersten KI-Zugs gestartet worden wäre.

11.11 Ortsbezogene Überholwegverarbeitung

Durch Überholgleise können Züge auf eingleisigen Strecken aneinander vorbeifahren. Die erforderlichen Überholwege werden pro Zugtrasse im MSTS-Aktivitätseditor oder im nativen ORTS-Wegeditor im TrackViewer definiert.

Die vorliegende Version ist eine „Zwischenstufe“, die zu einer vollständigen Neuverarbeitung führt. Die Datenstruktur und -verarbeitung sind bereits für die nächste Stufe vorbereitet, in der „alternative Wege“ (nicht nur ein einzelner Durchgangsweg, sondern mehrere Wege durch ein bestimmtes Gebiet) pro Standort und nicht mehr pro Zug definiert werden.

Die vorliegende Version basiert jedoch immer noch auf der MSTS-Aktivitäts- und Trassendefinition und basiert daher weiterhin auf der Definition alternativer Trassen pro Zug.

Das Setup dieser Version ist wie folgt:

• Für den Spielerzug definierte Überholwege stehen allen Zügen zur Verfügung – in beide Richtungen. Der Durchgangsweg des Spielerzuges wird als „Hauptweg“ durch diesen Ort angesehen. Dies gilt nur für den Aktivitätsmodus, da es im Fahrplanmodus keinen vordefinierten Spielerzug gibt.

• Jeder Zug kann Definitionen für zusätzliche Überholwege haben. Diese stehen nur diesem Zug zur Verfügung. Beachten Sie, dass dies bedeutet, dass es mehr als einen Durchgangspfad pro Standort geben kann.

• Bei der Ermittlung möglicher Überholstellen für jedes Zugpaar werden die Zuglängen berücksichtigt. Ein Ort ist nur dann als Ausweichort „gültig“, wenn mindestens einer der Züge in den kürzesten der verfügbaren Ausweichwege passt.

• Die Reihenfolge, in der vorbeiführende Pfade ausgewählt werden:

– Wenn aus der Gegenrichtung (Durchgangsstrecke) kein Zug entgegenfährt:

* Der eigene Weg des Zuges.

* „Haupt“-Pfad.

* Jeder alternative Pfad.

– Wenn der Zug einen anderen aus der Gegenrichtung entgegenkommenden Zug überholen soll (Überholstrecke):

* Der eigene Weg des Zuges (falls er nicht mit dem „Hauptweg“ identisch ist).

* Alternativer Pfad.

* „Haupt“-Pfad.

Wenn der Zug jedoch nicht auf alle Gleise passt, erhält der erste Zug, der eine Gleise durch das Gebiet beansprucht, den Gleisen (falls vorhanden) den Vorzug, auf denen der Zug passt.

Die Einstellung der „Deadlock“-Falle (die Logik, die verhindert, dass Züge aus beiden Richtungen auf ein einzelnes Gleis gelangen) wurde ebenfalls geändert.

In der „alten“ Version wurde die Falle „zugeschnappt“, als ein Zug seinen Weg durch einen möglichen Durchfahrtsbereich einnahm.

Dies führte jedoch häufig zu recht frühen Blockaden von Zügen in die Gegenrichtung.

In dieser Version wird die Falle „zugeschnappt“, wenn ein Zug tatsächlich seine Strecke im eingleisigen Abschnitt selbst beansprucht.

Ein kleiner Fehler in dieser Logik besteht darin, dass dies dazu führen kann, dass der Zug, der warten soll, der „Hauptstrecke“ zugewiesen wird, während der Zug, der passieren kann, über die „Schleife“ geleitet wird. Dies kann passieren, wenn sich zwei Züge fast gleichzeitig einem einzelnen Gleisabschnitt nähern und jeder seinen Weg durch die Überholbereiche an beiden Enden beansprucht, bevor die Blockierfalle tatsächlich ausgelöst wird.

Wenn an einem Überholort Bahnsteige vorhanden sind und Personenzüge dort halten sollen, versucht OR, einen alternativen Bahnsteig auf dem Überholweg zu finden, und wenn er ihn finden kann, ersetzt dieser Bahnsteig den ursprünglichen Bahnsteig als Haltepunkt. Dieses Verhalten tritt nur auf, wenn die Option „Location-linked Passing Path Processing“ aktiviert wurde.

Die Auswahl dieser Art von Überholwegen mit der damit verbundenen experimentellen Optionsverarbeitung kann zu erheblichen Änderungen im Verhalten von Zügen auf eingleisigen Strecken führen – und zwar zu einem Verhalten, das sich sicherlich erheblich von dem im MSTS unterscheidet.

11.12 Andere Vergleiche zwischen laufenden Aktivitäten in ORTS oder MSTS

11.12.1 Ende der KI-Züge

KI-Züge beenden ihre Fahrt dort, wo sich der Endpunkt ihrer Strecke befindet, wie in MSTS. Allerdings beenden sie ihren Lauf immer bei Nullgeschwindigkeit.

11.12.2 Standardleistung und Leistungsparameter

Wenn der KI-Zug keine Haltestellen anhält, wird seine Höchstgeschwindigkeit (ohne Berücksichtigung von Signal, Geschwindigkeitsposten und Streckengeschwindigkeit) durch den ersten MaxVelocity-Parameter in der .con-Datei angegeben, ausgedrückt in Metern pro Sekunde, multipliziert mit dem Parameter „Standardleistung“ ( dividiert durch 100), die im MSTS AE im „Service-Editor“ gefunden und geändert werden können. Dieser durch 100 geteilte Parameter wird von der AE in die .srv-Datei als „Effizienz“ geschrieben.

Wenn der KI-Zug an Haltestellen anhält, hängt seine Höchstgeschwindigkeit vom Parameter „Leistung“ für jeden Streckenabschnitt ab, wie im Fahrplan des KI-Zuges ersichtlich und definiert ist (d. h. die Höchstgeschwindigkeit ist das Produkt des ersten MAxVelocity-Parameters mit der „Leistung“). Parameter geteilt durch 100).

Eine solche Leistungsparameterliste wird von der AE im Block „Service_Definition“ im Aktivitätseditor geschrieben (geteilt durch 100), wiederum als „Effizienz“ (für jeden Stationsstopp).

Vom Startort des KI-Zugs bis zur ersten Station wird die mit dieser Station verknüpfte „Leistung“ verwendet; Von der ersten Station zur zweiten wird die mit der zweiten Station verknüpfte „Performance“ verwendet und so weiter. Von der letzten Station bis zum Ende der Strecke wird die oben genannte „Standardleistung“ verwendet. Dies entspricht dem MSTS-Verhalten.

Darüber hinaus wird der Effizienzparameter auch zur Berechnung von Beschleunigungs- und Bremskurven verwendet.

11.12.3 Berechnung der Geschwindigkeitsbegrenzung für Züge

Für den Spielerzug: Die Geschwindigkeitsbegrenzung ist die niedrigste unter:

• Streckengeschwindigkeitsbegrenzung, wie in der .trk-Datei definiert

• lokale Signalgeschwindigkeitsbegrenzung

• örtliche Geschwindigkeitsbegrenzung

• Temporäre Geschwindigkeitsbegrenzung vor Ort

• Erster Parameter MaxVelocityA in der .con-Datei, wenn größer als Null und ungleich 40

• Geschwindigkeitsbegrenzung der Lokomotive in der .eng-Datei in den anderen Fällen.

Für die KI-Züge gilt: Die Geschwindigkeitsbegrenzung ist die niedrigste unter:

• Streckengeschwindigkeitsbegrenzung, wie in der .trk-Datei definiert

• lokale Signalgeschwindigkeitsbegrenzung

• örtliche Geschwindigkeitsbegrenzung

• Temporäre Geschwindigkeitsbegrenzung vor Ort

• Erster Parameter MaxVelocityA in der .con-Datei, wenn größer als Null und ungleich 40

• Geschwindigkeitsbegrenzung der Lokomotive in der .eng-Datei in den anderen Fällen.

• Streckengeschwindigkeitsbegrenzung, wie in der .trk-Datei definiert

• lokale Signalgeschwindigkeitsbegrenzung

• örtliche Geschwindigkeitsbegrenzung

• Temporäre Geschwindigkeitsbegrenzung vor Ort

• erster Parameter MaxVelocityA in der .con-Datei, wenn größer als Null, multipliziert mit der Effizienz, wie erläutert:ref:here <operation-performance>.

11.12.4 Beginn der Fahrt eines KI-Zuges in einem von einem anderen Zug reservierten Abschnitt

Der KI-Zug wird wie in MSTS erstellt. Es liegt in der Verantwortung des Aktivitätserstellers, keine Deadlocks zu erzeugen. Das Erstellen eines Zugs in einem Abschnitt, in dem sich ein anderer Zug befindet, ist nur möglich, wenn der erstellte Zug nicht direkt gegenüber dem vorhandenen Zug steht.

11.12.5 Stoppzeit an Stationen

Die vom MSTS-Aktivitätseditor definierte Bahnsteigpassagiernummer wird von OR gelesen

Jeder Passagier benötigt 10 Sekunden zum Einsteigen. Diese Zeit muss durch die Anzahl der Personenwagen innerhalb der Bahnsteiggrenzen geteilt werden. Auch Lokomotiven mit der Bezeichnung PassengerCapacity in der englischen Sprache zählen zu den Personenwagen (EMU, DMU). Das Kriterium zur Bestimmung, ob sich ein Personenwagen innerhalb der Bahnsteiggrenzen befindet, ist für Spielerzüge und KI-Züge unterschiedlich. Bei Spielerzügen wird an jedem Personenwaggon eine individuelle Prüfung durchgeführt, um zu prüfen, ob er sich innerhalb der Bahnsteiggrenzen befindet (es wird davon ausgegangen, dass dies in Ordnung ist, wenn mindestens zwei Drittel des Waggons innerhalb der Bahnsteiggrenzen liegen). Bei KI-Zügen wird stattdessen die Anzahl der Waggons + Lokomotiven innerhalb des Bahnsteigs berechnet, und alle davon, bis zur Anzahl der Personenwagen im Zugverband, werden als Personenwagen betrachtet. Die Einstiegszeit des Spielers oder des KI-Zugs wird zur tatsächlichen Ankunftszeit addiert, wodurch sich eine neue Abfahrtszeit ergibt. Diese neue Abfahrtszeit wird mit der geplanten Abfahrtszeit verglichen und der höhere Wert als tatsächliche Abfahrtszeit ausgewählt.

Ein Zug gilt als Personenzug, wenn mindestens ein Waggon (oder eine Lokomotive) Fahrgäste befördert.

KI-echte Güterzüge (0 Personenwagen) halten wie in MSTS 20 Sekunden an Bahnhöfen, wenn keine planmäßigen Startzeiten vorhanden sind. Wenn sie vorhanden sind, halten die Güterzüge bis zur geplanten Startzeit oder bis zur tatsächlichen Ankunftszeit plus 20 Sekunden an, je nachdem, welcher Wert höher ist.

Für Züge mit mehr als 10 Wagen und einem einzigen Personenwagen wurde ein Sonderverhalten eingeführt. Dieser Zugtyp wurde in MSTS verwendet, um die Möglichkeit zu haben, auch Fahrpläne für Güterzüge zu definieren. Diese Züge werden – wie MSTS – als Personenzüge mit den oben de nierten Regeln geführt. Für den Spielerzug wurde jedoch eine Vereinfachung für den Spieler eingeführt: Wenn der Zug mit dem einzelnen Personenwagen außerhalb des Bahnsteigs hält, gilt die Haltestelle weiterhin als gültig.

All dies ist mit dem MSTS-Betrieb kompatibel; Lediglich die Tatsache, dass bei AI-Zügen die planmäßige Abfahrtszeit berücksichtigt wird, unterscheidet sich, da dies als Verbesserung angesehen wird.

11.12.6 In Aktivitäten definierte Zonen mit eingeschränkter Geschwindigkeit

OR verwaltet Zonen mit eingeschränkter Geschwindigkeit, die in Aktivitäten als MSTS definiert sind. Der Beginn einer Geschwindigkeitsbeschränkungszone ist im Track MonitorWindow daran zu erkennen, dass die Höchstgeschwindigkeit rot angezeigt wird; Die Höchstgeschwindigkeit am Ende einer Geschwindigkeitsbeschränkungszone wird grün angezeigt.

11.13 Erweiterte KI-Zugrangierung

11.13.1 Allgemeines

Die Durchführung von Rangiervorgängen durch KI-Züge sorgt für interessantere und abwechslungsreichere Aktivitäten. Beachten Sie, dass diese Funktion im Fahrplanmodus nicht verfügbar ist, der andere Möglichkeiten zum Durchführen der KI-Zugrangierung bietet. Folgende zusätzliche Rangierfunktionen stehen zur Verfügung:

1. Der KI-Zug koppelt sich an einen statischen Zug und startet damit neu.

2. KI-Zug koppelt sich an einen Spieler oder KI-Zug und wird Teil davon; Der gekoppelte Zug setzt seine Strecke fort.

3. KI-Zug koppelt sich an einen Spieler oder KI-Zug und überlässt ihm seine Waggons; Der Kuppel- und Kuppelzug setzt seine Fahrt fort.

4. KI-Zug koppelt sich an einen Spieler oder KI-Zug und stiehlt dessen Waggons; Der Kuppel- und Kuppelzug setzt seine Fahrt fort.

5. KI-Zug koppelt beliebig viele Waggons ab; Der entkoppelte Teil wird zu einem statischen Verbund. Mit der gleichen Funktion ist es möglich, beliebig viele Wagen aus einem statischen Verbund zu koppeln.

6. KI-Zug koppelt an einen Spieler oder KI-Zug; Der resultierende kombinierte Zug fährt einen Teil der Strecke und hält dann an. Dort wird der Zug in zwei Teile geteilt, die auf eigenen Wegen weiterfahren (Join- und Split-Funktion).

7. Ein KI-Zug kann die Erlaubnis erhalten, bei Gefahr ein Signal zu passieren.

Diese Funktionen werden im Folgenden ausführlich beschrieben.

Eine Beispielaktivität finden Sie unter Documentation\SampleFiles\Manual\Show_AI_shunting_enh.zip.

11.13.2 Aktivitätsdesign für erweiterte KI-Zugrangierfunktionen

Das Aktivitätsdesign kann mit dem MSTS-Aktivitätseditor durchgeführt werden und erfordert keine Nachbearbeitung der erstellten Dateien

.

Erweiterte KI-Funktionen 1 bis 4 (alle mit Kopplung)

Es ist nicht immer erwünscht, dass KI-Züge an andere Züge gekoppelt werden; z.B. Die Aktivität hätte so gestaltet sein können, dass die Züge getrennt fahren, sich dann aber zur Laufzeit aufgrund von Zeitproblemen zur gleichen Zeit am selben Ort befinden könnten. In einem solchen Fall wäre es unerwünscht, dass die Züge kuppeln. Die Kopplung wird also nur dann aktiviert, wenn bestimmte Bedingungen erfüllt sind.

Im Allgemeinen gelten die Signalschutzregeln, das heißt, ein KI-Zug findet ein rotes Signal, wenn sein Weg ihn direkt zu einem anderen Zug führt. Generell können diese Funktionen also nur genutzt werden, wenn zwischen dem Kuppelzug und dem Kuppelzug keine Signale vorhanden sind. Dies kann jedoch auf drei Arten überwunden werden:

• durch den Aktivitätsentwickler, indem er einen doppelten Umkehrpunkt zwischen dem Signal und dem gekoppelten Zug einfügt (dies funktioniert nur, wenn der doppelte Umkehrpunkt nicht in dem Gleisabschnitt liegt, auf dem sich der gekoppelte Zug befindet).

• durch den Spieler, indem er das Signal mithilfe des Dispatcher-Fensters in den Status „Frei“ versetzt.

• oder noch besser, durch die Verwendung der erweiterten KI-Rangierfunktion Nr. 7, die weiter unten beschrieben wird und es dem KI-Zug ermöglicht, ein Signal bei Gefahr zu passieren. Die Kopplung mit einem statischen Verband unterliegt keinen anderen Bedingungen, denn wenn der Aktivitätsdesigner entschied, dass der Weg einen KI-Zug an einen statischen Verband führen würde, war es auch gewünscht, dass der KI-Zug daran gekoppelt würde.

Die Kopplung mit einem anderen KI-Zug oder mit dem Spielerzug unterliegt den folgenden Bedingungen. Entweder:

• die Kopplung im letzten Streckenabschnitt des koppelnden AI-Zugs erfolgt und der Streckenendpunkt unter dem gekoppelten Zug oder darüber hinaus im selben Abschnitt liegt, oder

• Die Kopplung erfolgt im letzten Abschnitt vor einem Umkehrpunkt des Kopplungs-AI-Zugs und der Umkehrpunkt liegt unter dem gekoppelten Zug oder darüber hinaus im selben Abschnitt.

Auf diese Weise werden unerwünschte Kopplungen vermieden, falls der KI-Zug über den gekoppelten Zug hinaus in die gleiche Richtung verläuft.

Unmittelbar nach der Kopplung führt OR eine weitere Prüfung durch, um festzulegen, was als nächstes passiert.

Für den Fall, dass der gekoppelte Zug statisch ist:

• Wenn es mindestens einen Umkehrpunkt weiter auf der Trasse gibt oder wenn es mehr als 5 Gleisabschnitte weiter auf der Trasse gibt, kuppelt der Kuppelzug mit dem statischen Zug, und dann fährt der resultierende gebildete Zug wieder auf der Strecke des Kuppelzuges fort , oder

• Wenn nicht, koppelt sich der Kupplungszug mit dem statischen Zug und wird Teil des statischen Zuges selbst (wird von ihm absorbiert), wodurch die Bewegung gestoppt wird.

Falls der gekoppelte Zug ein Spielerzug oder ein KI-Zug ist:

• Befindet sich unter dem Kuppelzug oder weiter im gleichen Gleisabschnitt mindestens eine Umkehrstelle, kuppelt der Kuppelzug mit dem Kuppelzug zusammen; An diesem Punkt gibt es zwei Möglichkeiten:

1. Der an den Kuppelzug gekoppelte Triebzug ist ein Waggon: In diesem Fall überlässt der Kuppelzug dem Kuppelzug alle Waggons zwischen seiner Lokomotive und dem Kuppelzug, kuppelt ab und bewegt sich auf seinem eigenen Weg weiter (er kann nur umkehren, weil). oben genannten Bedingungen). Der gekoppelte Zug folgt seinem eigenen Weg.

2. Der an den Kuppelzug gekoppelte Triebzug ist eine Lokomotive: In diesem Fall stiehlt der Kuppelzug dem Kuppelzug alle Waggons zwischen der Lokomotive des Kuppelzuges und dem Kuppelzug, kuppelt ab und bewegt sich auf seinem eigenen Weg weiter (er kann nur rückwärts fahren). aufgrund der oben genannten Bedingungen). Der gekoppelte Zug folgt seinem eigenen Weg.

• oder wenn sich weiter im Weg des Kuppelzugs kein Umkehrpunkt befindet, kuppelt der Kuppelzug mit dem Kuppelzug zusammen und wird dessen Teil (wird von ihm absorbiert). Der gekoppelte Zug folgt seinem eigenen Weg.

Nun zum Entwerfen von Pfaden:

• Wenn man möchte, dass der Kuppelzug vom Kuppelzug aufgenommen wird: einfach den Endpunkt der Trasse des Kuppelzuges unterhalb des Kuppelzuges oder weiter, aber im gleichen Gleisabschnitt legen.

• Wenn man möchte, dass sich der Kuppelzug nach dem Kuppeln mit dem Kuppelzug auf seiner Strecke weiterbewegt: Setzen Sie in der Strecke des Kuppelzuges einen Umkehrpunkt unterhalb des Kuppelzuges. Möchte man außerdem, dass der Kuppelzug nicht sofort wieder anfährt, sondern eine Pause einlegt, muss im Fahrweg des Kuppelzuges im Anschluss an den Umkehrpunkt ein Wartepunkt eingefügt werden. Es wird empfohlen, den Wartepunkt in der Nähe des Umkehrpunkts und auf jeden Fall im selben Gleisabschnitt zu platzieren. ODER führt den Wartepunkt aus, auch wenn er nicht genau darunter liegt. Nach dem An-/Abkuppeln bleibt vom Kuppelzug nur noch die Lokomotive übrig.

• Handelt es sich bei dem gekoppelten Zug um einen KI-Zug, muss dieser selbstverständlich an einem Wartepunkt angehalten werden, wenn er vom Kuppelzug gekoppelt werden soll.

Erweiterte KI-Funktion 5 (KI-Zug koppelt beliebig viele Waggons ab)

Um eine vordefinierte Anzahl an Wagen von einem KI-Zug abzukoppeln, muss ein spezieller Wartepunkt (WP) eingefügt werden. Das Format dieses Wartepunkts (in Dezimalschreibweise) ist normalerweise 4NNSS, wobei NN die Anzahl der Wagen vor dem KI-Zug ist, die NICHT abgekoppelt sind, einschließlich der Lokomotive, und SS die Dauer des Wartepunkts in Sekunden ist.

Das 5NNSS-Format wird ebenfalls akzeptiert. In diesem Fall besteht der verbleibende KI-Zug aus NN-Wagen (einschließlich Lokomotiven), die am Ende des Zuges beginnen. Natürlich muss sich in diesem Teil des Zuges mindestens eine Lokomotive befinden.

Es ist zu beachten, dass die „Vorderseite“ des KI-Zugs der Teil ist, der in der tatsächlichen Vorwärtsrichtung vorne am Zug liegt. Wenn der Verbund also mit der Lokomotive an erster Stelle erstellt wurde, befindet sich die Lokomotive bis zum ersten Umkehrpunkt an der Spitze. An diesem Punkt wird „vorne“ zum letzten Auto und so weiter.

Es ergeben sich folgende Möglichkeiten:

• Der KI-Zug fährt weiter und stoppt mit der Lokomotive vorne, möchte abkuppeln und in die gleiche Richtung weiterfahren: aWP mit dem Format 4NNSS wird an der Stelle eingefügt, an der der KI-Zug anhalten wird, wobei die Wagen ab der Lokomotive gezählt werden.

• Der KI-Zug fährt mit der Lokomotive am Ende weiter und möchte abkuppeln und in die umgekehrte Richtung weiterfahren: An der Stelle, an der der Zug anhalten wird, muss ein Umkehrpunkt gesetzt werden, und danach muss sequentiell ein 4NNSS-WP gesetzt werden Umkehrpunkt, irgendwo unter dem Teil des Zuges, der beim Zug verbleibt, formatiert wie oben. Da der Zug an der Umkehrstelle die Richtung geändert hat, werden die Wagen erneut beginnend bei der Lokomotive gezählt.

• Die KI-Lokomotive fährt weiter und koppelt an einen losen Verbund und möchte nur einen Teil davon erhalten: Ein Umkehrpunkt wird unter dem losen Verbund eingefügt, und ein 4NNSS-WP wird nacheinander nach dem Umkehrpunkt irgendwo unter dem Teil des Zuges eingefügt Zug, der beim Zug verbleibt, formatiert wie oben.

Was derzeit NICHT möglich ist, ist die Möglichkeit, den KI-Zug an den Spielerzug oder an einen anderen KI-Zug zu koppeln und ihm eine vordefinierte Anzahl an Waggons zu „stehlen“. Mit den derzeit verfügbaren Funktionen ist es nur möglich, alle Autos zu stehlen oder alle Autos zu überholen. Wenn gewünscht ist, dass nur eine bestimmte Anzahl von Waggons von einem KI- oder Spielerzug an einen anderen übergeben werden soll, muss der erste KI-Zug diese Waggons wie oben beschrieben abkoppeln, sich dann ein Stück vorwärts bewegen und dann den zweiten KI-Zug ankuppeln lassen diese Autos.

Funktion 6 (Verbinden und Teilen)

Einführung

Verbinden und Teilen bedeutet, dass zwei Züge (KI oder Spieler) jeweils auf ihrem eigenen Weg losfahren. dann schließen sie sich zusammen und laufen gemeinsam einen Teil ihres Weges, und dann trennen sie sich und laufen jeder auf seinem eigenen Weg weiter (in die gleiche Richtung oder in entgegengesetzte Richtungen).

Dies kann z.B. die folgenden Beispielanwendungen:

Anwendung 1:

• ein Paar Hilfslokomotiven, die hinten oder vorne an einen langen Zug gekoppelt werden;

• der resultierende Zug fährt bergauf;

• Oben angekommen koppeln die Hilfslokomotiven vom Zug ab.

– Wenn die Hilfslokomotiven am Ende des anderen Zuges angekoppelt waren, fährt der Zug auf seiner Strecke vorwärts, während die Hilfslokomotiven bergab zurückfahren.

– Wenn die Helfer an der Front angekoppelt waren, fahren die Helfer auf ein Abstellgleis und halten an; Der Zug setzt seinen Weg vorwärts fort, und wenn der Zug vorbeigefahren ist, können die Helfer rückwärts fahren und bergab zurückkehren.

Dadurch kann ein kompletter Helferzyklus simuliert werden.

Anwendung 2:

• Ein Personenzug besteht aus zwei zusammengefügten Teilen (z. B. zwei Abschnitten eines HST);

• der Zug erreicht einen Zwischenbahnhof und die beiden Abschnitte entkoppeln;

• Ein Abschnitt nimmt die Hauptstrecke auf, während der andere eine Nebenstrecke nimmt (dies kann für beide Züge in jede Richtung erfolgen).

• Sowohl der sich verbindende Zug (derjenige, der sich bewegt und mit dem anderen Zug koppelt – der verbundene Zug) als auch der verbundene Zug können ein KI-Zug oder ein Spielerzug sein.

Aufgabenentwicklung

1) Die beiden Züge starten als separate Züge, koppeln sich zusammen und entkoppeln sich später im Spiel. Danach können solche Züge natürlich an andere Züge gekoppelt werden und so weiter.

2) Der Kuppelzug wird nach dem Kuppeln zu einem „integrierten“ Zug, das heißt, er hat keine Waggons oder Lokomotiven mehr (sie werden alle Teil des Kuppelzuges) und ist eine Art virtueller Zug. In dieser Phase wird es nicht im Dispatcher-Informations-HUD angezeigt. Es erwacht wieder zum Leben, wenn ein Entkupplungsbefehl (automatisch oder manuell) gegeben wird.

3) Um ein „Incorporated“-Zug zu werden, muss der Kuppelzug, wenn er vom Typ AI ist, auf seinem Weg vor dem Kuppeln einen Wartepunkt mit dem Wert 60001 passieren (die effektive Wartezeit beträgt 0 Sekunden); Ein solcher WP ist nicht erforderlich, wenn der Koppelzug der Spielerzug ist.

4) Für das Ankuppeln des Kuppelzuges an die Rückseite des Kuppelzuges bestehen keine besonderen Anforderungen; Wenn Sie jedoch sehr kurze Strecken vom Start des Zuges bis zum Moment des Kuppelns haben möchten, kann es notwendig sein, dazwischen ein paar Umkehrpunkte einzufügen, sonst könnte der Zug anhalten und das Kuppeln vermeiden. Bitte verachten Sie Doppelumkehrungen nicht: Sie sind manchmal die einzige Möglichkeit, den Autoritätsbereich eines Zuges einzuschränken.

5) Wenn der Kuppelzug an der Vorderseite des Kuppelzuges ankuppeln muss, ist für den Kuppelzug natürlich ein Umkehrpunkt erforderlich: Er muss irgendwo unter dem Kuppelzug oder noch weiter unten im gleichen Gleisabschnitt verlegt werden; Auch in diesem Fall kann es ein Autoritätsproblem geben, das erfordern könnte, dass der gekoppelte Zug nach dem Punkt, an dem er auf das Kuppeln wartet, einige Umkehrpunkte hat.

6) Der eingegliederte Zug verfügt über eine eigene Trasse, muss aber vom Kupplungs- bis zum Entkupplungspunkt über dieselben Gleisabschnitte der Trasse des eingliedernden Zuges fahren. Der eingebundene Zug darf im gemeinsamen Gleisteil weder Wartestellen noch Haltestellen haben (der gekoppelte Zug kann diese jedoch haben). Kommt es zu Umkehrungen innerhalb des gemeinsamen Pfadteils, müssen diese in beiden Pfaden vorhanden sein.

7) Zum Zeitpunkt der Entkopplung kann die Anzahl der vom Zug abzukoppelnden Waggons und Lokomotiven von der Anzahl des ursprünglichen Zuges abweichen.

8) Der gesamte abzukoppelnde Zugteil muss auf demselben Gleisabschnitt liegen. Nach der Entkopplung ist der „eingebaute“ Zug wieder ein Standard-KI-Zug.

9) Die manuelle Entkopplung (für Spielerzüge) erfolgt über das F9-Fenster; Die automatische Entkopplung erfolgt mit den Befehlen 4NNSS und 5NNSS (siehe vorheriger Absatz); Die erste muss verwendet werden, wenn sich der abzukoppelnde Teil am Ende des Zuges befindet, und die zweite, wenn sich der Teil am Anfang des Zuges befindet.

10) Im Regelfall, dass der Hauptteil des Zuges in die gleiche Richtung weiterfährt, können folgende Fälle auftreten:

• Liegt der abgekoppelte Teil vorne, kann dieser abgekoppelte Teil nur in die gleiche Richtung (vor dem Hauptteil des Zuges) weiterfahren. Um zu vermeiden, dass er unmittelbar nach dem Abkoppeln startet, ist es sinnvoll, im Weg des abgekoppelten Zuges einen WP von einigen zehn Sekunden einzustellen. Dieser WP kann am Anfang des Abschnitts eingestellt werden, in dem die Entkopplung erfolgt; OR verschiebt es unter das entkoppelte Teil, sodass Sie bei der Positionierung nicht genau sein müssen.

• Liegt der entkoppelte Teil auf der Rückseite, sind zwei Fälle möglich: Entweder der entkoppelte Teil kehrt sich um oder der entkoppelte Teil läuft in die gleiche Richtung weiter. Im ersten Fall muss an einer beliebigen Stelle im Abschnitt, an dem die Entkopplung erfolgt, ein Umkehrpunkt platziert werden (besser am Ende des Abschnitts), und OR verschiebt ihn an die richtige Stelle, sodass der Zug an der Stelle, an der die Entkopplung erfolgte, rückwärts fährt; Darüber hinaus wird auch empfohlen, einen WP von einigen zehn Sekunden festzulegen, damit der Zug nicht sofort wieder anfährt. Dieser WP muss logischerweise hinter dem Umkehrpunkt und im selben Gleisabschnitt liegen; ODER verschiebt es unter den entkoppelten Zug.

• Wenn der entkoppelte Teil in die gleiche Richtung verläuft, sind weder WP noch RP erforderlich. Dieser Zugteil wartet, bis der vorausfahrende Teil den Weg frei macht, bevor er losfährt.

Hinweise zum Aktivitätslauf

• Wenn Sie als Spieler laufen, müssen Sie den Zug an der von der Aktivität vorgesehenen Stelle abkuppeln (der abgekuppelte Zug muss in einem Streckenabschnitt auf seinem Weg liegen). Wenn Sie nicht auf einem Gleisabschnitt im Fahrweg des abgekoppelten Zuges abkuppeln, wird der abgekuppelte Zug zu einem statischen Zug, da er sich nicht auf seinem Weg befindet.

• Sie können den Zug, der aus dem ursprünglichen Zug und dem eingegliederten Zug besteht, von jedem Führerstand aus fahren (auch in einem Führerstand des eingegliederten Zuges). Vor dem Abkuppeln (Aufteilen) der Züge müssen Sie jedoch zu einem Führerstand des ursprünglichen Zuges zurückkehren.

Funktion 7 (Erlaubnis, Signal bei Gefahr für KI-Zug weiterzugeben)

Beim Rangieren von KI-Zügen gibt es Fälle, in denen es erforderlich ist, dass der KI-Zug bedingt in der Lage ist, ein rotes Signal zu passieren, ähnlich wie die Züge des Spielers, wenn sie die Tabulatortaste drücken.

Dies kann erreicht werden, indem ein spezifischer WP mit dem Wert 60002 definiert wird, der im AI-Zugweg vor dem zu passierenden Signal (im Gleisabschnitt direkt vor dem Signal) festgelegt wird.

11.14 Signalbezogene Dateien

Für Content-Entwickler

OR verwaltet Signale, wie sie in den Dateien sigcfg.dat und sigscr.dat definiert sind, auf eine Weise, die hochkompatibel zu MSTS ist. Eine Beschreibung ihres Inhalts und wie diese beiden Dateien geändert werden können, ist im Word-Dokument How_to_make_Signal_config_and_Script_files.doc enthalten, das sich im Ordner TECH DOCS einer MSTS-Installation befindet. Beachten Sie, dass diese Dateien mit einem Unicode-Texteditor bearbeitet werden müssen.

Darüber hinaus steht eine C#-Skriptschnittstelle zur Ergänzung der Datei „sigscr.dat“ für komplexere Systeme zur Verfügung.

11.14.1 SignalNumClearAhead

Für den sigcfg.dat-Parameter SignalNumClearAhead() gelten jedoch bestimmte Regeln, die von MSTS nicht konsistent verwaltet werden.

In diesem Absatz wird der Standardfall besprochen, bei dem sich sigcfg.dat und sigscr.dat im Stammverzeichnis der Route befinden.

Wenn für einen SignalType nur ein SignalNumClearAhead() definiert ist (wie es in MSTS-Dateien Standard ist), dann definiert dieser Parameter die Anzahl der NORMALEN Signalköpfe (keine Signale!), die entlang der Route gelöscht werden, einschließlich der Signalköpfe der Signal, in dem sich der SignalType befindet. Dies ist nicht ganz so wie bei MSTS, wo recht komplexe und seltsame Berechnungen durchgeführt werden, die in manchen Fällen dazu führen können, dass zu wenige Signale für einen zufriedenstellenden Zugbetrieb freigegeben werden. Darüber hinaus berücksichtigt MSTS nicht die SignalNum-

Der ClearAhead()-Wert bezieht sich auf das Signal, ist jedoch der maximale SignalNumClearAhead()-Wert, der in den in der Route verwendeten Signaltypen auftritt. Wenn daher gewünscht wird, dass OR sich der MSTS-Operation annähert, muss der Wert von SignalNumClearAhead() aller Signale auf den gleichen Maximalwert gesetzt werden. Um zu vermeiden, dass auch der MSTS-Betrieb beeinträchtigt wird, gibt es zwei Ansätze, die im Folgenden beschrieben werden.

Wenn für einen SignalType ein zweiter SignalNumClearAhead()-Parameter direkt vor dem vorhandenen hinzugefügt wird, interpretiert OR ihn als die Anzahl der NORMALSIGNALE, die entlang der Route gelöscht werden, einschließlich des Signals, in dem sich der SignalType befindet.

MSTS überspringt dieses erste SignalNumClearAhead() und berücksichtigt nur das zweite. Somit hat diese Änderung an sigcfg.dat keine Auswirkungen auf die Verwendung in MSTS.

Anstatt jedoch die Kopie der Datei sigcfg.dat im Stammverzeichnis der Route zu ändern, wird der im nächsten Absatz beschriebene Ansatz empfohlen.

11.14.2 Speicherort der OR-spezifischen sigcfg- und sigscr-Dateien

Durch einfaches Kopieren der ursprünglichen Dateien sigscr.dat und sigcfg.dat in einen Unterordner namens OpenRails, der im Hauptordner der Route erstellt wurde, berücksichtigt OR das Dateipaar im Stammordner der Route nicht mehr und interpretiert das (einzelne) SignalNumClearAhead ()-Zeile als Definition der Anzahl der gelöschten Signale. OR interpretiert sigscr.dat also unterschiedlich, je nachdem, ob sich eine Kopie dieser Datei im OpenRails-Unterordner befindet oder nicht. Auf diese Weise wird in der Regel das Problem gelöst, dass zu wenige Signale für einen zufriedenstellenden Zugbetrieb freigegeben sind.

Wenn sich dieser einzeilige Standard sigscr.dat jedoch auch beim Zählen von Signalen nicht zufriedenstellend verhält (ein Grund wurde im vorherigen Absatz beschrieben), muss er für ODER optimiert werden, indem der Parameter SignalNumClearAhead () für die nicht zufriedenstellenden Signale geändert wird. Bei Bedarf kann die Linie so bleiben, wie sie ist, und eine optimierte Linie kann vor der vorhandenen hinzugefügt werden, und die Signale werden erneut gezählt. In diesem Fall verhält sich die Datei sigscr.dat genauso, als ob sie sich im Stammordner der Route befinden würde.

Sigcfg.dat muss seinen Namen behalten, während die Sigscr-Dateien auch andere Namen haben können, sofern in sigcfg.dat ein Verweis auf diese anderen Namen vorhanden ist.

11.14.3 ODER-eindeutige Werte für SignalNumClearAhead ()

OR erkennt zwei zusätzliche eindeutige Werte des Parameters SignalNumClearAhead(), wenn sich dieser Parameter in einer Zeile vor der Zeile mit dem MSTS-Wert befindet oder wenn sich die Datei sigcfg.dat im Unterordner OpenRails befindet:

• 0: Über dieses Signal hinaus wird kein Signal gelöscht, bis der Zug dieses Signal passiert.

• -1: Signal zählt nicht, wenn die Anzahl der zu löschenden Signale bestimmt wird.

11.14.4 C#-Signalskripting

Um besonders komplexes Verhalten zu simulieren, stellt Open Rails eine C#-Skriptschnittstelle für Signale bereit. Diese Skripte werden in .cs-Dateien mit C#-Klassen geschrieben, aber zur Laufzeit kompiliert und verknüpft, sodass sie nicht von Änderungen im Kernprogramm selbst abhängig sind und mit der Route verteilt werden können.

C#-Signalskripte werden im Unterordner „Script/Signal“ im Hauptordner der Route abgelegt. Alle in diesem Ordner vorhandenen C#-Dateien werden zur Laufzeit in einer einzigen Assembly kompiliert.

Für jeden in der Datei sigcfg.dat definierten Signaltyp versucht OR, eine Klasse mit demselben Namen wie der Signaltyp in der kompilierten Assembly zu finden. Treten Kompilierungsfehler auf oder wird keine Klasse mit dem erforderlichen Namen gefunden, wird stattdessen das in der Datei sigscr.dat definierte Skript verwendet, sofern dort ein entsprechendes Skript vorhanden ist.

Jedes Signalskript muss sich im ORTS.Scripting.Script-Namespace befinden und von der CsSignalScript-Klasse erben, die alle für das Skript verfügbaren API-Funktionen enthält.

Dieses Beispiel veranschaulicht den für ein Signalskript erforderlichen Mindestcode:

Verwenden des Systems;

mit Orts.Simulation.Signalling;

Namensraum ORTS.Scripting.Script

{

öffentliche Klasse MYSIGNALTYPE: CsSignalScript

{

öffentliches Override void Initialize()

{

// Führen Sie hier unter Berücksichtigung einige Initialisierungen durch

// dass derzeit keine Routeninformationen verfügbar sind

}

öffentliches Override void Update()

{

// Stellen Sie hier den Aspekt Ihres Signals je nach Routenstatus ein

}

öffentliche Überschreibung void HandleSignalMessage(int signalId, string message) {}

}

}

Eine Liste der für Signalskripte verfügbaren API-Aufrufe finden Sie in der Datei Orts.Simulation/Simulation/Signalling/CsSignalScript.cs im OR-Quellcode.

Zur Beschleunigung des Entwicklungsprozesses kann eine Entwicklungsumgebung eingerichtet werden. Weitere Informationen finden Sie im Abschnitt zur Engine-Skripterstellung.

11.15 OR-spezifische Signalisierungsfunktionen

Es steht eine Reihe leistungsstarker OR-spezifischer Signalfunktionen zur Verfügung. Sigcfg- und sigscr-Dateien, die sich auf diese Funktionen beziehen, müssen wie im vorherigen Absatz beschrieben lokalisiert werden.

11.15.1 SPEED-Signale – ein neuer Signalfunktionstyp

Der Signalfunktionstyp SPEED ermöglicht die Verwendung einer Signalobjektmarkierung als Geschwindigkeitszeichen.

Die Vorteile einer solchen Nutzung sind:

• Die Signalobjektmarkierung gilt nur für das Gleis, auf dem sie platziert ist. Originale Geschwindigkeitsschilder wirken sich immer auch auf benachbarte Strecken aus, so dass es in komplexen Gebieten schwierig und manchmal unmöglich ist, eine bestimmte Geschwindigkeitsbegrenzung nur auf einer Strecke festzulegen.

• Als Signalobjekt kann das SPEED-Signal mehrere Zustände definieren und eine Skriptfunktion zur Auswahl des erforderlichen Zustands, z. B. basierend auf der Routenauswahl. Dadurch können unterschiedliche Geschwindigkeitsbegrenzungen für unterschiedliche Strecken durch das Gebiet definiert werden, z.B. Es gibt keine Begrenzung für die Hauptstrecke, aber spezifische Beschränkungen für eine Reihe abweichender Strecken.

Das SPEED-Signal wird vollständig als Geschwindigkeitsbegrenzung und nicht als Signal verarbeitet und hat keine Auswirkung auf andere Signale.

Einschränkung: Es ist nicht möglich, unterschiedliche Geschwindigkeiten je nach Zugtyp (Personen- oder Güterzug) zu definieren.

Definition und Verwendung

Die Definition ähnelt der jedes anderen Signals, wobei SignalFnType auf SPEED eingestellt ist.

Es ermöglicht die Definition von Drawstates und Aspekten wie jedes andere Signal. Wie üblich können pro Aspekt unterschiedliche Geschwindigkeitswerte definiert werden.

Ein Aspekt kann so eingestellt werden, dass er kein aktives Geschwindigkeitslimit hat. Wenn dieser Aspekt aktiv ist, wird die Geschwindigkeitsbegrenzung nicht geändert. Dies kann beispielsweise genutzt werden, wenn eine streckengebundene Geschwindigkeitsbegrenzung erforderlich ist. Dieser Aspekt kann dann für eine Strecke eingestellt werden, für die keine Geschwindigkeitsbegrenzung erforderlich ist.

Ein Aspekt kann auch so eingestellt werden, dass er kein aktives Geschwindigkeitslimit hat, aber mit einem speziellen Signalflag: OR_SPEEDRESET.

Wenn dieses Flag gesetzt ist, wird die Geschwindigkeitsbegrenzung auf die durch das letzte Geschwindigkeitsbegrenzungsschild festgelegte Grenze zurückgesetzt. Damit können alle durch einen bestimmten Signalaspekt vorgegebenen Grenzwerte zurückgesetzt werden. Beachten Sie, dass dadurch keine durch ein anderes SPEED-Signal festgelegten Geschwindigkeitsbegrenzungen außer Kraft gesetzt werden, da diese Begrenzungen so verarbeitet werden, als ob sie durch ein Geschwindigkeitsbegrenzungsschild festgelegt würden.

SignalType ("SpeedSignal"

SignalFnType ( SPEED )

SignalLightTex ( "ltex" )

SignalDrawStates ( 5

SignalDrawState ( 0

"speed25"

)

SignalDrawState ( 1

"speed40"

)

SignalDrawState ( 2

"speed50"

)

SignalDrawState ( 3

"speed60"

)

SignalDrawState ( 4

"speed70"

)

)

SignalAspects ( 5

SignalAspect ( APPROACH_1 "speed25" SpeedMPH ( 25 ) )

SignalAspect ( APPROACH_2 "speed40" SpeedMPH ( 40 ) )

SignalAspect ( APPROACH_3 "speed50" SpeedMPH ( 50 ) )

SignalAspect ( CLEAR_1 "speed60" SpeedMPH ( 60 ) )

SignalAspect ( CLEAR_2 "speed70" SpeedMPH ( 70 ) )

)

SignalNumClearAhead ( 2 )

)

Anmerkungen:

• Der SignalNumClearAhead-Wert muss aus Gründen der Syntax enthalten sein, hat aber keine Funktion.

• Die tatsächliche Geschwindigkeit kann entweder über eine feste Aspektauswahl über Benutzerfunktionen eingestellt oder mit der Route verknüpft werden.

Die tatsächliche Verwendung wird im zugehörigen Skript und der zugehörigen Formdefinition definiert.

Beispiel 2:

SignalType ( "SpeedReset"

SignalFnType ( SPEED )

SignalLightTex ( "ltex" )

SignalDrawStates ( 1

SignalDrawState ( 0

"Red"

)

)

SignalAspects ( 1

SignalAspect ( STOP "Red" signalflags (OR_SPEEDRESET) )

)

SignalNumClearAhead ( 2 )

)

In diesem Beispiel wird die Geschwindigkeit auf die durch das letzte Geschwindigkeitsschild festgelegte Grenze zurückgesetzt und alle durch Signalaspekte festgelegten Geschwindigkeitsbegrenzungen außer Kraft gesetzt.

11.15.2 Annäherungskontrollfunktionen

Vorfahrtkontrollsignale werden insbesondere im Vereinigten Königreich verwendet, um ein Signal in „Gefahr“ zu halten, bis sich der Zug in einem bestimmten Abstand vor dem Signal befindet oder seine Geschwindigkeit auf einen bestimmten Wert reduziert hat. Eine solche Steuerung wird für abzweigende Strecken eingesetzt, um sicherzustellen, dass die Geschwindigkeit des Zuges ausreichend reduziert wird, um die Weichen auf der abzweigenden Strecke sicher zu befahren.

Es wurden drei Skriptfunktionen für den Einsatz in OR definiert, mit denen das Signal so lange gesteuert werden kann, bis der Zug eine bestimmte Position erreicht oder seine Geschwindigkeit reduziert hat.

Diese Funktionen sind:

APPROACH_CONTROL_POSITION(Position)

APPROACH_CONTROL_POSITION_FORCED(Position)

APPROACH_CONTROL_SPEED(Position, Geschwindigkeit)

Bei diesen Funktionen handelt es sich um boolesche Funktionen: Der zurückgegebene Wert ist „wahr“, wenn sich ein Zug dem Signal nähert, sich innerhalb der erforderlichen Entfernung zum Signal befindet und für APPROACH_CONTROL_SPEED seine Geschwindigkeit unter die erforderlichen Werte reduziert hat.

Die Funktion APPROACH_CONTROL_POSITION_FORCED ähnelt der Funktion APPROACH_CONTROL_POSITION, kann jedoch mit jeder Art von Signal verwendet werden. In der Zwischenzeit erfordert APPROACH_CONTROL_POSITION NORMAL-Signale und löscht das Signal nur, wenn es das nächste Signal des Zuges ist.

Parameter:

• Position: erforderliche Entfernung des Zuges, der sich dem Signal nähert, in Metern

• Geschwindigkeit: erforderliche Geschwindigkeit in m/s

Beachten Sie, dass die Geschwindigkeit nur überprüft wird, wenn sich der Zug innerhalb der definierten Entfernung befindet.

Wichtiger Hinweis: Obwohl das Skript „float“ verwendet, um lokale Variablen zu definieren, handelt es sich in Wirklichkeit ausschließlich um Ganzzahlen. Dies gilt auch für die in diesen Funktionen verwendeten Werte: Werden direkte Werte verwendet, müssen diese ganzzahlige Werte sein.

Die Werte können direkt im Signalskript eingestellt werden, entweder als Variablen oder als Zahlen im Funktionsaufruf.

Es ist jedoch auch möglich, die erforderlichen Grenzwerte im Rahmen der Signaldefinition in der Datei sigcfg.dat zu definieren.

Die Syntaxdefinition hierfür lautet:

ApproachControlLimits ( <definitions> )

Zulässige Definitionen:

• Position:

– Positionm: Position in Metern.

– Positionkm: Position in Kilometern.

– Positionmiles: Position in Meilen.

– Positionyd: Position in Yards.

• Geschwindigkeit :

– Speedkph: Geschwindigkeit in km/Stunde.

– Speedmph: Geschwindigkeit in Meilen/Stunde.

Auf diese Werte wird in der Skriptdatei mithilfe der folgenden Variablennamen verwiesen:

• Approach_Control_Req_Position

• Approach_Control_Req_Speed

Diese Variablen müssen nicht als Floats etc. definiert werden, sondern können ohne vorherige Definition direkt verwendet werden.

Beachten Sie, dass die in der Datei sigcfg.dat definierten Werte in Meter und Meter/Sek. konvertiert und auf den nächsten ganzzahligen Wert gerundet werden.

Das folgende Beispiel bezieht sich auf ein dreiköpfiges Suchlichtsignal, das die Anfahrkontrolle verwendet, wenn die Route auf den „unteren“ Kopf eingestellt ist.

Die Routenauswahl erfolgt über „Dummy“-DISTANCE-Routenauswahlsignale.

Signaldefinition:

SignalType ( "SL_J_40_LAC"

SignalFnType ( NORMAL )

SignalLightTex ( "bltex" )

SigFlashDuration ( 0.5 0.5 )

SignalLights ( 8

SignalLight ( 0 "Red Light"

Position ( 0 6.3 0.11 )

Radius ( 0.125 )

)

SignalLight ( 1 "Amber Light"

Position ( 0 6.3 0.11 )

Radius ( 0.125 )

)

SignalLight ( 2 "Green Light"

Position ( 0 6.3 0.11 )

Radius ( 0.125 )

)

SignalLight ( 3 "Red Light"

Position ( 0 4.5 0.11 )

Radius ( 0.125 )

)

SignalLight ( 4 "Amber Light"

Position ( 0 4.5 0.11 )

Radius ( 0.125 )

)

SignalLight ( 5 "Green Light"

Position ( 0 4.5 0.11 )

Radius ( 0.125 )

)

SignalLight ( 6 "Amber Light"

Position ( 0 2.7 0.11 )

Radius ( 0.125 )

)

SignalLight ( 7 "White Light"

Position ( 0 2.7 0.11 )

Radius ( 0.125 )

)

)

SignalDrawStates ( 8

SignalDrawState ( 0

"Red"

DrawLights ( 1

DrawLight ( 0 )

)

)

SignalDrawState ( 1

"TopYellow"

DrawLights ( 1

DrawLight ( 1 )

)

)

SignalDrawState ( 2

"TopGreen"

DrawLights ( 1

DrawLight ( 2 )

)

)

SignalDrawState ( 3

"TopYellowMidGreen"

DrawLights ( 2

DrawLight ( 1 )

DrawLight ( 5 )

)

)

SignalDrawState ( 4

"MidYellow"

DrawLights ( 2

DrawLight ( 0 )

DrawLight ( 4 )

)

)

SignalDrawState ( 5

"MidGreen"

DrawLights ( 2

DrawLight ( 0 )

DrawLight ( 5 )

)

)

SignalDrawState ( 6

"LowYellow"

DrawLights ( 3

DrawLight ( 0 )

DrawLight ( 3 )

DrawLight ( 6 )

)

)

SignalDrawState ( 7

"LowWhite"

DrawLights ( 3

DrawLight ( 0 )

DrawLight ( 3 )

DrawLight ( 7 SignalFlags ( FLASHING ))

)

)

)

SignalAspects ( 8

SignalAspect ( STOP "Red" )

SignalAspect ( STOP_AND_PROCEED "LowWhite" SpeedMPH(25) )

SignalAspect ( RESTRICTING "LowYellow" SpeedMPH(25) )

SignalAspect ( APPROACH_1 "MidYellow" SpeedMPH(40) )

SignalAspect ( APPROACH_2 "TopYellowMidGreen" )

SignalAspect ( APPROACH_3 "TopYellow" )

SignalAspect ( CLEAR_1 "MidGreen" SpeedMPH(40) )

SignalAspect ( CLEAR_2 "TopGreen" )

)

ApproachControlSettings (

PositionM ( 500 )

SpeedMpH ( 10 )

)

SignalNumClearAhead ( 5 )

)

Signalfunktion (reduziert, um nur die Verwendung der Annäherungskontrolle anzuzeigen). Diese Funktion nutzt die Anflugkontrolle für die „untere“ Route:

SCRIPT SL_J_40_LAC

// Searchlight Top Main Junction

extern float block_state ();

extern float route_set ();

extern float def_draw_state ();

extern float next_sig_lr ();

extern float sig_feature ();

extern float state;

extern float draw_state;

extern float enabled;

//

// Returned states

// drawn :

// SIGASP_STOP

//

// Top Cleared :

// SIGASP_APPROACH_3

// SIGASP_APPROACH_2

// SIGASP_CLEAR_2

//

// Middle Cleared :

// SIGASP_APPROACH_1

// SIGASP_CLEAR_1

//

// Lower Cleared :

// SIGASP_RESTRICTING

// SIGASP_STOP_AND_PROCEED

//

// User Flags

//

// USER1 : copy top approach

// USER2 : top approach junction

// USER3 : copy middle approach

// USER4 : no check block for lower

//

float clearstate;

float setstate;

float diststate;

float adiststate;

float nextstate;

float routestate;

float blockstate;

blockstate = 0;

clearstate = 0;

routestate = 0;

setstate = 0;

nextstate = next_sig_lr(SIGFN_NORMAL);

diststate = next_sig_lr(SIGFN_DISTANCE);

adiststate = diststate;

if (diststate ==# SIGASP_CLEAR_1)

{

diststate = SIGASP_CLEAR_2;

}

if (diststate ==# SIGASP_APPROACH_1)

{

diststate = SIGASP_APPROACH_3;

}

// get block state

if (!enabled)

{

clearstate = -1;

}

if (block_state () ==# BLOCK_JN_OBSTRUCTED)

{

clearstate = -1;

}

if (block_state() ==# BLOCK_OCCUPIED)

{

blockstate = -1;

}

// check if distant indicates correct route

if (diststate ==# SIGASP_STOP)

{

clearstate = -1;

}

// top route

state = SIGASP_STOP;

if (blockstate == 0 && clearstate == 0 && diststate ==# SIGASP_CLEAR_2)

{

// aspect selection for top route (not shown)

.......

}

// middle route

if (blockstate == 0 && clearstate == 0 && diststate ==# SIGASP_APPROACH_3)

{

// aspect selection for middle route (not shown)

.......

}

// lower route

if (blockstate == 0 && clearstate == 0 && diststate ==# SIGASP_RESTRICTING)

{

if (Approach_Control_Speed(Approach_Control_Req_Position, Approach_Control_Req_Speed))

{

state = SIGASP_RESTRICTING;

}

}

// Get draw state

draw_state = def_draw_state (state);

11.15.3 TrainHasCallOn-, TrainHasCallOn_Advanced-Funktionen

Diese Funktion ist speziell dazu gedacht, Zügen das „Anrufen“ im Fahrplanmodus zu ermöglichen, wenn dies im Fahrplan festgelegt ist. Die Verwendung dieser Funktion ermöglicht es einem Zug, im Fahrplanmodus einen Bahnsteig anzufahren, ohne die Funktionalität im normalen Aktivitätsmodus zu beeinträchtigen.

Die Funktion TrainHasCallOn öffnet das Signal nur, wenn der Zug vor dem Signal am Block angekommen ist. Wenn das Signal früher geöffnet werden soll, verwenden Sie stattdessen die Funktion TrainHasCallOn_Advanced. Das Öffnen des Signals erfolgt dann nach den Regeln des Sigcfg.dat-Parameters SignalNumClearAhead().

Es ist eine boolesche Funktion und gibt den Status wie folgt zurück:

• Aufgabenmodus:

– Gibt true zurück, wenn:

* Die Route vom Signal führt nicht zu einem Bahnsteig.

• Fahrplanmodus:

– Gibt true zurück, wenn:

* Die Route vom Signal führt nicht zu einem Bahnsteig.

* Die Route vom Signal führt zu einem Bahnsteig und der Zug hat eine gebuchte Haltestelle auf diesem Bahnsteig und einer der folgenden Zustände ist wahr:

· Der Zug verfügt über den $CallOn-Befehlssatz für diese Station.

· Der Zug verfügt über den $Attach-Befehl für diesen Bahnhof und der Zug auf dem Bahnsteig ist der Zug, an den er angeschlossen werden muss.

· Der Zug ist Teil des RunRound-Befehls und wird an den Zug angeschlossen, der sich gerade auf dem Bahnsteig befindet.

Darüber hinaus geben diese Funktionen sowohl im Zeitplan- als auch im Aktivitätsmodus „true“ zurück, wenn die Option „CallOn“ aus dem Kontextmenü des Signals im Dispatcher-Fenster ausgewählt wird.

Die Nutzung dieser Funktion muss mit einer Prüfung kombiniert werden auf:

blockstate ==# BLOCK_OCCUPIED

Hinweis: Diese Funktion darf NICHT in Kombination mit Folgendem verwendet werden:

blockstate ==# JN_OBSTRUCTED

Mit dem Zustand JN_OBSTRUCTED wird angezeigt, dass die Strecke für den Zug nicht befahrbar ist (z. B. Weiche gegen den Zug gestellt, Gegenfahrt stattfindet etc.).

Einige Signalskripte ermöglichen das Löschen von Signalen bei blockstate ==# JN_OBSTRUCTED. Dies kann zu allen möglichen Fehlsituationen führen. Diese Probleme sind nicht auf Programmierfehler zurückzuführen, sondern auf Fehler im Routing-Signal-Skript.

Beispiel (nur Teil des Skripts):

if (enabled && route_set() )

{

if (block_state == #BLOCK_CLEAR)

{

// normal klar, z.B.

state = #SIGASP_CLEAR_1;

}

else if (block_state == #BLOCK_OCCUPIED && TrainHasCallOn() )

{

// bei besetztem Gleis löschen und CallOn erlaubt

state = #SIGASP_STOP_AND_PROCEED;

}

anders

{

// Spur ist nicht klar oder CallOn nicht erlaubt

state = #SIGASP_STOP;

}

}

11.15.4 TrainHasCallOn_Restricted-, TrainHasCallOn_Restricted_Advanced-Funktionen

Diese Funktion wurde eingeführt, da Signale mit Aufrufaspekten nicht nur als Einfahrtssignale für Bahnhöfe, sondern auch auf „freien Streckenabschnitten“, also abseits von Bahnhöfen, verwendet werden können.

Die Funktion TrainHasCallOn_Restricted öffnet das Signal nur, wenn der Zug vor dem Signal am Block angekommen ist. Wenn das Signal früher geöffnet werden soll, verwenden Sie stattdessen die Funktion TrainHasCallOn_Restricted_Advanced. Das Öffnen des Signals folgt dann den Regeln des Sigcfg.dat-Parameters SignalNumClearAhead().

In den nächsten Zeilen, in denen TrainHasCallOn erscheint, sind TrainHasCallOn und TrainHasCallOn_Advanced gemeint; Wenn TrainHasCallOn_Restricted erscheint, ist analog TrainHasCallOn_Restricted und TrainHasCallOn_Restricted_Advanced gemeint.

TrainHasCallOn ermöglicht immer einen Anruf, wenn sich das Signal auf einem „Freileitungs“-Abschnitt befindet. Dies soll eine ordnungsgemäße Funktion für permissive Signale vom Typ USA ermöglichen.

Einige Signalsysteme verwenden diese Signale jedoch auf Abschnitten, auf denen kein Anruf zulässig ist. Für diesen Fall wurde die Funktion TrainHasCallOn_Restricted eingeführt.

Bei der Annäherung an eine Station verhalten sich beide Funktionen gleich, aber auf „freien Strecken“-Abschnitten lässt TrainHasCallOn_Restricted() niemals einen Anruf zu.

Also kurz und bündig:

• Einsatz bei der Anfahrt zu Bahnhöfen:

– TrainHasCallOn() und TrainHasCallOn_Restricted():

* Aktivität: Anruf nicht erlaubt

* Zeitplan: Aufruf in bestimmten Situationen erlaubt (mit $callon-, $stable- oder $attach-Befehlen)

• Verwendung auf „freier Leitung“:

– TrainHasCallOn():

* Aktivität oder Zeitplan: Ein Besuch ist immer erlaubt

– TrainsHasCallOn_Restricted():

* Aktivität oder Zeitplan: Ein Besuch ist niemals gestattet

Alle diese Funktionen können im Dispatcher-Fenster manuell auf „true“ gesetzt werden.

Diese Signale können mit dem MSTS RE festgelegt werden. In der .tdb-Datei wird nur eine Referenz auf den SignalType-Namen geschrieben, in der World-Datei wird nur eine Referenz auf den Signalkopf geschrieben. Da diese den MSTS-Standards entsprechen, besteht keine Notwendigkeit, Routendateien manuell zu bearbeiten.

11.15.5 Signalisierungsfunktion NEXT_NSIG_LR

Diese Funktion ähnelt NEXT_SIG_LR, außer dass sie den Zustand des n-ten Signals voraus zurückgibt.

Funktionsaufruf:

state = NEXT_NSIG_LR(MstsSignalFunction fn_type, int n).

Zurückgegebener Wert:

• Zustand des n-ten Signals voraus, außer,

– Wenn weniger als n Signale vor dem Zug vorhanden sind.

– wenn eines der Zwischensignale gefährdet ist.

In solchen Situationen gibt die Funktion SIGASP_STOP zurück.

Verwendung: Nehmen Sie zum Beispiel die unten gezeigte Signalfolge.

Der Abstand zwischen den Signalen B und C sowie zwischen C und D ist kürzer als der erforderliche Bremsweg. Wenn also D in Gefahr ist, müssen sowohl C als auch B gelb anzeigen; Ähnlich gilt: Wenn C in Gefahr ist, müssen sowohl B als auch A gelb sein.

Das Problem ist nun, welcher Aspekt bei A angezeigt werden soll: Wenn B gelb ist, liegt das daran, dass C rot ist, also muss A auch gelb sein, oder liegt es daran, dass C gelb ist, während D rot ist – in diesem Fall kann A Grün anzeigen. Man könnte natürlich bei C zwei unterschiedliche Zustände für Gelb verwenden, aber das wird schnell ziemlich kompliziert, und außerdem könnten einem bald die verfügbaren Aspekte ausgehen.

Mit der neuen Funktion wird es einfacher: Wenn B auf Gelb steht, kann A direkt den Zustand von C prüfen und so entscheiden, ob es auf Grün wechseln kann oder Gelb anzeigen muss.

Angenommen, der Status SIGASP_STOP wird für alle Signale rot, SIGASP_APPROACH_1 gelb und SIGASP_CLEAR_1 grün angezeigt. Der zugehörige Teil des Skripts könnte wie folgt aussehen:

if (next_sig_lr(SIGFN_NORMAL) == SIGASP_APPROACH_1)

{

if (next_nsig_lr(SIGFN_NORMAL, 2) == SIGASP_STOP)

{

state = SIGASP_APPROACH_1;

}

anders

{

state = SIGASP_CLEAR_1;

}

}

Die Funktion ist auch dann sehr nützlich, wenn ein Vorsignal den Zustand von mehr als einem Heimatsignal widerspiegeln soll, dist_multi_sig_mr jedoch nicht verwendet werden kann, da weiter entfernt kein Vorsignal vorhanden ist.

11.15.6 Signalisierungsfunktion HASHEAD

Diese Funktion kann für jeden optionalen SIGNAL_HEAD verwendet werden, der für die relevante Signalform in sigcfg.dat definiert ist, um zu überprüfen, ob dieser für dieses Signal ausgewählt wurde oder nicht.

Durch die Verwendung von „DECOR“-Dummy-Köpfen können diese Köpfe als zusätzliche Benutzereinstellungen verwendet werden und sind somit eine Art Erweiterung der vier verfügbaren SIGFEAT_USER-Flags.

Bitte beachten Sie, dass diese Funktion noch experimentell ist.

Funktionsaufruf:

state = HASHEAD( n );

wobei n die betreffende SignalSubObj-Nummer ist. Die Funktion gibt 1 zurück, wenn Head SignalSubObj gesetzt ist, andernfalls 0.

11.15.7 Signalisierungsflag OR_NOSPEEDREDUCTION

Anders als bei MSTS passieren KI-Züge standardmäßig Signale mit dem Aspekt RESTRICTED oder STOP_AND_PROCEED mit reduzierter Geschwindigkeit. Um auch einen MSTS-kompatiblen Betrieb zu gewährleisten und Signalsysteme zu berücksichtigen, bei denen beim Passieren solcher Signale keine Geschwindigkeitsreduzierung erforderlich ist, wurde das Flag OR_NOSPEEDREDUCTION eingeführt. Dies ist ein Beispiel für die Verwendung eines solchen Flags:

SignalAspekte ( 7

SignalAspect ( STOP „Rot“)

SignalAspect ( STOP_AND_PROCEED „LowYellowFlash“ SpeedMPH(25) Signalflags (OR_

˓→KEINE GESCHWINDIGKEITSREDUZIERUNG) )

SignalAspect ( EINSCHRÄNKUNG „LowYellow“ SpeedMPH(25) Signalflags (OR_

˓→KEINE GESCHWINDIGKEITSREDUZIERUNG) )

SignalAspect ( APPROACH_2 „TopYellowMidGreen“)

SignalAspect ( APPROACH_3 „TopYellow“)

SignalAspect ( CLEAR_1 „MidGreen“)

SignalAspect ( CLEAR_2 „TopGreen“)

)

Wenn dieses Flag gesetzt ist, wird beim Passieren des Signals keine Geschwindigkeitsreduzierung angewendet.

11.16 OR-spezifische Ergänzungen zu Aktivitätsdateien

Die unten beschriebenen Ergänzungen werden von MSTS ignoriert. Da Aktivitätsdateien im Stundenplanmodus nicht verwendet werden, stehen in diesem Modus keine der folgenden Funktionen zur Verfügung. Sie können diese Ergänzungen auf drei verschiedene Arten vornehmen, die in den folgenden Unterabsätzen beschrieben werden.

11.16.1 Manuelles Ändern der .act-Datei

Nehmen Sie diese Ergänzungen vor, indem Sie die .act-Datei mit einem Unicode-fähigen Editor ändern. Beachten Sie, dass diese Zusätze vom MSTS-Aktivitätseditor entfernt werden, wenn die .act-Aktivitätsdatei von der AE geöffnet und als .act-Datei gespeichert wird. Wenn die Aktivität jedoch in der AE geöffnet und in einem .apk-Aktivitätspaket gespeichert wird, werden die Ergänzungen stattdessen einbezogen.

11.16.2 Verwendung der TSRE5-Aktivitätsbearbeitungsfunktionen

Der TSRE5-Routeneditor umfasst Funktionen zur Aktivitätsbearbeitung. Zu diesen Funktionen gehört das Hinzufügen einiger OR-spezifischer Ergänzungen zu den Aktivitätsdateien, die in den folgenden Absätzen beschrieben werden. Wo dies nicht zutrifft, ist ein Hinweis vorhanden.

11.16.3 Generieren einer Erweiterungsaktivitätsdatei

Wenn der TSRE5-Editor nicht verwendet wird und das Problem vermieden werden soll, dass die OR-spezifischen Ergänzungen durch eine spätere Änderung der Aktivität mit dem MSTS-Aktivitätseditor verloren gehen, empfiehlt sich die Verwendung dieser dritten Möglichkeit: Es muss ein OpenRails-Unterordner vorhanden sein im Ordner ACTIVITIES der Route erstellt werden, und eine .act-Datei, die nur die verwendeten OR-spezifischen Erweiterungen enthält, kann mit einem Unicode-fähigen Editor erstellt und dann dort gespeichert werden. Ein Beispiel einer unveränderten .act-Datei und einer Erweiterungs-.act-Datei im OpenRails-Unterordner der Route ist in der Datei ORActivityExtensionFileSample.zip enthalten, die sich im Unterordner Documentation\SampleFiles\Manual des OpenRails-Ordners befindet. Wie man sieht, muss der Name einer solchen .act-Erweiterungsdatei mit dem Namen der Basis-.act-Datei identisch sein. Bei Ereignissen muss die erste Zeile in der Erweiterungsdatei im EventCategory-Block jedes geänderten Ereignisses die ID()-Zeile sein, um eine korrekte Kreuzkorrespondenz zwischen Ereignisdefinitionen in der Basisdatei und in der Erweiterungsdatei sicherzustellen. und die ID muss mit der in der Basis-.act-Datei vorhandenen übereinstimmen. Nur die hinzugefügten Zeilen innerhalb eines solchen EventCategory-Blocks dürfen in der Erweiterungsdatei .act vorhanden sein.

11.16.4 Meldungsfeld „Kein Halt durch Aktivität“.

MSTS-Aktivitäten können Anweisungen zum Anzeigen eines Meldungsfelds enthalten, wenn der Spielerzug einen bestimmten Ort in der Aktivität oder zu einem bestimmten Zeitpunkt erreicht. Normalerweise wird die Simulation angehalten, wenn das Meldungsfeld angezeigt wird, bis der Spieler das Feld manuell schließt. Dieses Verhalten kann geändert werden, wenn die Zeile:

ORTSContinue ( nn )

Wobei nn = Anzahl der Sekunden, in denen das Feld angezeigt wird, wird der Ereignisdeklaration (EventTypeLocation oder EventTypeTime) in der .act-Datei hinzugefügt.

Zum Beispiel:

EventCategoryLocation (

EventTypeLocation ( )

ID ( 1 )

Activation_Level ( 1 )

Outcomes (

DisplayMessage ( "Test nopause." )

)

Name ( Location1 )

Location ( -146 14082 -1016.56 762.16 10 )

TriggerOnStop ( 0 )

ORTSContinue ( 10 )

)

Jetzt wird die Aktivität weiter ausgeführt, während das Nachrichtenfenster angezeigt wird. Wenn der Spieler nichts unternimmt, verschwindet das Fenster automatisch nach nn Sekunden. Der Spieler kann das Fenster manuell schließen oder die Aktivität anhalten, indem er auf die entsprechende Schaltfläche im Fenster klickt. Beachten Sie, dass diese Änderung nicht für das beendende Ereignis der Aktivität funktioniert.

11.16.5 AI Train Horn Blow

Mithilfe von Wartepunkten können KI-Züge angewiesen werden, an bestimmten Orten zu hupen.

Liegt der Wartezeitwert zwischen 60011 (1 Sekunde Hupenschlag) und 60020 (10 Sekunden Hupenschlag), wird ein einzelner Hupenschlag erzeugt.

Wenn der Wartezeitwert 60021 beträgt, wird eine Hupenfolge mit dem Muster Langton – Langton – Kurzton – Langton generiert (nordamerikanisches Hupenmuster an Bahnübergängen).

An diesen Wartepunkten hält der KI-Zug nicht an, sondern fährt mit seiner regulären Geschwindigkeit weiter.

Wenn für die Führungslokomotive des KI-Zugs der Parameter DoesHornTriggerBell in der .eng-Datei auf 1 gesetzt ist, wird die Glocke nach dem Ende des Hupenschlags weitere 30 Sekunden lang abgespielt.

Um diese Funktion zu implementieren, ist es nicht notwendig, wie in den ersten drei Absätzen dieses Kapitels beschrieben vorzugehen. Es reicht aus, die Wartepunkte entweder mit MSTS AE oder über TrackViewer in die Pfade einzufügen.

11.16.6 KI-Hupenschlag an Bahnübergängen



Open Rails kann auch angewiesen werden, KI-Züge an Bahnübergängen automatisch hupen zu lassen. Diese Funktion wird über spezielle Eigenschaften im Tr_Activity_File-Block aktiviert:

Diese Zeilen müssen nach der Zeile NextActivityObjectUID (32768) platziert werden, andernfalls kann die Aktivitätsdatei im MSTS-Aktivitätseditor nicht mehr geladen werden.

In der Trasse können auch einfache Straßenkreuzungen vorhanden sein, die nicht als Bahnübergänge definiert sind. Der KI-Zug wird an diesen Kreuzungen nicht hupen. Durch die Untersuchung der Strecke mit TrackViewer können die tatsächlichen Bahnübergänge identifiziert werden. Wenn ein Hupenschlag auch für eine einfache Straßenüberquerung gewünscht wird, muss die oben beschriebene Funktion AI Train Horn Blow verwendet werden.

Wenn für die Führungslokomotive des KI-Zugs der Parameter DoesHornTriggerBell in der .eng-Datei auf 1 gesetzt ist, wird die Glocke nach dem Ende des Hupenschlags weitere 30 Sekunden lang abgespielt.

11.16.7 Standortereignis, ausgelöst durch KI-Zug

Unter MSTS dürfen Standortereignisse nur dann ausgelöst werden, wenn der Spielerzug sie erreicht. OR bietet auch Standortereignisse, die durch KI-Züge ausgelöst werden. In diesem Fall muss eine Zeile wie die folgende innerhalb des EventCategoryLocation-Blocks hinzugefügt werden:

ORTSTriggeringTrain („TestEventAI“ 43230)

Dabei ist „TestEventAI“ der Dienstname des KI-Zugs und 43230 die Startzeit (in Sekunden) des KI-Zugs. Der zweite Parameter kann weggelassen werden, falls in der obigen Zeile nur ein KI-Zug mit dem Dienstnamen vorhanden ist.

Diese Funktion in Verbindung mit der KI-ZugWaiting Point-Änderung durch Ereignis ermöglicht die Synchronisierung zwischen KI-Zügen oder auch zwischen einem KI-Zug und dem Spielerzug.

Diese Funktion wird noch nicht von TSRE5 verwaltet.

11.16.8 Ortsereignis- und Zeitereignis-Sounddatei

Eine Aktivitätsdatei kann so geändert werden, dass eine Sounddatei abgespielt wird, wenn der Zug einen in einem EventTypeLocation-Ereignis in der .act-Datei angegebenen Standort erreicht oder wenn ein bestimmtes in einem EventType-Time-Ereignis angegebenes Zeitintervall seit dem Start verstrichen ist der Aktivität. Fügen Sie im Outcomes()-Unterblock des Ereignisses den folgenden Unterblock hinzu:

ORTSActivitySound (

ORTSActSoundFile (Dateiname SoundType)

ORTSSoundLocation ( TileX TileZ X Y Z )

)

zum EventCategoryLocation- oder EventCategoryTime-Ereignis, wobei:

• Dateiname = Name (in Anführungszeichen) einer .wav-Datei, die sich im SOUND-Ordner der Route befindet. (Wenn sich die WAV-Datei an einer anderen Stelle auf dem Computer befindet, muss die Zeichenfolge auch den Pfad vom SOUND-Ordner zum Speicherort des Sounds enthalten.)

• Soundtype = eine der Saiten:

– Überall – Der Ton wird in allen Ansichten mit der gleichen Lautstärke ohne Fading-Effekte abgespielt

– Kabine – Ton wird nur in der Kabine abgespielt

– Pass – Ton wird nur in der aktiven Beifahreransicht abgespielt

– Boden – Der Ton wird extern von einer festen Position abgespielt, die die Lokomotive erreicht hat, wenn das Ereignis ausgelöst wird. Der Ton ist auch in Innenansichten zu hören

abgeschwächt und wird abgeschwächt, wenn man sich von der Position entfernt.

– Standort – Der Ton wird extern von einer festen Position abgespielt, die im Parameter ORTSSound-Location definiert ist.

Hinweis: Der Parameter ORTSSoundLocation wird nur benötigt, wenn Soundtype „Location“ ist.

Zum Beispiel:

EventCategoryLocation (

EventTypeLocation ( )

ID ( 7 )

Activation_Level ( 1 )

Outcomes (

DisplayMessage ( "Won't be shown because ORTSContinue = 0")

ORTSActivitySound (

ORTSActSoundFile ( "milanogrecopirelli.wav" "Ground" )

)

)

Name ( Location6 )

Location ( -146 14082 -1016.56 762.16 10 )

TriggerOnStop ( 0 )

ORTSContinue ( 0 )

)

Das Einschließen der ORTSContinue-Zeile (oben erläutert) verhindert das normale Anhalten der Aufgabe durch das Ereignis. Auch wenn in der Zeile wie im obigen Beispiel der Wert 0 eingefügt wird, wird die Anzeige der Ereignismeldung komplett unterdrückt. Es ist nur eine Sounddatei pro Veranstaltung erlaubt.

Diese Funktion wird von TSRE5 in diesem Format noch nicht verwaltet.

11.16.9 Wetteränderungsaufgabenereignis

Eine Aktivität kann so geändert werden, dass sich das Wetter ändert, wenn die Aufgabe in ORTS ausgeführt wird. Der MSTS-Betrieb wird von diesen WeatherChange-Ereignissen nicht beeinträchtigt. Der folgende Block kann innerhalb des Outcomes()-Blocks eines Ereignisblocks (entweder ein Orts- oder ein Zeitereignis) der .act-Datei hinzugefügt werden:

ORTSWeatherChange (

ORTSOvercast (

final_overcastFactor(float)

overcast_transitionTime(int)

)

ORTSFog ( final_fogDistance(float) fog_transitionTime(int) )

ORTSPrecipitationIntensity (

final_precipitationIntensity(float)

niederschlagIntensity_transitionTime(int)

)

ORTSPrecipitationLiquidity (

final_precipitationLiquidity(float)

niederschlagLiquidity_transitionTime(int)

)

)

Das Wetter ändert sich während der Aktivität entsprechend. Die Bereiche der Faktoren sind wie folgt:

• final_overcastFactor: Wert von 0 bis 1.

• final_fogDistance: Wert von 10 (Meter) bis 100000.

• final_precipitationIntensity: Wert von 0 bis 0,020 (begrenzt auf 0,010, wenn eine 16-Bit-Grafikkarte verwendet wird).

• final_precipitationLiquidity: Wert von 0 bis 1.

Der Wettertyp ändert sich entsprechend den folgenden Regeln:

• Wenn die Niederschlagsintensität auf 0 fällt, wird der Wettertyp auf „Klar“ gesetzt.

• Wenn die Niederschlagsintensität über 0 steigt, wird der Wettertyp entsprechend final_precipitationLiquidity ausgewählt.

• Wenn die Niederschlagsflüssigkeit über 0,3 liegt, wird der Wettertyp auf Regen eingestellt.

• Wenn die Niederschlagsflüssigkeit kleiner oder gleich 0,3 ist, wird der Wettertyp auf Schnee eingestellt.

Der Parameter ORTSPrecipitationLiquidity ermöglicht einen sanften Übergang von Regen (ORTSPrecipitationLiquidity = 1) zu Schnee (ORTSPrecipitationLiquidity = 0) und umgekehrt.

Die xx_transitionTime wird in Sekunden ausgedrückt und gibt die Zeit an, die benötigt wird, um vom anfänglichen Wettermerkmalswert (overcastFactor, fogDistance usw.) bis zum endgültigen Wettermerkmalswert zu gelangen. Wenn xx_transitionTime auf 0 gesetzt ist, nimmt die Wetterfunktion sofort den endgültigen Wert an. Dies ist nützlich, um Aktivitäten mit Wetterfunktionen in Zwischenzuständen zu starten.

Das Ereignis kann auch eine ORTSContinue ( 0 )-Zeile enthalten, sodass keine Meldungen angezeigt werden und die Aktivitätsausführung nicht angehalten wird.

Manuelle wetterbezogene Befehle unterbrechen den durch die oben genannten Ereignisse ausgelösten Wetterwechsel.

Jeder Ereignisblock in der Aktivitätsdatei darf nur einen WeatherChange-Block enthalten, und jeder Weather-Change-Block darf eine bis alle der oben angegebenen Zeilen enthalten.

Ereignisblöcke, einschließlich WeatherChange-Blöcken, können teilweise verschachtelt sein (die Ausführung eines Blocks kann in dem Moment, in dem ein neuer WeatherChange-Block ausgelöst wird, noch aktiv sein). Die Durchführung der verschiedenen Wetterparameteränderungen bleibt unabhängig. Wenn in beiden Ereignissen ein Wetterparameter vorhanden ist, wird die Ausführung der vom ersten Block befohlenen Parameteränderung gestoppt und die vom zweiten Block befohlene gestartet.

Hinweis: Durch Bearbeiten der .act-Datei mit dem MSTS-Aktivitätseditor nach der Einbindung von WeatherChange-Ereignissen werden diese entfernt, daher sollten sie separat gesichert werden. Wenn Sie eine .act-Datei, die WeatherChange-Ereignisse enthält, mit dem MSTS-Aktivitätseditor öffnen und sie verpacken, ohne sie zu bearbeiten, wird eine .apk-Datei generiert, die die WeatherChange-Ereignisse enthält.

Diese Funktion wird von TSRE5 in diesem Format nicht verwaltet.

11.16.10 KI-Zug-Wartepunktänderung durch Ereignis

Zweck der Funktion

Es ist ein Ereignisergebnis verfügbar, das die Ablaufzeit des Wartepunkts ändert, wenn das Ereignis erreicht wird (z. B. wenn der Spielerzug es erreicht, im Falle eines Standortereignisses).

Dadurch werden Probleme mit der KI-Zugsynchronisierung gelöst. Wenn z.B. Soll ein KI-Zug Waggons an den Spielerzug an- oder abkuppeln, muss sichergestellt werden, dass die beiden Züge zur richtigen Zeit am richtigen Ort sind. Wenn dies jedoch nach einer längeren Fahrt des Spielerzuges geschieht, kann es zu Verzögerungen kommen, sodass es schwierig ist, zu garantieren, dass das Rendezvous korrekt erfolgt. In diesem Fall kann auf der KI-Zugstrecke ein längerer Wartepunkt eingerichtet werden. Der KI-Zug wartet dort auf den Spielerzug. Am Synchronisierungsort (normalerweise einige Zeit vor dem Punkt, an dem die

Spielerzug muss vom KI-Zug berührt werden) wird ein Ortsereignis positioniert, das den aktualisierten Wartepunktwert für den KI-Zug angibt (normalerweise ein kurzer Wartepunkt). Wenn der Spielerzug ein solches Ortsereignis erreicht, wird der KI-Zugwartepunkt aktualisiert und dieser Zug wird neu gestartet, nachdem der aktualisierte Wartepunkt abgelaufen ist, und er wird an den Spielerzug gekoppelt.

Die Funktion kann auch für andere Funktionen genutzt werden, etwa um einen KI-Zug mit dem Zug des Spielers als Helfer zu koppeln, oder um eine Personenzugverbindung in einem Bahnhof zu gewährleisten, oder um einen KI-Zug mit einem anderen KI-Zug zu koppeln (je nach Ereignis). kann auch durch einen KI-Zug ausgelöst werden, siehe Standortereignis, ausgelöst durch KI-Zug.

Syntax der Funktion

Um diese Funktion nutzen zu können, wird empfohlen, eine Erweiterungsaktivitätsdatei zu erstellen.

Hier ist ein Beispiel für eine Erweiterungsaktivitätsdatei, die diese Funktion verwendet:

SIMISA@@@@@@@@@@JINX0a0t______

Tr_Activity (

Tr_Activity_File (

Events (

EventCategoryLocation (

ID ( 1 )

ORTSContinue ( 3 )

Outcomes (

ORTSRestartWaitingTrain (

ORTSWaitingTrainToRestart ( "TesteventWP_ai_

˓→longerpath" 23240 )

ORTSDelayToRestart ( 60 )

ORTSMatchingWPDelay ( 31500 )

)

)

)

)

)

)

Beschreibung der Parameter:

1) ORTSWaitingTrainToRestart hat als ersten Parameter den Dienstnamen des KI-Zugs, dessen Wartepunkt geändert werden muss, und als zweiten (optionalen) Parameter die Startzeit des KI-Zugs.

2) ORTSDelayToRestart ist die neue Verzögerung für den Wartepunkt. Sie wird in Sekunden ausgedrückt.

3) ORTSMatchingWPDelay gibt den ursprünglichen Wert des KI-Zugwartepunkts an; Dadurch wird sichergestellt, dass der richtige Wartepunkt geändert wird.

Die obige Datei ist auch als Datei TesteventWP_longerpath_extension.zip verfügbar, die sich im Unterordner Documentation\SampleFiles\Manual im OpenRails-Ordner befindet. Eine Beispielaktivität, die eine solche Datei verwendet, ist als Datei testeventwp_longerpath.zip im selben Unterordner verfügbar. Es handelt sich um eine APK-Datei.

Die Aktivität nutzt die MSTS-Legacy-Route USA1 und Legacy-Triebzüge.

Der Spielerzug verlässt den Tunnel und hält am Bahnhof Baltimore. Kurz zuvor trifft es auf das Ortsereignis, das den KI-Zug WP setzt. Später wird ein KI-Zug in den Bahnhof einfahren und anhalten. Dieser Zug erreicht unmittelbar nach Beendigung der Passagierentladung einen absoluten WP. Da der Spielerzug zuvor angekommen ist, wird dieser absolute WP auf Null gesetzt und der KI-Zug wird ohne weitere Wartezeit neu gestartet.

Wenn stattdessen der Spielerzug angehalten wird, bevor er in den Bahnhof einfährt, und dort bleibt, bis der KI-Zug in den Bahnhof eingefahren ist und die Passagiere ausgeladen hat, bleibt der KI-Zug weiter dort, bis der Spielerzug neu startet, das Ortsereignis erreicht und die geänderte WP-Zeit abgelaufen ist Abgelaufen.

Diese Funktion wird noch nicht von TSRE5 verwaltet.

11.16.11 Alte Formate

Die folgenden alternativen Formate werden von OR für Event-Sounddateien und Wetteränderungen akzeptiert. Diese Formate werden für neue Aktivitäten nicht empfohlen.

Ereignis-Sounddateien: Die Sounddatei kann durch eine einzelne Zeile definiert werden:

ORTSActSoundFile (Dateiname SoundType)

direkt in den EventCategoryLocation()- oder EventCategoryTime()-Block eingefügt werden, anstatt in den Outcomes()-Unterblock eingefügt zu werden. In diesem alternativen Format wird der Location SoundType nicht unterstützt.

TSRE5 verwaltet dieses Format.

Wetteränderungsereignisse: Der ORTSWeatherChange()-Block kann direkt in den EventCategoryLocation()- oder EventCategoryTime()-Block eingefügt werden, anstatt in den Outcomes()-Unterblock eingefügt zu werden.

TSRE5 verwaltet dieses Format.