StellSi Binary

nicht vorhanden

Ein mit einer Teilfahrstraße in den Bahnhof eingelassener Zug muss die Weichenbereichsregel beachten, d.h. z.B. die 40 km/h bis zum Asig beibehalten, und nicht bereits beschleunigen, sobald die Gleise es hergeben.

Vermutlich müsste die Information über die im eigenen Stellbereich mögliche signalisierte Geschwindigkeit von der Relaisanlage an den Streckenanschluss, und von diesem beim Aufgleisen dem Zug mitgegeben werden.

Fallbeispiel: Beilheim Hbf, Einfahrt von 620/691 nach Gleis 2.

nicht vorhanden

Siehe 14.01.2024

Notwendige Abhängigkeiten:
* Befehl 7 für Fahrten vom KI-Nachbarn
* (Befehl 7 für Fahrten vom HI-Nachbarn ist schon Funktionsfähig.)
* Befehl 12 zumindest zwischen Signalen
* (Befehl 8 wenn BÜ so weit sind)
* (Vmtl. noch Befehl 14.6 und 14.35)
* Befehl A/B/C als Alternative zu Befehlen
* Zs12 als weitere Alternative

nicht vorhanden

Für Gruppentasten wäre es sinnvoll, dass man in Polygonen die Farbzuordnung aus der Bibliothek nutzen kann. (bspw. bgcolor=”.olivgreen”)

Zum einen lässt sich dadurch auch eine Farbvariation in Gruppentasten einbauen und zum anderen kann man bequem die Farbe anpassen, wenn es neue Erkenntnisse bei den RAL-Farbcodes gibt.

Lösungsidee: Eine Tabelle, wo man für verschiedene “Ansichten” definieren kann, in welchem Fenster ein Raster angezeigt werden und an welcher Koordinate. Auf stwk- oder auf stwt-Basis? (s. auch 26.01.2023)

Das S60 (und einige andere Bauformen) implementieren Gesamthilfsuaflösung so, dass erst die FHT gedrückt wird, und dann innerhalb von wenigen Sekunden Start+Ziel bedient werden. Wir haben derzeit eine Dreitastenbedienung, u.a. weil die Einzelauflösung im Vorbild als Zweitastenbedienung von FHT und WT umgesetzt wird. Die Unterscheidung zwischen der Zwei- und der Dreitastenbedienung erfolgt über den Signalnamen der Innentaste (signaltaste vs weichentaste)
Im Dr S ist die Problematik, dass diese Unterscheidung nicht funktioniert, da die D-Weg-Hilfsauflösung in Zweitastenbedienung von FHT und Gleistaste erfolgt, während die Fahrstraßen-Hilfsauflösung wie beim S60 durch vorab-Bedienung der FHT erfolgt. Hier ist in beiden Fällen dieselbe Innentaste (gleistaste) beteiligt.

Für eine vorbildgerechte Bedienung (und zur Lösung des Dr-S-Problems) folgender Vorschlag: Ein Doppelklick auf eine Taste löst eine sofortige Bedienung aus (anstatt noch auf weitere Tasten-Vormerkungen zu warten). Gesamtauflösung würde dann per Doppelklick auf die FHT und anschließender Bedienung von Start+Ziel erfolgen.

Bei mehrfach verbundenen Ausgangssignalen - i.d.R. mehrfach vorhandenen Gruppentasten, oder die Fahrstraßenwahl vom S60 - kommt es zu Race-Conditions. StellSi bildet kein Maximum aus den Inputs (wie etwa bei RingleitungParallel), sondern das zuletzt empfangene Signal wird ausgewertet (daher: getRecentIntWert statt getIntWert). Das kann dazu führen, dass im S60 unbeteiligte Relaisgruppen unzeitig 0-Werte in die Fahrstraßenwahl senden, die die Fahrstraßenwahl einer gerade zu bildenden Fahrstraße torpedieren. Zweites (konstruiertes) Beispiel: Zwei WGTs auf der Stellwand. Beide per rechtsklick festhalten. Löst man dann die erste, nimmt das Stellwerk das als Loslassen der WGT wahr, obwohl die andere WGT noch gedrückt ist.

Den Strings in Angelscript fehlt eine Memberfunktion string.count(), um deren Länge zu erfragen. Stattdessen behelfen wir uns in diversen Bibliotheken (u.a. ZN, Nstp, DET) mit einer ineffizienten Krücke: string.split(”“).count().

Weiterhin fehlt eine Memberfunktion, um einzelne Zeichen abzurufen, string.at(i). Mit dieser könnte das Kopieren von Strings in String-Listen mittels split(”“) in vielen Fällen vermieden werden.

Auch diverse andere übliche String-Funktionen fehlen, etwa
- string.substring(i, j), die derzeit mit string.split(”“).at(0) + string.split(”“).at(1) + ... emuliert werden muss.
- string.contains(x)

Konkret:
* Hauptsignal
* Standort Höhe Asig/Esig
* Gruppenausfahrsignal
* Sperrsignal für Gruppenausfahrt
* SFB-Signal als Ls

22:05 08.04.2021
<Suedwest> Unser StellSi E50 ist mit Zs3 “60” inkompatibel. :P
<Suedwest> Steht auch so in der Beschreibung. :P
<Hl13> dafür hatte ich auch mal eine Idee
<MrX> vermutlich weil die Züge dann 50 fahren?
<Hl13> man könnte die Signalbedeutungen mit “Leveln” versehen, und der Begriff mit dem höchsten Level wird dann wirksam
<Hl13> damit könnte man auch Ersatzsignale an Formsignalen in eigene Schirme packen usw
<Suedwest> Ob das überhaupt sinnig ist, das dort auszulagern?

nicht vorhanden

Um bei überlagerten Tischfeldern die Zeichenreihenfolge ändern zu können, wäre eine Verschiebe-Option sinnvoll. Die derzeitige Lösung, entweder Bearbeiten per Texteditor, oder Löschen und in der richtigen Reihenfolge neu anlegen, ist unbefriedigend.

Die Elemente werden in der Reihenfolge gezeichnet, wie sie innerhalb eines Rasters in der .stwt-Datei stehen. Entsprechend könnte eine “In den Hintergrund”-Funktion ein Element ganz nach oben in dem Raster verschieben. Die Option könnte im Parametereditor analog zum Spiegeln im Kontextmenü angeboten werden (nicht schön, aber eben wenigstens konsistent zum Spiegeln).

Previewconfigs werden derzeit alle nebeneinander dargestellt. Das ist bei Feldern mit vielen Previews (z.B. Gruppentasten, insbesondere beim L60) unerfreulich.

Hilfreich wäre, wenn diese Zeilen, abhängig von der Breite der Seitenleiste, umgebrochen würden. Dabei sollte in einer neuen Zeile eine Einrückung um eine Feldbreite erfolgen, um Tischfeldvarianten klar von anderen Tischfeldern unterscheiden zu können.

Es wäre hilfreich, wenn in der Stelltisch-Liste die Hintergrundfarbe des Standardrasters aus der Tischfeldbibliothek hinterlegt würde. Dann wäre es z.B. bei den ZNP801-Monitor-Feldern wesentlich leichter, zu erkennen, worum es sich handelt.

Das System zur Auswertung, ob eine Zugfahrt an einem Signal zugelassen ist, ist mindestens für die Nachbildung aktueller deutscher Regelungen unzureichend.
Insbesondere folgende Punkte sind problematisch:
* Das System bietet keine Differenzierungsmöglichkeit bezüglich des Grund des Halts (planmäßig, wegen Signal, unvorhergesehen).
* Das System bietet keine Differenzierungsmöglichkeit bezüglich des Standorts des Zuges (Bf oder freie Strecke) oder mindestens bezüglich des zuletzt überfahrenen Signals.
* Das System bietet für gewisse Randfälle (z. B. Zugspitze steht über Signal hinaus, Bahnhöfe ohne Asig) keine Lösung.
* In das System lässt sich ein Zp 9 nur schwer / gar nicht einfügen.
* Das System bietet keine Möglichkeit für Geschwindigkeitsherabsetzungen ab Halteplatz.
* Das System hebt die Geschwindigkeitsbeschränkung wegen einer Fahrt auf besonderen Auftrag bereits am Halteplatz auf.

Es sollte daher ein erweitertes oder neues Konzept aufgestellt werden, wie mit den Anforderungen umgegangen werden kann, möglicherweise auch im Hinblick auf historische oder ausländische Regelungen.

Notizen zur aktuellen Regelung: https://pastebin.com/13Rxwq8X

Daraus abgeleitete Umsortierung, möglicherweise geeigneter zur Implementierung: https://pastebin.com/x5tW761s (nicht ganz so scharf formuliert, bitte sinngemäß betrachten)

Bei den Zeitraffer-Reglern führt die Nutzung des Mausrads oder ein Klicken zwar zu einer visuellen Verschiebung des Reglers, aber der Faktor ändert sich nicht. Man muss schieben.

Die Wahrscheinlichkeits-Graphen im Random-UI sollten ihre Achsenlängen an die Größe des Fensters anpassen. Derzeit ist die Größe statisch, und so gewählt, dass standardmäßig eine vertikale Scrollbar nötig ist.

Das UI im Hauptfenster zum Thema Zufall hat anstelle gewöhnlicher Tabs drei untereinander angeordnete quadratische Buttons mit Bildern, die offenbar als Tab-Reiter fungieren. Diese Wirkung ist nicht ersichtlich, die Buttons rasten bspw. nicht ein, wenn die zugehörige “Registerkarte” gezeigt wird. Ein vierter Button (Lupe) funktioniert irritierenderweise völlig anders: Er wird nur in manchen “Reitern” gezeigt, und öffnet ein Kontextmenü.

Ich würde anstelle der Buttons gewöhnliche Tabs vorschlagen mit einer Text-Beschriftung statt der Bilder.

In der Auswahlleiste der Tischfelder sollte per Tooltip dessen Name angezeigt werden, um es dort wiederfinden zu können, wo es nur per Name aufgelistet wird.

Zeitsprünge sind in Version 0.0.9.20 langsam und verursachen Speicherverbrauch. Dieser ist abhängig von der Größe der geladenen Dinge, vermutlich von der Fahrplangröße.

In Dortmund-Barop (Fpljahr 2017) mit jedem Sprung um 1 Tag rückwärts 2-3 MB, und ca. 1sek.
In Dortmund Hbf mit fs (Fpljahr 2017) mit jedem Sprung 40 MB und 60 sek

Reproduktion (am 18.11.2020, kA ob das jeden Tag funktioniert).
- StellSi starten, Klemin Hbf laden
- Uhr auf 4:23 Uhr stellen
- Fahrplan laden
- Jetzt zu Fahrplanstartzeit Fr 2020-12-18 06:00:15 springen
- StellSi spawnt jetzt drei Züge, und bietet einen Zug über Gleis 140 an, der aber nicht kommen wird, aber verhindert, dass die fahrplanmäßigen Züge kommen

Lehnt man einen per ZN angebotenen Zug ab, wird einem der abgelehnte Zug nicht wieder angeboten. Im Telefon ist auch keine Option, den Zug “anzufordern”, dort taucht aber stattdessen die merkwürdige Option auf, dass er Züge auf VzG 123 nicht mehr anbieten müsse. Bewirken tut das aber augenscheinlich nichts.

Sinnvoll wäre, wenn der Nachbar den Zug nach gewisser Zeit wieder anbieten würde (bspw. Zeitablauf, oder natürlich, wenn in der Zwischenzeit etwas in Gegenrichtung gefahren ist).