Gleissperrsignale für Interlocking Towers

Ich bin gerade dabei die Stadtanlage mit den neuenFahrstraßen der Interlocking Towers zu versehen und eines der Probleme, welchesich zurzeit habe, ist, dass es keine Gleissperrsignale gibt, die bei Verwendungder Fahrstraßen keine Fehlermeldungen produzieren. Die Skripte sowohl der Formsignaleals auch der Lichtsignale versuchen auf den trainzinternen Signalstatuszuzugreifen und das Signal zu stellen. Dies ist bei Verwendung den Fahrstraßenaber nicht mehr erlaubt. (Es handelt sich dabei um eine der größten Schwächender neuen Interlocking Towers, aber es sieht nicht so aus, als ob das nicht geändertwird und so wird man damit leben müssen).

Für Hauptsignale gehe ich dem Problem mit einem Trick ausdem Weg: Ich stelle in sehr kurzem Abstand nach dem sichtbaren Hauptsignal(welches unter den Fahrstraßen denselben Skriptfehler erzeugen würde) einunsichtbares Signal (mit einfacher Rot/Grün-Logik ohne Skript) auf und lassedie Fahrstraße dort beginnen. Die Fahrstraße endet bei der letzten Weiche inder Fahrstraße (also nicht beim nächsten Hauptsignal).

Mein Problem ist, dass ich gerne realitätsgetreu Gleissperrsignalein den Weichenbereich setzen würde, überden die Fahrstraßen laufen. Die Gleissperrsignale sollen funktionierendeSignale sein, allerdings mit einer einfachen Rot/Grün-Logik ohne ein Skript, dasversucht, die Signale zu stellen.

Gibt es jemanden, der die Lichtsperrsignale von Ehauschi oderdie Formsignale und FCCA entsprechend umbauen könnte und auch die Berechtigunghat, diese auf die DLS zu laden? Es müssen natürlich nicht die beiden vorgenannten Signale sein, jedes andereordentlich aussehende Signal wäre ebenfalls toll. Ich würde mich sehr freuen,wenn sich jemand des Themas annehmen könnte.

Viele Grüße
wallner

wenn man mir ganz genau mitteilt, wie das eingerichtet werden muss, dann bin ich bereit, meine Lichtsperr-Signal-Repaints einmal komplett ohne Konfigurationsmenü und Skript bereit zu stellen.
Die hätten demnach eine einfache Rot/Grün stellung als Hp0 und Sh1/Ra12.

Hallo cj187,

ich habe dir eine Nachricht geschickt. Ja, es müsste eine einfache Rot/Grün-Stellung als Hp0 und Sh1/Ra12 sein, aber ohne Signalstellbefehle wie SetSignalState zu benutzen. Meine Kenntnisse zu Trainz-Signal-Skripten sind nur sehr rudimentär, aber wen ich es richtig verstanden habe, dann gibt man einfach an, welche Trainz-internen Signalstellungen ("SignalState") das Signal haben kann, trägt die Lichtzeichenstellung für den jeweiligen SignalState ein und belässt das Signal sonst auf Automatik.

Ich weiß nicht, ob man in Signalen einen Geschwindigkeitstrigger integrieren kann oder ob dies auch eine Fehlermeldung in den Fahrstraßen produziert. Wenn es geht, könnte man noch eine Option für 25km/h einbauen, ansonsten weglassen. Müsste man ausprobieren, ob das geht. Ich helfe dir gerne beim Testen.

Gruß

wallner

Nachdem ich die DKW-Weichen-Skripte angepasst hatte, habe ich gestern auch kurz einen Blick in das Skript der Gleissperrsignale geworfen. Das sieht auf den ersten Blick wie eine Kopie des Skripts für die DR HL-Signale aus. Das Skript hat nur einen einzigen Stellbefehl "SetSignalState",welcher erreicht, dass das Signal auf Automatikmodus geschaltet wird. Dieser Befehl ist bei Einbezug des Signals in eine Fahrstraße überflüssig und man sollte den Befehl daher gefahrlos bei Einbezug des Signals in eine Fahrstraße abschalten können. Liegt keine Fahrstraße an, würde das Skript genauso funktionieren wie bisher. Ich werde das heute Abend mal ausprobieren.

Falls die Skripte in den DR HL-Signalen gleich sind, zu denen in den Gleissperrsignalen, könnten man das auch bei den HL-Signalen machen und damit diese ebenfalls fit für Interlocking Towers machen.

CJ187, falls das klappt mit der Skript-Anpassung, könnte man Updates der Gleissperrsignale herausbringen, man bräuchte keine neuen seperaten Objekte. Würdest du die Updates auf die DLS hochladen?

Gruß
wallner

Das würde ich machen

Hallo cj187,

die Skripte habe ich angepasst. Da muss man nur an einer Stelle den SetSignalState-Befehl abfangen, also skriptmäßig ist das Update sehr einfach. Danach habe ich die Versionsnummer auf 4.3 hochgesetzt. TANE meckert bei ein paar Config.txt-Einträgen welche es nicht mehr gibt, die kann man einfach löschen. Eine neue Fehlermeldung kriege ich aber nicht weg. Bis jetzt ist nur ein Mesh mit über 900 Polys verbaut. TANE will aber LOD-Meshes mit dem einfachsten unter 500 Polys. Da ich die Original-Meshes nicht habe, kann ich auch kein neues Low-Poly-Mesh basteln. Meine Mesh-Erstellungskünste sind auch sonst eher bescheiden.

Ich habe schon mal in die Config das LOD-Mesh-Prinzip eingebaut, aber als Low-Poly-Mesh einfach das bestehende kopiert. Die Fehlermeldung in TANE bleibt dadurch natürlich bestehen. Aus meiner Sicht gibt es zwei Möglichkeiten:

• Man erstellt ein neues Low-Poly-Mesh, z.B. einen einfachen viereckigen Kasten, haut die vorhandenen Texturen drauf und fertig.
• Man lädt das bestehende (also ohne Low-Poly-Mesh) unter Versionsnummer 3.8 (Trainz Simulator 2 (Mac)) zur DLS. Das ist höher als TS12, so dass man mit TS12 nicht in Konflikt kommt. Gleichzeitig ist das die letzte Trainz-Build-Version, welche noch keine Fehlermeldung, sondern nur eine Warnung ausgibt. Ich habe probehalber ein Signal zur DLS geladen und es ist gebilligt worden.

Hier ist ein Link zu einem Signal, welches ich als Muster upgedated habe und auf Version 3.8 gesetzt habe.
http://www.mediafire.com/file/…_DB_Licht-Sperrsignal.zip

Welche Option würdest du bevorzugen?

Danke und Gruß
wallner

Macht nicht den Fehler, anzunehmen, das Problem wäre bei Signalen genauso einfach zu lösen wie bei den DKW-Laternen (diese Lösung gefällt mir auch nicht).

Die Signale sollen ja eigentlich ihre eigene Funktion beibehalten, die sie vom Scripter bekommen haben. Wenn man jetzt ein Update des Signals abschaltet (also SetSignalStateEx/SetSignalState, abfängt),
so kann u.U. ein Signalupdate nicht gegeben werden.

Da kommen zwei wichtige Methoden der Klasse "Signal" ins Spiel:

// Wird aufgerufen, wenn Trainz den Status des Signals einlesen möchte
// Gibt eine Soup mit den Werten "state" (ein Signalstatus-Makro, siehe Klasse "Signal") 
// und "reason" (Eine Zeichenkette mit dem Tooltip der beim Mouse-Over am Signal erscheint)
// zurück
public Soup DetermineUpdatedState(void);




// Wird aufgerufen, wenn duruch oben stehende Methode ein Status eingelesen wurde,
// um den neu eingelesenen Status anzuwenden.
// Bekommt als Paramter die Soup aus DetermineUpdatedState
public void ApplyUpdatedState(Soup StateSoup);

Wenn man eine eigene Logik implementieren möchte, wie das eben bei solchen Signalen der Fall ist,
so kann man sich am besten einen Member anlegen, der den Signalstatus enthält.
Ich nutze für sowas immer gerne eine class und zweckentfremde sie als eine Art struct, wie man sie aus C kennt.
Wenn man jetzt in der eigenen Implementierung, alle SetSignalState und SetSignalStateEx weglässt und statdessen,
diese beiden Methoden überimmt, hat man eine viel bessere Kompatibilität hergestellt.
Man kann so sicher gehen, daß jedes Update auch tatsächlich angewandt wird. Man gaukelt Trainz einfach ein Update in DetermineUpdatedState
vor und gibt die durch die eigene Implementierung ermittelten Signalstatus einfach zurück.

include "Signal.gs"




class SSignalState
{
    public string     m_sReason = "";
    public int        m_iState = "";
};




class CMeinSignal isclass Signal
{
    SSignalState      m_SignalState = new SSignalState();




    // ...




    // In der eigenen Implementierung kann man dann, statt SetSignalState
    // oder SetSignalStateEx einfach nur die Member von m_SignalState manipulieren.
    m_SignalState.m_iState = EX_STOP;
    m_SignalState.m_sReason = Constructors.GetTrainzStrings().GetString("$signal_endofline_lbl");




    // ...




    // Jetzt kann ich einfach die Member von m_SignalState an Trainz zurückgeben, 
    // wenn es ein Update des Signals will
    public Soup DetermineUpdatedState(void)
    {
        Soup StateSoup = Constructors.NewSoup();    // Es geht auch: Soup StateSoup = inherited();
                                                    // Allerdings ist bei einer eigenen Implementierung
                                                    // der Logik die Trainzinterne Statusbestimmung irrelevant
                                                    // und kostet nur Performance
                                                    // inherited sorgt dafür, daß die gleiche Methode der
                                                    // Elternklasse aufgerufen wird und speichert das Ergebnis zwischen in StateSoup




        StateSoup.SetNamedTag("state", m_SignalState.m_iState);
        StateSoup.SetNamedTag("reason", m_SignalState.m_sReason);
        return StateSoup;
    }




    public void ApplyUpdatedState(Soup StateSoup)
    {
        // Hier wieder optional: inherited(StateSoup);

        // Falls benötigt wäre hier die Stelle an der anhand des Status aus StateSoup die Lämpchen
        // gesteuert werden müssen, wenn dies nicht an anderer Stelle schon geschehen ist
        int iState = StateSoup.GetNamedTagAsInt("state", EX_STOP); // Lädt "state" mit Standardwert "EX_STOP"

        if(iState == EX_STOP)
        {
            // Hp0, zum Beispiel
        }
    }
};

Danke an Pascal für die, zumindest für mich, sehr interessanten Erläuterungen. Ich hatte mich bisher nur mit SetSignalState beschäftigt und DetermineUpdatedState außen vorgelassen.

Ich habe mir das Skript noch mal angesehen. Das Skript selbst nimmt keine Steuerung der Gleissperrsignale vor, d.h. es übermittelt keine aktiven Steuerbefehle an Trainz. Das Skript übernimmt vielmehr vollständig die Trainz interne Signalsteuerung und richtet daran lediglich die Anzeige der Signallampen aus. Also wenn Trainz das Signal in der internen Logik auf grün stellt, dann schaltet das Skript beim Gleissperrsignale die zwei roten Signallampen ab und die zwei weißen an.

Der einzige Stellbefehl für die interne Trainz-Signallogik, den das Skript enthält, ist ein Befehl, dass das Signal auf Automatik gestellt wird. Ein Befehl, der nicht schadet, eigentlich (aus meiner Sicht zumindest) aber überflüssig ist. Zumindest wenn das Signal in einen Interlocking Tower einbezogen ist, kann man auf den Befehl verzichten, da der Interlocking Tower dann sowieso eine automatische Steuerung des Signals aufzwingt.

Aus meiner Sicht kann es in diesem Fall daher bei der von mir vorgeschlagenen Skriptänderung bleiben. CJ187, ich würde auf dieser Basis die Signale alle überarbeiten und auf Version 3.8 setzen. Dann könnten sie zur DLS geladen werden.

Viele Grüße
wallner

Schoen, Dich nun auch als "Scripter" kennenzulernen. Habe Dich bislang immer "nur" als Streckenbauer wahrgenommen. Freut mich! Leute mit diesen Faehigkeiten sind duenn gesaet!

Mick!

Ich habe die angepassten Signale zur Probe hier im TD hochgeladen. Bei mir haben die Signale beim Einsatz in Interlocking Towers fehlerfrei funktioniert. Falls jemand noch Fehler findet bitte gerne melden. http://www.trainzdepot.net/dow…249-db-lichtsperrsignale/

Hallo CJ187, wenn du mit der Überarbeitung soweit zufrieden bist, würde ich dich bitten, die Signale zur DLS zu schicken. Die kuid-Versionsnummerhabe ich bereits überall um eins nach oben gesetzt. Falls du Fragen oder Änderungswünsche hast, bitte her damit.

Vielen Dank
wallner

So, nun habe ich die Zeit gefunden um mir die Signale, die der Wallner angepasst hat, anzuschauen...

Wie bereits bemerkt, muss ich bei den Signalen mit Build 3.7 arbeiten, da mit Build 3.8 die Lod-Meshes benötigt werden.
Und sorry, ich werde nun keine neuen Modelle dafür erstellen...

Ob nun die Stellwerk-Funktion auch mit 3.7 funktioniert, müsstet ihr mal testen...

Aber ich habe auch noch ein paar kleine änderungen vorgenommen.

zB die Coronas wurden getauscht und sind nun etwas dezenter...
Ein paar Texturen wurden ersetzt.
Das weiße Schild wurde entfernt und die Schrift wurde von Schwarz auf Weiß geändert.

Ich weis noch nicht mal, ob ich die Signale überhaupt noch auf die DLS laden kann, da ja der DLS-Support der Build 3.7 abgelaufen ist...

Vielen Dank, dass du dir die Signale angeschaut hast. Mit Versionsnummer 3.7 gehen die nicht mehr auf die DLS, 3.8 ist das Geringste, was die DLS akzeptiert. Version 3.8 ist allerdings auch noch die letzte, die fehelende LODs nur als Warnung und nicht als Fehler behandelt. Man kann die Signale also ohne LOD mit 3.8 zur DLS laden. Ich habe das probehalber schon mit einem Signal probiert, es hochgeladen und es hat es durch die DLS-Prüfung geschafft.

Zum LOD, ich habe mal kurz daran gedacht einen einfachen schwarzen Kasten zu bauen und den als niedrigstes LOD zu verwenden, aber ich habe keine Abmessungen zu den Signalen. Die Signale werden nach wenigen hundert Metern so klein, dass ein schwarzer Kasten reichen sollte, ohne dass das optisch auffällt.

hm, also bei mir sind die mit build 3.8 fehlerhaft und nicht nutzbar

Also, funktioniert denn das interlocking Tower dings bums mit den Signalen?
Könnte das mal bitt einer der 12 User bestätigen?

Ich habe keine Ahnung von dieser Funktion

Also das Interlocking Tower dings bums wird mit TS12 nicht funktionieren. Um die Signale fit für Interlocking Towers zu machen, muss man den SetSignalState-Befehl abfangen. Dazu ist es notwendig abzufragen, ob das Signal einen Eigentümer "Owner" hat. Dieser Abfragebefehl ist neu und nicht vorhanden in TS12. Das geänderte Script wird in TS12 daher nicht funktionieren. Wenn man die Signale in 3.7 hochlädt, würden sie zwar in TANE funktionieren, man zerschießt sie aber für TS12. Das war der Grund, warum ich vorgeschlagen habe, es in Version 3.8 hochzuladen.

CJ187, hast du mal versucht ein Signal als 3.8 zur DLS zu schicken. Ich habe es aus TANE heraus hochgeladen. Dort hat es funktioniert und es ist auch durch die DLS-Prüfung durchgelaufen und war veröffentlichungsbereit.

Die Änderungen am Skript habe ich gemacht.
Allerdings ist das Signal bei mir mit Build 3.8 fehlerhaft und nicht nutzbar.
Bei mir wurde der DLS Upload verweigert.

Auch dein "Test Signal" kann ich nirgends auf der DLS finden...

TS12 ist eh veraltet und interessiert mich nicht mehr.

TS12 nutzer bleiben bei der alten Version, TANE Nutzer bekommen das update.
Wenn TS12 nutzer das Tane-Update installieren, müssen sie selber das Skript reparieren oder wieder die alte version verwenden...

Nur die Frage ist immernoch:

Funktioniert das jetzt so wie es soll, oder nicht..

Sollte und Müsste genügt mir nicht...

Ich schaue es mir heute Abend an und gebe dir Rückmeldung.

Auf der DLS ist das Probesignal nicht gelandet. Ich habe ja keine Veröffentlichungsberechtigung. Ich habe es nur hochgeladen und gewartet bis es durch die DLS-Prüfung war. Als abschließenden Schritt muss man dann ja noch die Veröffentlichung bestätigen. Das habe ich dann abgebrochen.

_______________________
EDIT: So, ich habe es mir angesehen. CJ187 hat recht, ohne LOD gehts es nicht mit Version 3.8 auf die DLS. Was ich beim Überarbeiten gemacht habe und was auch in den Signalen drin ist, die ich hier im TD hochgeladen habe war folgendes (was dann auch in Version 3.8 zur DLS hochladbar ist): Ich habe das komplette LOD-Konzept in die Signale eingebaut allerdings habe ich als LOD 0 und als LOD 1 Mesh, das selbe vorhandene Mesh genommen. Dann spukt Trainz keine Fehlermeldung aus, sondern nur eine Warnmeldung, dass das kleine LOD Mesh zu wenige Ploy-Count-Reduzierung gegenüber dem großen Mesh hat. Ein gewisser Performance-Vorteil ist durch den Einbau des LOD-Konzepts auch vorhanden, da man darin einstellen kann, ab wann auch das kleinste Mesh komplett ausgeblendet wird, das es zu klein geworden ist, um es zu sehen.

CJ187, vielleicht wäre es am Besten, wenn du mit deinen Änderungen auf den Signalen aufsetzt, die ich hier im TD hochgeladen habe und dort deine weiteren Verbesserungen einfügst. Dann musst du nicht das ganze LOD-Gedöns erst wieder in deine Varianten rüberziehen. Ich hatte bei meinen Versionen auch bereits die kuid2-Nummer um jeweils eins hoch gesetzt. Aber mach natürlich was aus deiner Sicht einfacher ist.

Achso, das Script in deinen Versionen war korrekt geändert. Ich hab zur Probe allerdings nur in zwei Signale reingeschaut. Ich habe auch noch einen Testlauf mit einem Signal in TANE gemacht mit Interlocking Towers. Das verlief fehlerfrei.

Hallo CJ187, ich wollte das Thema noch mal nach oben holen. Hast du es ausprobiert mit dem LOD-Konzept wie in meinem obigen Post geschrieben? Brauchst du noch Unterstützung beim Überarbeiten der Signale? Ich würde mich freuen, wenn die angepassten Signale demnächst den Weg zur DLS finden würden.

Danke und viele Grüße
wallner

Bin noch nicht dazu gekommen.
Bin vorerst auch wieder auf Dienstreise und habe wirklich garkeine Zeit dafür.