Autor Thema: Erweiterung von Signalbegriffen  (Gelesen 3795 mal)

Danty

  • Krawallteufel
  • Globaler Moderator
  • *****
  • Beiträge: 215
Erweiterung von Signalbegriffen
« am: 10. März 2009, 10:13:08 »
Vor knapp einem Jahr gab's da ein Thema über Signalbegriffe.
Nachdem in der Praxis doch verbreitet Geschwindigkeitsanzeiger auf Signalen zu finden sind, diese jedoch im MSTS sehr selten zu finden sind, habe ich einen Versuch aus dem Jahre 2004 ausgegraben :


Da Schnellbahner an diesen Anzeigern (primär an den Lichtsignalen) interessiert war, habe ich mich noch einmal genauer mit diesem Thema auseinandergesetzt. Nach einigen Fehlermeldungen und Tests konnte nun eine Lösung erzielt werden.
Nach meinen Erkenntnissen ist eine Erweiterung von bestehenden Signalpaketen davon abhängig, nach welchem Prinzip die Signalkonfigurationen und Scripts aufgebaut sind.

Dabei sind mit 2 grundsätzliche Varianten aufgefallen :

1. "System Signalfeatures" (z.B. MzB-Signale) : Hier wird grundsätzlich pro Signalform (Shape) ein Signaltyp definiert, dessen Begriffe (Frei, 40, 60) mittels Signalfeatures (Prüfung auf Fahrweg 40/60, immer 40, immer 60) ausgewählt werden können. Vorteil dieser Methode ist eindeutig eine geringe Anzahl von Signaltypen und damit recht übersichtliche Konfigurationen und Scripts. Leider sind die Signalfeatures nur mit den Rückgabewerten "USER_1 bis USER_4" belegbar, wodurch man auf 4 Möglichkeiten limitiert ist. In der Praxis reicht das für ein 4-begriffiges Signal aus, weitere Begriffe mit Geschwindigkeitsanzeigern konnte ich aber nicht mehr einbauen.

2. "System Signaltypen" (z.B. Viper-Signalpack) : Konfigurationen uns Scripts unterscheiden sich hier grundlegend vom vorher beschriebenen System. Grundsätzlich gibt es pro Option (Frei, Weiche 40, Weiche 60 usw.) ein eigenes Script samt Signaltype. Zusätzlich wird zwischen Einfahr- (auch als Blocksignal verwendbar) und Ausfahrsignalen unterschieden, da die Aufhebung einer Weichenbeschränkung (Weichenbereichsende) hier anders zu berücksichtigen ist.
Damit ergeben sich für ein normales vierbegriffiges Haupsignal immerhin 10 Signaltypen bzw. Scripts (Frei, Weiche 40, Weiche 60, 40, 60 und das jeweils für Ein- und Ausfahrt). Das bedeutet zwar innerhalb kürzester Zeit eine Unzahl von Signaltypen, bringt aber den Vorteil, dass man dieses System unbegrenzt erweitern kann (vorausgesetzt, man verliert dann irgendwann nicht die Übersicht in der Buchstaben- und Klammernsuppe ;) ). Folglich ist es kein großes Mirakel, neben bzw. auf vorhandene Signale einen Geschwindigkeitsanzeiger (egal, ob Lichtsignal oder Tafel) zu setzen und die zusätzlich erforderlichen Signaltypen zu ergänzen.

Bei Schnellbahners Signalen war es jedenfalls erforderlich, die gesamte Konfiguration samt Scripts auf das System "Signaltypen" umzuschreiben, damit auch die Anzeiger für 50, 80, 100 und 120 km/h realisiert werden können. Ob's wirklich nötig war, bin ich mir nicht sicher, aber die "Gewaltaktion" hat den gewünschten Erfolg gebracht und kann bei Bedarf noch erweitert werden.

Falls da jemand ebenfalls diesbezügliche Erfahrungen hat, bitte hier einwerfen.

liftwartbertl

  • Fahrdienstleiter
  • *****
  • Beiträge: 517
Re: Erweiterung von Signalbegriffen
« Antwort #1 am: 10. März 2009, 19:51:50 »
Könntest du das Know-how nicht an Trainheinz übermitteln, dann könnte er sie vl. für sein Westbahnprojekt verwenden.

Danty

  • Krawallteufel
  • Globaler Moderator
  • *****
  • Beiträge: 215
Re: Erweiterung von Signalbegriffen
« Antwort #2 am: 10. März 2009, 21:47:04 »
Soll kein Problem sein, wenn Bedarf ist. Da einige Erkenntnisse erst in den letzten Tagen gewonnen wurden, habe ich diese hier jetzt einmal hier deponiert und hoffe, dass sich noch weitere Leute finden, die dazu etwas wissen.

Grundsätzlich ist aber eine Signalkonfiguration eine höchst streckenspezifische Sache, weil dort drinnen alle vorkommenden Signale und möglichen Begriffe definiert werden müssen und das kann schon mitunter recht umfangreich werden. Hauptproblem ist dann eher eine Klammer oder eine Zählvariable, die sich irgendwo verirrt hat und dann mächtigen Ärger verursachen kann. Auch wenn ich Sigmexx nicht zum Erstellen von Konfigurationen und Scripts verwende, als Prüfinstrument hat es mir recht gute Dienste geleistet.