Die Story-Infrastruktur

Story-Infrastruktur

Einleitung

Im Beitrag →Story 1 – Köf tanken wurde die erste Story vorgestellt; inklusive der beiden beispielhaften Verläufe →Verlauf 1 und →Verlauf 2. Wesentliches Kernelement der Story ist das →Xml-Script, welches alle möglichen Storyverläufe organisiert. Dazu sind aber auch gewisse Voraussetzungen bzw. eine Infrastruktur erforderlich, um die es in diesem Beitrag geht. Nur wenn diese Voraussetzungen alle stimmig kombiniert sind, kann die Story wie gewünscht funktionieren.

Das Video zum Beitrag

Überblick

Regelmäßiger Aufruf der Story

Wie in den verlinkten Artikeln bereits angedeutet, muss das Story-Xml in relativ kurzen Abständen von ca. 2-3 Sekunden regelmäßig aufgerufen werden. Dazu wird eine Rocrail-Aktion eingerichtet, die wiederum von der Modellzeit getriggert wird. Das Bild zeigt diesen Zusammenhang:

Überblick (englisch) über den Mechanismus hinter den Stories (StoryTick.xml = StoryTrigger.xml)

Rocrail-Einstellungen für den regelmäßigen Aufruf

Die folgenden Einstellungen müssen in Rocrail genau angepasst werden:

Kurze Zeiteinheit

In den Rocrail-Eigenschaften (nicht Rocview! => Automatik muss AUS sein) muss folgende Option gecheckt (angehakt) sein:

  • Rocrail-Eigenschaften ->  Tab “Automatik” ->  Gruppe “System” -> “Aktion Zeiteinheit 60sek.”

Die Einstellung sorgt dafür, dass die Überprüfung zur Auslösung einer Aktion häufiger ausgeführt wird. Ansonsten würden die Story-Xmls nicht oft genug aufgerufen. Achtung! Da diese Option mehr Rechenleistung benötigt, kann dies die Programmausführung beeinträchtigen. Hier ist genau zu prüfen, ob es in der geplanten Umgebung möglich ist. Das hängt z.B. von der Größe der Anlage ab, der Anzahl der gleichzeitig fahrenden Züge, sonstigen weiteren Aktion & Xml-Scripten usw. Bei meinem →kleinen Spur 1-Bahnhof sind max. 2-3 Lokomotiven unterwegs, so dass es hier kein Problem darstellt.

Pfad für Xml-Scripte festlegen

Um nicht überall lange Pfade schreiben zu müssen, bietet es sich an, den Pfad zu den Xml-Scripten in den Rocrail-Einstellungen zu hinterlegen.

Teiler Modellzeit

In meiner Rocrail-Umgebung ist der Teiler für die Modellzeit auf 100 gesetzt. Dann dauert ein Modelltag ca. 15 Minuten. Dieser Wert bestimmt zusammen mit der zeitgesteuerten Aktion, wie häufig das Story-Xml aufgerufen wird.

  • Rocrail-Eigenschaften ->  Tab “Dienst” ->  Gruppe “Clock Service” ->  Teiler 100

Zeitgesteuerte Trigger-Aktion

Zusammen mit dem Teiler der Modellzeit bestimmt die Intervallzeit in der Trigger-Aktion, wie häufig das Story-Xml aufgerufen wird. Hier steht die Zeit auf 00:02:00, so dass die Aktion alle zwei Modellminuten ausgelöst wird. Zusammen mit dem Teiler 100 (siehe oben) ergibt sich also alle 2*60 / 100 = 1,2 Sekunden ein Trigger-Ereignis. Bei einem kleineren Teiler von 75 würde der Modelltag 20 Minuten dauern. Dann würde es sich anbieten, die Aktionszeit auf z.B. 00:02:30 zu setzen, da dann die Auslösung alle 2,5*60 / 75 = 2 Sekunden stattfindet. Es kommt aber nicht ganz genau darauf an, da auch Rocrail zeitlich nicht so exakt auslöst.

Die Trigger-Aktion ist sehr wichtig, da nur mit diesem Mechanismus der gesamte Anlagenzustand aktuell bleibt und Ereignisse vom Script abgefragt werden können. Bei der Trigger-Aktion müssen die Checkboxen

  • “Benutze”,
  • “Jede” und
  • “Aktivieren”

angehakt sein. Mit dem einkommentierten Abschnitt “TEST ONLY” im Script StoryTest.xml wird dann der Button StoryYes/OK im Takt des Triggers blinken, wenn der StoryButton “TestStory” aktiv ist (siehe →Video).

Das Trigger-Xml-Script (StoryTrigger.xml)

Die Umsetzung der Story-Inhalte im Xml erfolgt in zwei Schritten. Zunächst werden bestimmte Grundfunktionen über ein sogenanntes Trigger-Script erledigt. Dieses trägt den Namen StoryTrigger.xml. Im Wesentlichen geht es hier um die Unterscheidung verschiedener Stories (siehe auch Benutzerschnittstelle -> Buttons) und darum, fehlerhafte Mehrfachaufrufe zu vermeiden. Auch die Pausenfunktion (siehe Buttons) findet hier Platz. Alle eigentlichen Story-Funktionalitäten sind dann in der jeweiligen StoryXYZ.xml zusammengefasst. Dieses wird wiederum von StoryTrigger.xml aufgerufen.

Die Benutzerschnittstelle (oder: Was sieht man eigentlich von der Story?)

In den Beispielverläufen (→Verlauf 1, →Verlauf 2) ist schon die Schnittstelle in Rocrail zu erkennen. Sie besteht aus einer Anzahl von Menu-Buttons und zwei Textfeldern mit Antwort-Buttons. Damit lässt sich der grundsätzliche Ablauf kontrollieren, aber auch die interaktive Nutzung ist möglich.

Story-Buttons

Über die Story-Buttons lässt sind ganz grundsätzlich steuern, ob überhaupt eine Story abläuft und wenn ja, welche. Im Bild sind die Storybuttons links oben vertikal angeordnet. Wie der Name schon sagt, bedeutet der Button “Aus”, dass keine Story läuft (und z.B. Variablen zurückgesetzt werden). Der Button “StoryTest” leitet das StoryTrigger.xml dann auf eine entsprechende Story-Xml-Datei weiter. Als letztes gibt es noch einen Button “Pause”. Damit wird das StoryTrigger.xml daran gehindert, weitere Xml-Script aufzurufen => die aktuelle Story bleibt da stehen, wo sie gerade ist. Eine Alternative wäre, die Modellzeit hier anzuhalten bzw. fortzusetzen. Die Story-Buttons können über eine Gruppenkennung so verknüft werden, dass jeweils immer nur genau ein Button aktiv ist. Das ist auch im Video beschrieben.

Hinter dem StoryTest-Button muss noch das Script Story-Reset hinterlegt werden.

Textfelder

Zwei Textfelder sind dazu da, dem Benutzer Informationen zu geben bzw. Anfragen zu stellen:

  • Benutzer-Information
  • Benutzer-Abfrage

Bei der Benutzer-Information werden Textinformationen ausgegeben. In der →Story Nr 1 ist das z.B. der Dieselvorrat.

Bei einer Benutzer-Abfrage muss der Benutzer eine Entscheidung treffen. Die Frage wird im Textfeld angezeigt, und der Benutzer muss mit Ja/Ok oder Nein/Abbrechen reagieren. Diese Interaktivität wird in der Story Nr 1 noch nicht genutzt. In der TestStory gibt es am Anfang eine Abfrage, ob die Story wirklich gestartet werden soll oder nicht.

Antwort-Buttons

Wie schon beschrieben, gibt es zwei Buttons, mit denen der Benutzer Entscheidungs-Eingaben machen kann. Zur sauberen Identifizierung stehen neben den Buttons noch beschreibende Textfelder:

  • Button “StoryAntwortJaOk”. Daneben das Textfeld “Ja/OK”
  • Button “StoryAntwortNeinAbbr”. Daneben das Textfeld “Nein/Abbrechen”

Variablen

Derzeit kommt nur eine Variable zum Einsatz, sie ist aber auch essentiell für die Handhabung der Story:

  • StoryIndex

StoryIndex ist ein Zahlenwert und bestimmt, an welcher Stelle der hinterlegten Handlungsfolge sich die Story derzeit befindet. So wird mit fortschreitender Handlung der Wert von StoryIndex immer weiter erhöht und manchmal auf bestimmte Stände zurückgesetzt. Über StoryIndex “weiß” dann das eigentliche Story-Script immer, was zu einem bestimmten Zeitpunkt zu tun ist.

Dies ist am Beispiel →des Scripts “Köf tanken” zu erkennen:

Zum Beispiel wird bei StoryIndex = 2 die Textausgabe “Achtung, Köf muss betankt werden!” gemacht. Danach wird auf StoryIndex 3 erhöht. Bei StoryIndex = 5 wird die Dieselreserve ausgegeben. Zu dieser Stelle (StoryIndex = 5) wird von mehreren Stellen aus gesprungen, damit regelmäßig eine Aktualisierung der Dieselreserve angezeigt wird. Bei StoryIndex = 14 steht fest, dass  der Motor im Leerlauf läuft. Daher wird hier die Dieselreserve (eine lokale Variable ‘temp_StoryCounter1’) nur um einen kleinen Wert (1) reduziert.

Über ein Script “StoryReset” muss immer, wenn ein Story-Abbruch stattfindet oder eine Story beendet wurde, der Wert von StoryIndex zurückgesetzt werden. Ansonsten kann es passieren, dass beim Umschalten zwischen zwei Stories die neu angewählte Story nicht mit StoryIndex = 0 gestartet wird. Das würde zu völlig falschem Verhalten führen, da die Story “irgendwo” mittendrin anfangen würde. Das StoryReset-Script ist auch in den →Downloads enthalten und setzt diese Variable entsprechend zurück. Wie das Script eingebunden wird, ist im Video erläutert.

Wann welche Story?

Grundregeln

Zunächst mal sollten die Stories “sauber” aufgerufen werden. Sollte z.B. bei jedem StoryTrigger eine andere Story aufgerufen werden, kein sauberer Reset zwischen zwei Stories erfolgen oder die Zeitintervalle zu kurz sein, kann dies zu Beeinträchtigungen nicht nur der Stories, sondern auch der gesamten Automatik führen. Daher ist ein gut organisierter Aufbau der Xml-Scripte sehr wichtig. Folgende Grundregeln lassen sich aufstellen:

  • Eine Story darf keine andere unterbrechen
  • Daraus folgt, dass eine Story solange aktiv bleibt, bis sie beendet (zuende gespielt) oder absichtlich gestoppt wurde.

Downloads

Fazit

Für das Funktionieren der Stories müssen bestimmte Voraussetzungen erfüllt sein. Erst dann wird die Story im richtigen Zeitintervall getriggert und kann korrekt funktionieren. Viel Spaß bei euren Experimenten mit den Stories wünscht



Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.