Trigger und Skriptmodule für Freewaresignale


Abonniere unseren Kanal auf WhatsApp (klicke hier zum abonnieren).

    Hallo,


    da @143er mit seinen HL-Signalen schon so weit vorangeschritten ist, wird es Zeit, etwas zu den Triggern zu schreiben. Diese sind nämlich in den Skriptpaketen für die Signalbauer nicht enthalten und das aus gutem Grund. Die Frage ist nämlich auch, wie es nun zukünftig weiter gehen soll?


    Da es wahrscheinlich ist, dass mehrere Signalbauer die gleichen Skripte eines Signalsystems nutzen, wie zum Beispiel bei den HL- und EZMG-Signalen oder es mehrere Varianten eines Signalsystems geben könnte, macht es keinen Sinn, die Skriptmodule mit den Signalen gemeinsam zu installieren. Diese würden sich später unweigerlich gegenseitig überschreiben. Deshalb werden die Skriptmodule separat durch mich veröffentlicht und müssen als zweiter Bestandteil vom Anwender installiert werden.
    Im Gegenzug hierzu wird dieses Installationspaket jedoch die Skriptmodule ALLER veröffentlichten Freewaresignale und einen Satz Trigger enthalten. Somit lädt der Anwender alle erstellten Signalsysteme herunter und zusätzlich das Paket mit den Skriptmodulen und Triggern. Ich bin dann auch von den Signalbauern unabhängig, wenn ich Updates veröffentlichen möchte oder muss.


    Die Trigger gibt es für alle Signalsysteme nur einmal. Die Austauschbarkeit ist derzeit bei allen vorhandenen Signalsystemen auch schon gegeben.
    Als Trigger Objekt habe ich ein EditorShapeBlueprint verwendet. Dies bedeutet, dass der Trigger nur im Editor sichtbar ist. Weiterhin erkennt man den Typ jedes Triggers auf der Oberseite.



    Derzeit arbeite ich an diesem Paket, damit es schon für die neuen HL-Signale genutzt werden kann.


    Gruß Schuster

    An dieser Stelle muss ich @Schuster einmal Danke sagen. Ich finde das machen wir hier eh viel zu selten, jemandem zu danken für die ausgezeichneten Ergebnisse die er/sie der Community zur Verfügung stellt. Durch die Skripte und seine kompetente Hilfe war es mir möglich einige Funktionen besser zu verstehen und korrekt umzusetzen. Am Anfang waren meine Nachrichten noch voll von ziemlich vielen Anfängerfragen, doch mittlerweile hat sich das gebessert :) Wenn man dich irgendwie/irgendwo unterstützen kann dann tue ich dies sehr gerne!


    Die HL Signale warten natürlich sehnsüchtig darauf, aber auch mit den Formsignaltriggern war es mir bereits möglich den Funktionsumfang der Signale zu testen. Ein Beispiel dazu findet sich im Anhang! Ersatzrot am HL Signal mit Trigger provoziert.


    vg 143er,
    Moritz

    Hallo,


    kurz vor der Fertigstellung des Trigger-Paketes kam mit noch eine Idee, um das Ersatzrot einfacher nutzen zu können.
    Bisher konnte das Ersatzrot nur durch eine manuelle Signalstörung aktiviert werden. Damit ging das Signal aber im Grunde "außer Betrieb" da anschließend kein Fahrtbegriff mehr signalisiert werden konnte. Durch eine einfache Erweiterung des Hp0-Triggers kann man nun durch Eingabe von "ZE" (Analogie zu "Z1" und "Z7" zum Umschalten zwischen Ersatzsignal und Vorsichtssignal bei den HV-Signalen) das Hauptrot deaktivieren und das Ersatzrot anschalten. Das Signal bleibt weiterhin betriebsbereit. Bei den HV-Signalen wird diese Neuerung zukünftig auch einfließen. :)


    Das Bild ist im Editormodus erstellt worden. Deshalb ist der Trigger noch zu sehen.


    Gruß Schuster

    Hallo,


    das Paket für die Skript-Module und Signal-Trigger ist online. Gleichzeitig habe ich die beiden Pakete für die Erstellung von HV- und HL-Signalen geupdatet. Dort wurde nur die Anleitung überarbeitet. Weiterhin habe ich aus diesen beiden Paketen die bisherigen Installationsdateien für die Skript-Module entfernt. Diese sind nur noch in diesem Paket "Freeware Skript-Module und Signal-Trigger" enthalten. Somit wird es keine überkreuzenden Aktualisierungen geben.


    Im Paket werden immer die Skript-Module für alle veröffentlichten Freewaresignale und die Signal-Trigger enthalten sein. Somit braucht der Anwender nur dieses einzige Paket von mir und dann die jeweils erstellten Signale herunter zu laden und zu installieren.


    Gruß Schuster

    @Schuster,


    In Zusi gibt es die Moeglichkeit, mit einem kleinen Prozentsatz "Chaos" in einem Fahrplan zu erzeugen, so dass, wenn dieser Wert nicht auf 0 steht, jede Fahrt leicht anders sein kann. Gibt es in den Signalskripten die Moeglichkeit ein aehnliches Verhalten durch zufaellig eingestreute rote Signale abzubilden, z.B. durch zufaellige +1 in occupation tables? Mir waere als Lokfuehrer dabei egal, ob es im Block vor mir wirklich einen Zug gibt oder nicht, da ich den ja eh nicht zu Gesicht bekaeme, und Zuege hinter mir waeren auch nicht direkt betroffen. Ob KI Zuege auf Gegengleisen an solchen roten Signalen einfach vorbeifahren waere mir auch egal, da ich einfach gerne groessere PZB Herausforderungen und -abwechslung haette.


    Ich hatte die Stoerungsoptionsvariable mehrfach versucht zu testen, aber selbst von ich die Wahrscheinlichkeitsvariable auf gRandomBug = 1000 (immer gestoert) setze, bekomme ich auf Strecken in denen Schuster Signale verbaut sein sollen an keinem der Signale eine Stoerung. Eventuell waere die zflg. Stoerung ohnehin der falsche Ansatz fuer das von mir gewuenschte Verhalten?

    Zitat von 143er

    Wenn der von dir gewählte Wert von 1000 nicht funktioniert dann liegt das Problem woanders...

    Danke fuer die Antwort: heisst das, das von mir gewuenschte Verhalten so oefter mal (zufaellig) ein restriktives Vorsignal oder rotes Hauptsignal zu bekommen sollte so eigentlich funktionieren (per setzen von gRandomBug)?

    Es ist auch die Frage bei welcher Datei du da was eingestellt hast. Ich bspw. habe unterschiedliche Einstellungen für Form- und Hl Signale eingetragen. Bei den Hl Signalen jedenfalls klappt es bei mir, aber ich habe auch teilweise Skripte von Schuster drauf die mal in der Beta waren (u.a. So16). Da kann ich dir erst am Wochenende eine Rückmeldung geben. Werde auch mal den 1000er Wert ausprobieren. Normal ist das ausreichend für Signalstörungen.

    Hallo StefanDD,


    ja, die Variable gRandomBug ist zuständig für die Warhscheinlichkeit einer Signalstörung.
    0 = keine Signalstörungen
    1000 = im Prinzip sind nun alle Signale gestört
    Dazwischen ist jeder ganzzahlige Wert möglich. Der Wert gilt immer nur für das Signalsystem, für das auch die Optionsdatei gilt. Hier muss man also aufpassen.
    Dieser Wert kann in Szenarien auch mit einem Opt-Trigger-Szenario für alle Signalsysteme gleichzeitig und einheitlich gesetzt werden.


    Bei den HL-Signalen funktioniert diese zufällige Signalstörung auch jetzt schon. Als Störung verbleit das Hauptsignal auf Halt oder wird dunkel geschaltet.
    Ein Vorsignal wird überwiegend dunkel geschaltet oder verbleibt auf Halt erwarten.
    Die Prüfung, ob eine Signalstörung eintreten soll, findet in dem Augenblick statt, wenn das Signal in einen Fahrtbegriff wechseln soll. Sonst nicht.


    Gruß Schuster

    Hallo Schuster,


    Ich weiss jetzt, nach kurzem Studium der Dokumentation der Freeware-Signaltrigger ziemlich genau, was fuer eine Funktionalitaet ich gerne hatte.
    Es waere aus meiner Sicht sehr schoen, wenn man beim Hp0-Trigger zur Erzeugung von Hp0 auf freier Strecke eine Wahrscheinlichkeit definieren koennte, mit der dies eintreten soll, aehnlich der Signalstoerung. Also genau solche Faelle wie in "3.1.1.1. Einsatz zum Erzeugen vom Signalbegriff Hp0" beschrieben, mit dem kleinen Unterschied, dass zusaetzlich zur Zugfolgenummer auch noch eine Wahrscheinlichkeit angegeben kann, mit welcher der Trigger beim Passieren die in der jetztigen Fassung mit 100%-Wahrscheinlichkeit erzeugten Signalmeldungen generiert.


    Man koennte das z.B. so loesen, das im linken Textfeld, in welchem fuer dieses Anwendungsszenario z.B. "0" oder "2" als Zugfolgenummer eingegeben werden, man eingeben kann "0P5" oder "2P1000", also genau wie bei der Randombugvariable mit einer Promillewahrscheinlichkeit die Signalmeldungen mit nur dieser Wahrscheinlichkeit generiert.
    Dann koennte ich mir auf Strecken meiner Wahl diese Trigger vor Signale legen und bekomme mit einer kleinen Wahrscheinlichkeit zufaellig ein Halt -- so dass Quickdrives nicht mehr langweilig sind. Dies waere auch mit allen Szenarien rueckwaertskompatible, denn diese verwenden ja kein "P" im linken Textfeld.


    Gruesse,
    StefanDD

    Hallo StefanDD,


    man kann eine Signalstörung im Szenario auch mit einem Single-Opt-Trigger für ein einzelnes Signal generieren. Mit dem Trigger lässt sich dann die Wahrscheinlichkeit nur für dieses eine Signal hoch setzen. Das Hauptsignal zeigt dann entweder Hp0 an oder ist dunkel. Beides sollte für den Tf dann ein Problem sein.
    Da sich die KI nicht nach den Signalen richtet, sollte die Zugfolgenummer egal sein.


    Gruß Schuster

    Hallo Schuster,


    vielen Dank fuer die Antwort. Es ist mir soweit klar, dass man das in Szenarien machen kann.Ich wuerde die Hp0 Trigger allerdings gerne permanent auf z.B. Hasi v3 verlegen, damit ich spannendere Quickdrives! habe. Gilt in diesem Sinne ein Quickdrive als Szenario? Ausserdem waere es von ganz neuer Flexibilitaet, wenn man dem Trigger eine Wahrscheinlichkeit fuer Hp0 zuordnen koennte. Bitte korrigiere mich, aber das geht doch bisher nur fuer Stoerungen?! Ich moechte, wie in Zusi, ab und zu mal Rot, nicht ab und zu mal dunkel oder Ersatzrot.


    Besten Dank -- StefanDD

    Hallo StefanDD,


    also man kann den Single-Opt-Trigger auch permanent auf eine Strecke legen. Somit sollte der gleiche Effekt erzielbar sein.
    Die Signalstörung wirkt sich halt manchmal auch als dunkles Signal aus. Eine Auswahl gibt es hier nicht. Da es sich um eine Störung handelt ist das Ergebnis wohl relativ zufällig.


    Ich glaube es gibt so einige Dinge nicht, die möglich wären. *denk*


    Gruß Schuster

    Irgendwie erklaere ich wahrscheinlich nicht praezise genug, was ich vorschlagen will. Ich moechte keine Signalstoerung erzeugen -- ich moechte ein normales Hp0 inkl. entsprechender Vorsignalstellung erzeugen, indem ich den Hp0 Trigger verlege und gemaess "3.1.1.1. Einsatz zum Erzeugen vom Signalbegriff Hp0" nutze. Der einzige vorgeschlagene Unterschied zur deutlichen Erhoehung der Flexibilitaet ist, eine Wahrscheinlichkeit dafuer definieren zu koennen, dass der Trigger diese Signalstellung per SendSignalMessage auch wirklich ausloest. Dazu waere, denke ich, eine nur sehr kleine Modifikation des Triggercodes in OnConsistPass noetig.
    Dazu hatte ich vorgeschlagen im linken Eingabefeld im Editor fuer die Triggeroptionen statt "0" (fuer alle consists) "0P50" eingeben zu koennen, so dass der Trigger nur mit 5-prozentiger Wahrscheinlichkeit ausloest.