Signalbibliothek für T:ANE & Interlocking Towers

Zitat von grisu07

In solchen Momenten verstehe ich dann, warum der Autor von DBsig seinen eigenen Weg gegangen ist.

Was meint ihr? Was sollte man sinnvollerweise beobachten, und wie weit?

Vor diesem Punkt stand der Entwickler von DBsig wohl auch. Im weiteren musst Du Dir natürlich auch die Frage stellen, welche Funktionen baue ich mit welchem Aufwand ein. Und noch wichtiger, welche Anzahl an User bei Trainz nutzen es am Ende wirklich. Wenn es jedoch um Selbstverwirklichung geht, stellt sich diese Frage natürlich erstmal nicht.

Wenn man nun eine Funktion für alle verfügbaren Signale schafft, wie sieht es mit Blick auf die Zukunft aus? Was bringt ein Signalsystem für alle Signale wenn es kein PZB / LZB gibt bzw. es ja schon an den Loks und deren Funktionen scheitert. Die Frage ist also wie weit möchte ich dieses Thema treiben.

Ein umfangreiches System ist ein wichtiger Schritt, aber zur Abbildung von Betriebsabläufen im Ansatz fehlen halt nach wie vor ein globales PZB / LZB. Und hier wird man mit einer Globalen Lösung wohl immer Kompromisse eingehen müssen. Bis dahin ist in meinen Augen ein Signalsystem in Trainz immer irgendwie eine Optische sowie Zweckmässige Lösung.

Ab diesem Punkt stellt sich nun wieder die Frage ob ein in sich geschlossenes System mit Signalen, PZB / LZB, eigenen Fahrwegsystem und Loks dazu nicht langfristig die bessere Lösung ist.

Wollte mich nur mal eben als "noch lebendig" melden.
Danke nochmal für die Hilfe und die Erklärungen.

Ich bin übrigens noch weiter mit dem Projekt beschäftigt.
Ich finde es recht unpraktisch, dass man die Pfade nur aus dem Tower konfigurieren kann, deshalb habe ich mal versucht, das direkt ins Signal einzubauen. Klappt ganz gut:

Hallo an alle TrainzDepot-Mitglieder (ich bin komplett neu hier),

ich hoffe, dass sich aus dieser Arbeit eine KS/HV Signalbibliothek ergeben wird. Ich habe fuer den TS PZB und LZB Module geschrieben, die im TS in kommerziellen Addons verbaut sind und die ein hohes Mass an Akkuratheit besitzen. Ich wuerde die sehr gerne irgendwie der deutschen T:ANE community zugaenglich machen/ auf Trainzscript portieren (das waere technisch ueberhaupt kein Problem; es gibt keine Skriptsprachenelemente in Lua die Trainzscript nicht haette).

Allerdings muesste man dann eben einheitliche Signaltrigger entwickeln (PZB Magnete, LZB Blockgeschwindigkeitswechsel) die die PZB oder LZB Skripte mit dem Signalsystem koppeln. Eine solche Arbeit wuerde am besten in Zusammenarbeit mit jemand/oder einer Grupper von Leuten erfolgen, der/die am Signalsystem arbeitet(en). Also meine Frage: ist so ein Vorhaben realistisch und gibt es genug interessierte und "Macher" in der deutschen T:ANE um so etwas durchzuziehen?

Zitat von StefanDD

ich hoffe, dass sich aus dieser Arbeit eine KS/HV Signalbibliothek ergeben wird.

Da haben wir bereits ein sehr gute Grundlage, die bis T:ANE SP1 einwandfrei funktioniert.

Zitat von StefanDD

HaIch habe fuer den TS PZB und LZB Module geschrieben, die im TS in kommerziellen Addons verbaut sind und die ein hohes Mass an Akkuratheit besitzen. Ich wuerde die sehr gerne irgendwie der deutschen T:ANE community zugaenglich machen/ auf Trainzscript portieren (das waere technisch ueberhaupt kein Problem; es gibt keine Skriptsprachenelemente in Lua die Trainzscript nicht haette).

Auch hier gibt es bereits eine Grundlage, die sogar noch etwas weiter ins Detail geht. Die PZB wird durch Trigger gesteuert, die dem Fahrzeug einfach mitteilt,

dass eine Beeinflussung satt findet:

Nachrichten:

"PZB", "1000Hz"

"PZB", "500Hz"

"PZB", "2000Hz"

Allerdings ist das mit den Nachrichten in der kommenden Version SP2 von T:ANE nicht mehr so einfach möglich. Das Nachrichtensystem wurde nämlich grundsätzlich umegbaut, sodass Objekte nicht mehr durch ihren Namen oder ihrer ID, sondern über ihre sog. GameObjectID (das ist eine Klasse in Script, wahrscheinlich ein struct im Native Code) angesteuert werden können.

Bei der LZB haben wir bereits zwei Ansätze. Einmal der, dass es einen Streckenrechner gibt und einen, bei dem technisch gesehen jedes Fahrzeug einen eigenen Streckenrechner bekommt. Der erste wird in T:ANE Sp2 ebenfalls nicht weiter funktionieren. Wenn die Strecke mit den nötigen Blockkennzeichen und VMax-Werten bestückt worden ist, macht Variante 2 den besseren Eindruck. Im Einzelspieler würden somit nur Berechnungen für das mit der LZB geführte Fahrzeug des Spielers angestellt, nicht aber für die KI. Bei der ersten Variante werden Führungsgröße und VMax der Fahrzeuge für alle in der LZB befindlichen Fahrzeuge berechnet. Ein weiterer Nachteil unseres ersten Ansatzes ist der, dass die Strecke zuvor gänzlich dem Streckenrechner angegeben werden muss. Die Konfiguration dauert dann einfach ewig. Variante 2 wäre also eine Out-Of-The-Box funktionsfähige Variante, sofern die nötigen Signale und Objekte entland der Strecke gesetzt worden sind.

Zitat von StefanDD

Allerdings muesste man dann eben einheitliche Signaltrigger entwickeln (PZB Magnete, LZB Blockgeschwindigkeitswechsel) die die PZB oder LZB Skripte mit dem Signalsystem koppeln. Eine solche Arbeit wuerde am besten in Zusammenarbeit mit jemand/oder einer Grupper von Leuten erfolgen, der/die am Signalsystem arbeitet(en).

Wenn man eine Bibliothek schreibt, lässt es sich einrichten, dass alle Klassen von den anderen Klassen "wissen". Das war damals die große Neuerung, die wir lange erwartet hatten.

Somit war es uns möglich, vieles, das sonst über das Nachrichtensystem in Trainz gegangen ist, jetzt über Methoden-Aufrufe machen können. Du kannst also direkt Signal und Trigger koppeln, indem einfach ein Verweis in der Konfiguration des Signals im Editor von T:ANE erfolgt.

T:ANE SP2 wird eine große Neuerung. DBSig, also das Signalsystem, um das es hier geht, liegt in einer SP1 Version auf der DLS. Tests im SP2 haben ergeben, dass ein Umstieg vom DBSig-Fahrstraßensystem auf Interlockting Tower (eingebautes Fahrstraßensystem) nun unumgänglich ist. Ziel wird es sein, für jeden Fahrweg das Signalbild zu bestimmen, der alte Marker-Ansatz würde dann wegfallen.

Weiter ist das Ziel, für Fahrwege auch Varianten anzugeben, sodaß eine Rangierfahrt (darunter unterscheidet DBSig ja!) nicht auf ein Hp-Signal ausfahren kann, sondern nur über Sh1.

Die Möglichkeiten dort sind nahezu unbegrenzt.

Außerdem:

DBSig besitzt in einer internen Version einen Stellwerksimulator. Dort sitzt du als Fdl in deinem Stellwerk und siehst draußen im BW/Bahnhof die Züge, denen du dann Fahrwege stellen musst.

Das ganze funktioniert mit unserem 24-h Fahrplan. Damit kannst du bei einer Strecke eine Aufgabe erstellen, bei der der Spieler zu einer beliebigen Uhrzeit einspringen kann. Die Züge werden dann automatisch nach einer Liste abgearbeitet. Für uns liegt ein Bahnhof vor, der einen Fahrplan dem von Rheydt Hbf (Mönchengladbach) entspricht, sich allerdings der Bahnhof anders nennt.

Weiter ist bei den Signalen geplant, die Änderung der Lichter als Animation darzustellen. Damit hat man gleich zwei Fliegen mit einer Klappe geschlagen:

- Das Umschalten der Lichter sieht etwas realistischer aus, es ist kein Thread im Script zuständig, der Sleep-Aufrufe macht

- Formsignale sind einfacher zu machen, denn HV-Scripts liegen bereits vor

Zitat von StefanDD

Eine solche Arbeit wuerde am besten in Zusammenarbeit mit jemand/oder einer Grupper von Leuten erfolgen, der/die am Signalsystem arbeitet(en). Also meine Frage: ist so ein Vorhaben realistisch und gibt es genug interessierte und "Macher" in der deutschen T:ANE um so etwas durchzuziehen?

Wir, die JTG, sind ein guter Partner dafür, da wir sowohl TS als auch T:ANE sehr gut kennen und schon lange mit beiden arbeiten. Das Signalsystem ist in der letzten Version ziemlich ausgereift, nur leider kommt nun das SP2. Eine Neuentwicklung im Grundsatz ist da erforderlich. Wir haben auch schon eine nicht kleine Anzahl an Rollmaterial für dieses System angepasst bzw. anpassen dürfen.

Wieso sollte man da nicht zusammenarbeiten?

PS: Nur eine Sache ist uns wichtig, es muss Freeware (in Trainz) bleiben...

Hallo Basti,

ich habe noch keine Lok gesehen welche LZB/PZB und ein Zusammenspiel mit Signalen bietet sodass ich die von Dir angesprochene Systeme nur als reiner Nutzer kenne, und mir aus technischer Sicht kein Urteil bilden kann bzw. dies falsch wäre. Somit bleibt mir nur von "unserem" Ansatz erzählen. Hierzu müssten die beiden sich selbst äußern - mir fehlen die Details darüber.

Zitat von Sebastian

vielleicht schafft man ja letzten Endes eine übergreifende Kompatibilität zwischen den einzelnen Ansätzen. Ich finde nichts schlimmer als unterschiedliche Systeme, die sich am Ende nicht kombinieren lassen

Mit dem SP2 kein Thema mehr. (Wenn man sich an das hält was Chris im DEV Forum geschrieben hat)

^{/OT
PS: Pascal ist bei Trainz nur noch beratend tätig}

Was meinstest du genau? Ein Zusammenspiel zwischen einem KS Signal (Z.b. von Autor A) und einem Formsignal (z.b. von Autor B)

Ich verstehe nicht wo es ausgenommen von Zugsicherung und oben beschriebenen Beispiel Schnittmengen geben sollte welche zu Problemen führen könnte.

Kann ich bei einem kompletten System zwar auch nur schwer verstehen, auch Eisenbahntechnisch in T:ANE nur bedingt nachvollziehen. Man macht z.b. bei einem Signal mit dem System A "Schluss" und übergibt an System "B" z.b. durch unsichbare oder "Rot / Grün" Signal. Beispiel bei einem Übergang von KS auf HV, auch dies ist heute schon möglich*, ausgenommen der CC weigert sich oder baut bewusst "Sperren" ein. (hätte ich oben besser formulieren sollen - mein Fehler)

Ausgenommen man arbeitet als Streckenersteller mit sagen wir mal einzigartigen Signalzusammenstellungen, aber da ist ja dann der Ersteller in der Verantwortung und nicht die Systeme an sich.

Mit dem SP 2 ist diese Befürchtung eh obsolete, wenn alle sich an die Aussagen wie oben aus dem DEV Forum halten..

*manche bieten dafür Trigger an

RiccardoInter [ITA]

vielen Dank fuer die ausfuehrliche Schilderung des Ist-Zustandes. Das klingt allerdings so, als ob es noch Monate-bis-Jahre dauern wird, ehe ein Signalsystem welches auf SP2 basiert, Magnetmeldungen an eine PZB schicken kann. Leider kenne ich mich mit Signaltechnik viel weniger aus, als mit den Zugsicherungssystemen, so dass ich leider nicht wirklich an der Entwicklung eines Signalsystems fuer SP2 mithelfen kann. Was ich sehr gerne und natuerlich auf Freewarebasis tun will ist, sobald sich ein solches System herauskristallisiert oder wenigstens die Funktionsweise festgelegt ist, die PZB / LZB Skripte von TS auf Trainzscript portieren und an dieses System anpassen, damit auch fuer T:ANE eine PZB/LZB auf einem technischen Niveau nahe Zusi-3 existiert -- je kostenloser, desto besser!

^{Inhalt aus Beitrag oben zur Übersicht:}

Hallo Stefan,

Der Ist-Zustand ist insofern unbefriedigend, da mit dem SP2 massive Änderungen stattfinden welche ein Umdenken erfordern. Das System an sich ist fertig, muss jedoch komplett neu angepasst werden. D.h. wir sind in der jetzigen Situation mit dem SP2 soweit, dass wir aus Entwicklersicht einen großen Schritt machen müssen. Vergleichbar mit einem Umstieg von TS auf TSW (Aus Entwicklersicht). Wie groß der wirklich Aufwand am Ende ist - SP2 unterliegt intern noch Änderungen - kann man jetzt nicht abschätzen. Mit jedoch 7 Mann im Team dürfte der Aufwand dann doch überschaubar sein.

Gerade dieses Servicepack bringt massive positive Veränderungen welche es bis dahin in diesem Umfang noch nicht gab, d.h. auch für uns alle hier wird das relatives Neuland. Gerade auch weil der Hersteller (ähnlich wie DTG) für Änderungen in letzer Minute bekannt ist. D.h. wirklich ernsthaft entwicklen kannst du erst mit der finalen Version.

Was jedoch wirklich massiv Zeit in Anspruch nehmen wird, ist der Neubau von Rollmaterial respektiven Führerstände welche so ein System letztlich anzeigen. Hier ist man bei Trainz noch Jahrzehnte hinter dem was du gewohnt bist. - Einen Füherstand auf DTG Niveau inkl. Funktionen findest du hier leider noch nicht.

Zitat von geophil

Implementierungen deutscher Signalsysteme für T:ANE, untereinander nicht kompatibel. Zwar versucht T:ANE, durch die eingebaute S

Dies ist gefährliches Halbwissen, wenn man sich mit den Systemen beschäftigt hätte wüsste man, dass sogar Elemente übergreifend miteinander zum Einsatz gebracht werden. Auch eine rhetorisch unterstellte Fokussierung der jeweiligen Autoren auf ihre eignen Schöpfungen ist ein Mythos welcher erst durch Foren entstanden ist.

Zitat von geophil

Da muss man Realist bleiben, das wird nicht gelingen. In Zusi sind die Zugsicherungssysteme nativ, Funktion und Schnittstellen werden vom System in einheitlicher und umfassender Weise vorgegeben. Strecken- und fahrzeugseitige Ausrüstung reduziert sich damit auf reine Konfiguration,

Ich vermute Stefan wollte damit etwas anderes zum Ausdruck bringen, und es ging vermutlich weniger um die Umsetzung sondern um Funktionsumfang. Aber schön mal wieder was von Zusi zu lesen, war lange bedauerlicherweise in vielen Fremdforen kein Thema mehr.

Zitat von siebziger

Starker Tobak...

Auch hier, wer die Systeme nutzt wird diesen "Starken Tobak" von sich aus sehr schnell zur Kenntnis nehmen. Wer natürlich rein lesend aktiv ist, für den scheinen solche hier geführten Diskussionen rein zur Erheiterung zu dienen.

Sicher hast du Verständnis, dass gerade du für mich durch die Vergangenheit der falsche Gesprächspartner bist wenn es um Elemente der Zugsicherung in Trainz geht.