Gleissperrsignale für Interlocking Towers

    • T: ANE

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • 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.

      CPU: Intel Core i7-3770K ~ 4 x 3.5GHz // Mainboard: Asus P8Z77-V // RAM: 2 x 8GB DDR3-1333 RAM
      Grafik: GIGABYTE GeForce GTX1080 OC // Soundkarte: Creative Gamer X-Fi
    • 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
    • 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.
      mediafire.com/file/06tkcbdbhob…_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:

      TrainzScript: Beispiel

      1. // Wird aufgerufen, wenn Trainz den Status des Signals einlesen möchte
      2. // Gibt eine Soup mit den Werten "state" (ein Signalstatus-Makro, siehe Klasse "Signal")
      3. // und "reason" (Eine Zeichenkette mit dem Tooltip der beim Mouse-Over am Signal erscheint)
      4. // zurück
      5. public Soup DetermineUpdatedState(void);
      6. // Wird aufgerufen, wenn duruch oben stehende Methode ein Status eingelesen wurde,
      7. // um den neu eingelesenen Status anzuwenden.
      8. // Bekommt als Paramter die Soup aus DetermineUpdatedState
      9. 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.

      TrainzScript: NeuesSignal.gs

      1. include "Signal.gs"
      2. class SSignalState
      3. {
      4. public string m_sReason = "";
      5. public int m_iState = "";
      6. };
      7. class CMeinSignal isclass Signal
      8. {
      9. SSignalState m_SignalState = new SSignalState();
      10. // ...
      11. // In der eigenen Implementierung kann man dann, statt SetSignalState
      12. // oder SetSignalStateEx einfach nur die Member von m_SignalState manipulieren.
      13. m_SignalState.m_iState = EX_STOP;
      14. m_SignalState.m_sReason = Constructors.GetTrainzStrings().GetString("$signal_endofline_lbl");
      15. // ...
      16. // Jetzt kann ich einfach die Member von m_SignalState an Trainz zurückgeben,
      17. // wenn es ein Update des Signals will
      18. public Soup DetermineUpdatedState(void)
      19. {
      20. Soup StateSoup = Constructors.NewSoup(); // Es geht auch: Soup StateSoup = inherited();
      21. // Allerdings ist bei einer eigenen Implementierung
      22. // der Logik die Trainzinterne Statusbestimmung irrelevant
      23. // und kostet nur Performance
      24. // inherited sorgt dafür, daß die gleiche Methode der
      25. // Elternklasse aufgerufen wird und speichert das Ergebnis zwischen in StateSoup
      26. StateSoup.SetNamedTag("state", m_SignalState.m_iState);
      27. StateSoup.SetNamedTag("reason", m_SignalState.m_sReason);
      28. return StateSoup;
      29. }
      30. public void ApplyUpdatedState(Soup StateSoup)
      31. {
      32. // Hier wieder optional: inherited(StateSoup);
      33. // Falls benötigt wäre hier die Stelle an der anhand des Status aus StateSoup die Lämpchen
      34. // gesteuert werden müssen, wenn dies nicht an anderer Stelle schon geschehen ist
      35. int iState = StateSoup.GetNamedTagAsInt("state", EX_STOP); // Lädt "state" mit Standardwert "EX_STOP"
      36. if(iState == EX_STOP)
      37. {
      38. // Hp0, zum Beispiel
      39. }
      40. }
      41. };
      Alles anzeigen
    • 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

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von wallner ()

    • 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. trainzdepot.net/download/index…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...
      Bilder
      • TANE 2017-01-10 03-39-10-44.jpg

        296,21 kB, 1.920×1.080, 15 mal angesehen
      • TANE 2017-01-10 03-39-29-12.jpg

        138,81 kB, 1.920×1.080, 14 mal angesehen
      • TANE 2017-01-10 03-39-35-93.jpg

        152,51 kB, 1.920×1.080, 12 mal angesehen
      Dateien

      CPU: Intel Core i7-3770K ~ 4 x 3.5GHz // Mainboard: Asus P8Z77-V // RAM: 2 x 8GB DDR3-1333 RAM
      Grafik: GIGABYTE GeForce GTX1080 OC // Soundkarte: Creative Gamer X-Fi
    • 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.
    • Build 3.7 geht noch auf die DLS!

      Momentan gehe ich, sofern ich noch aufm letzten Stand bin, auch niedrigere Builds, da das Ganze nun über die Content Repair Group läuft, allzu alte Sachen werden dort geprüft.
      Habe ja selbst die Talent2-Sachen und die Köf2 vor Kurzem noch als 3.7 hochgeladen.

      Davon ab hat N3V auch den Support für TS 12 auf unbestimmte Zeit verlängert (hieß es zum Zeitpunkt, wo TS 12 eigentlich auslaufen sollte). TS 12 hat doch auch noch DLS-Zugriff, oder?
    • 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

      CPU: Intel Core i7-3770K ~ 4 x 3.5GHz // Mainboard: Asus P8Z77-V // RAM: 2 x 8GB DDR3-1333 RAM
      Grafik: GIGABYTE GeForce GTX1080 OC // Soundkarte: Creative Gamer X-Fi
    • 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...

      CPU: Intel Core i7-3770K ~ 4 x 3.5GHz // Mainboard: Asus P8Z77-V // RAM: 2 x 8GB DDR3-1333 RAM
      Grafik: GIGABYTE GeForce GTX1080 OC // Soundkarte: Creative Gamer X-Fi
    • 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.

      Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von wallner ()

    • Neu

      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