Beiträge von Schuster

Hallo,

wenn der TAB-Trigger nichts bewirkt, dann kommt die TAB-Nachricht nicht über das Gleis am Signal an.
Lege den TAB-Trigger mal dichter vor das Signal. Ggf. an die Stelle, wo Du aus der Lok heraus TAB gedrückt hast.

Gruß Schuster

Hallo,

das kombinierte Zs1 + Ra12 für den Anbau an ein Hauptsignal hat ja nur einen Link 0, der vor dem Hauptsignallink 0 zu liegen kommt. Deshalb gibt es gar kein Buchstabenfeld. Bei mir funktioniert das auch tadellos.
Anbausignale kann man nicht so einfach mit zusätzlichen Links ausstatten. Vor allem Signale mit nur einem Link 0, die an Haupt- oder Vorsignalen angebaut werden wird es der Skript dann nicht verstehen...

Wenn man im Buchstabenfeld eine 0 eingeben kann, dann gibt es auch einen Link 1+.

Gruß Schuster

Hallo Amisia,

das ist bereits umgesetzt und möglich. Siehe in der Anleitung unter Punkt 3.3.6.5. "Vorsignal-Dummy als Überleiter von Signalnachrichten".

Gruß Schuster

Hallo,

ohne dass ich das explizit getestet habe, würde ich sagen, dass das SBK Signal dann aber Halt signalisiert, da der Blockabschnitt belegt ist.

Die Fahrtstellung als SBK Signal bedeutet ja nur, dass es Fahrt signalisiert, obwohl kein Zug in Annäherung ist. Wenn der Zug ein SBK Signal in Fahrtrichtung passiert, schaltet das SBK Signal ja auch auf Halt, solange sein Blockabschnitt belegt ist. Wenn der Zug nun aus der Gegenrichtung den Blockabschnitt belegt, so muss das SBK Signal auch auf Halt schalten. Wenn nicht, dann habe ich etwas falsch gemacht.

Gruß Schuster

Hallo,

ich habe mir die Sache mit dem Zs6 in Verbindung mit einem Hauptsignal nochmals angeschaut und die Lösung war gar nicht so weit entfernt.

Somit wird an einem Hauptsignal nun der bereits vorhandene untere Kasten eingeblendet und als Zs6 genutzt, wenn das Zs3 für Geschwindigkeiten verwendet wird.
Allerdings ist das an einem Mehrabschnittsignal nicht so, da hier dar untere Kasten ausschließlich als Zs3v fungiert.

Wer das mal testen will. Das Modul aus dem Anhang in folgendes Verzeichnis entpacken: Assets\Schuster\SignalTeam-KS\RailNetwork\Signals\German KS\Module

Gruß Schuster

Hallo,

da Hauptsignale kein Zs3v kennen, habe ich hier die Möglichkeit geschaffen, den sowieso vorhanden Zusatzanzeiger für Richtungsanzeigen zu nutzen.
Diese Funktion kam nachträglich und soll zusätzlichen Aufwand für ein Zs2 vermeiden. Ein Zs6 ist dort nicht möglich. Ich werde das zukünftig vermerken und in einer Tabelle zusammenstellen.

Gruß Schuster

Zitat von Cotten Eye Joe

es geht allein um die beschriebene Möglichkeit durch Eingabe von "]" im ID-Feld ein Zs2 unterhalb des Signalschirms zu erhalten.

Der vorhandene Anzeiger unterhalb eines Signals ist ein Zs3v und kein Zs2 und das steht unter Punkt 3.1.
Unter Punkt 3.1.3.3. steht auch, dass das Sonderzeichen "]" ein Zs3v Licht einblendet.
Wenn man ein Zs2 unterhalb des Signalschirmes haben will, muss man ein separates Zs2 anbauen.

Gruß Schuster

Hallo,

mal zur näheren Erläuterung:

- Punkt 3.1.
-Hauptsignale mit Zs3 Licht und festes Zs3
- Mehrabschnittsignale mit Zs3 und Zs3v Licht und festes Zs3 und Zs3v
- Punkt 3.8.1. behandelt separate (!) Richtungsanzeiger

In diesem Zusammenhang wird dort erwähnt, dass ein Zs6 auch auf einem Zs3 angezeigt wird, soweit keine Geschwindigkeitsbeschränkung für den entsprechenden Link eingetragen wurde. Dies funktioniert auch mit "6" , "l" und "r" wie auf dem Bild zu sehen ist.

Gruß Schuster

Hallo,

wie bei den KS-Signalen gewünscht, habe ich auch gleich noch für die HV-Signale das Q als Groß- und Kleinbuchstabe für die Mastbezeichnung hier als Zusatzpaket.

Ab dem nächsten Update ist der Buchstabe dann regulär mit im Paket.

Gruß Schuster

@HappyNiki,

es ist kein großer Aufwand.
Wir sind damals davon ausgegangen, dass es keine Signalbezeichnungen mit dem Buchstaben Q gibt. Aber es ist wie, immer....

Somit habe ich das Q als Groß- und Kleinbuchstabe mal hier als Zusatz zum Installieren.
Ab dem nächsten Update ist es dann regulär mit im Paket.

Gruß Schuster

Hallo,

hab mich falsch ausgedrückt und habe mir das nochmals angeschaut.

Es geht natürlich um die Animations-ID. Diese sollten in allen drei Signal-BINs gleich sein.
Die Gleissperre an sich wird dann mit "Stopping = eTrue" und 2 Track-Links gebaut.
Die Laterne und der Hebel dann mit "Stopping = eFalse" und nur einem Track-Link gebaut.
Dadurch erkennt der Skript, dass er sich anders verhalten soll.
Das Symbol für die 2DMap wird mit einem Befehl ("Call("Set2DMapSignalState", gSignalState)") erzeugt, der bei den Objekten mit nur einem Track-Link nicht ausgeführt wird. Somit wird dort das Symbol nicht angezeigt. Außerdem werden sowieso nur Symbole von Signalen mit "Stopping = eTrue" angezeigt.

Die Link 0 der Laterne und Hebel sitzen dann hinter dem Link 0 der Gleissperre und bekommen von der Gleissperre eine Nachricht zugesendet. Damit ist der Kontakt hergestellt.
Und die zweite Gleissperre, die synchron öffnen muss, wird dann auch nur mit einem einzigen Track-Link gebaut und bewegt sich ebenso mit, ohne ein Eigenleben zu entwickeln.

Für mich stellt sich nur noch die Frage wie die Gleissperre bestenfalls geöffnet und geschlossen werden soll?
1. Öffnung mit TAB ?
2. Öffnung bei Annäherung davor oder dahinter ?
3. Öffnung immer bei richtig gestellter Weiche ?
4. Schließung nach Passieren des Link 0 ?
5. Schließung bei Entfernung in Metern ?

Gruß Schuster

Zitat von StS

Die Idee ist Hebel, Laterne und Gleissperre in eigene Objekte zu trennen, damit die Kombinationsvielfalt reduziert wird.

Die Idee ist gut. Wenn man beim Erstellen der Objekte für Gleissperre, Laterne und Hebel immer die gleichen Node-Namen verwendet, könnte man sogar alles mit dem gleichen Skript abwickeln und die Links jeweils "übereinander" legen.
Anhand des Child-Namens müsste man das 2DMap-Symbol nur für die Gleissperre aktivieren. So mal nur ins auf die Schnelle gedacht.

Gruß Schuster

Hallo,

also TS für LUA-Meldungen starten:

[Pfad zu Railworks]\RailWorks.exe -LogMate -SetLogFilters="Script Manager" -lua-debug-messages

Die Optionsdatei muss zum Signalsystem passen:

Schuster\SignalTeam-KS\RailNetwork\Signals\German KS\DEs KS Option.lua

Die Debugmeldungen sollten schon angezeigt werden, wenn im ID-Feld des Zs2 6T "ZS12" und in der Optionsdatei bei gDebug = "ZS12" steht.

Ist das vorhandene Modul:

Schuster\SignalTeam-KS\RailNetwork\Signals\German KS\Module\DEs KS Modul HS.out

vom 11.03.2019 15:07 ?

Irgendetwas stimmt hier doch nicht.

Gruß Schuster

Hallo,

die Ursachen können eigentlich nur folgende sein:

a) Die Weichenumschaltung wird vom KS-Signal nicht an den davor liegenden Link0 vom Zs2 6T weiter geleitet-> Lösung: Cross_Patch
b) Es gibt keinen verbundenen Link am Zs2 6T -> Gleis prüfen?

Aus meiner Sicht kommt aber die Weichenumschaltung nicht an, da die Änderung der Fahrstraße das "T" nicht erlöschen lässt. Somit bemerkt das Zs2 6T diese Umschaltung nicht. Vor dem Cross_Patch wurde die Nachricht von der Weiche am Hauptsignallink blockiert. Ist das Mehrabschnittsignal wirklich von Schuster/SignalTeam-KS?

Was passiert, wenn Du den Link0 vom Zs2 6T hinter den Link0 vom Mehrabschnittsignal legst?

Hilfreich wäre für mich noch ein Log vom Zs2 6T. Also einfach mal in das ID-Feld eine Bezeichnung eintragen und diese dann auch in die Optionsdatei eintragen. Dann die Weichen durchschalten. Die Log-Einträge verraten (mir) dann die Ursache.

Gruß Schuster

Hallo,

ich denke, Dir fehlt dieser Patch.

Er gilt für folgende Signalsysteme:

• Kuju/KS-Signale
• Kuju/Formsignale
• RLB/Freeware-Formsignale
• Schuster/Freeware (HL, HL, KS, OEBB)
• Schuster/HV-Signale
• Schuster/KS-Signale

Gruß Schuster

Hallo,

das Zs2 T funktioniert ganz normal. Mit den Updates seit Version 8 sind auch keine Neuerungen einbaut worden. Lediglich die LZB-Funktionalität wurde auf LZB-V2 erweitert. Betrifft aber nu die aktive LZB-Schaltung.
Bei mir läuft das Zs2 T auch ohne Probleme.

Gruß Schuster

@DarkFictionWorld,

in der Textdatei stehen keine LOG-Zeilen des Signals drin.
Somit kann ich da nichts auswerten. Hast Du wie weiter oben beschrieben die Angaben in die Optionsdatei eingetragen?
Und Du musst den TS folgendermaßen starten:

[Pfad zu Railworks]\RailWorks.exe -LogMate -SetLogFilters="Script Manager" -lua-debug-messages

Gruß Schuster

Hallo,

ich habe mir das Zs7 von Schienenbus mal "unter der Haube" angeschaut.
Es funktioniert skriptmäßig als Zs1. Somit stellt es kein Problem dar und sollte auch mit den RLB-Formsignalen richtig funktionieren, wenn dort das Zs1 aktiviert wird.

Gruß Schuster

Hallo,

bei dem Signal handelt es sich nicht um die neuen KS-Signale sondern um die überarbeiteten KS-Signale von Kuju.
Das besagte Signal ist ein KS Hauptsignal als Blocksigna. Ich habe es getestet und das LOG geprüft. Einen Fehler konnte ich nicht entdecken.
Wenn Du das testet, wäre es gut mal ein LOG zu bekommen. Also in die Options-Datei unter:

Assets\TrainTeamBerlin\AS_Common\RailNetwork\Signals\German KS\DEs KS Option.lua

in der Variable gDebug die Signal-ID eintragen ( gDebug = "4868" ) die Stelle abfahren und mir dann das Log mal zur Verfügung stellen.
Ich kann dann schauen, ob sich das Signal abartig verhält. Die Skripte sind zwar von 2016 aber gerade an der Funktionalität vom Hp0-Trigger hat sich in diesem Bereich nichts geändert.

Gruß Schuster

Hallo,

es gibt kein Zs7-Objekt bei den RLB-Formsignalen und auch im Skript der Formhauptsignale ist keine Zs7 Funktionalität hinterlegt.
Somit würde kein separates Zs7 angedockt werden können.

Das mit dem Skript könnte ich ja selbst regeln.

Gruß Schuster