OMSIWiki - Benutzerbeiträge [de]

Fahrtzielanzeiger an Bussen

2014-05-18T20:33:25Z

Busfanat: Die Seite wurde neu angelegt: „=Fahrtzielanzeiger des Vorbilds in OMSI= Prinzipiell lassen sich alle Fahrtziel-Anzeigesysteme mittels Scripts in OMSI darstellen. Die Schwierigkeiten liegen im …“

=Fahrtzielanzeiger des Vorbilds in OMSI=

Prinzipiell lassen sich alle Fahrtziel-Anzeigesysteme mittels Scripts in OMSI darstellen. Die Schwierigkeiten liegen im Aufwand der Umsetzung und der Performance.
Im folgenden Artikel geht es lediglich um die scriptseitige Darstellung, nicht um das Erstellen im 3D-Programm oder das Einbinden in der *.cfg-Datei.

==Steckschilder==
* Fahrtzieldarstellung:
Die wahrscheinlich einfachste Möglichkeit eines Zielanzeigers. Auf einer Tafel steht das Ziel geschrieben.
Der Dateiname der aktuellen Ziel-tga kann aus der *.hof-Datei ausgewertet werden.
* Bedienung/Umsetzungsvorschlag:
Das Entfernen des Schildes kann recht einfach realisiert werden. Ein Klick auf das Schild und über eine Visible-Variable wird das Schild ausgeblendet.
Komplexer ist das Einstecken des richtigen Schilds. Lässt sich theoretisch über das Alt-Menü lösen, allerdings ist diese Variante eher unschön.
In der Realität wurden bei Schichtbeginn genau jene Schilder, die man während des Diensts brauchen würde, im Bus verstaut und mitgeführt.
Als Alternative zur Umsetzung würde sich ein Blick in eine Fahrermappe, in der man die nächste Route bzw. das nächste Ziel auswählt, anbieten.
Ein Klick auf den Zielschildhalter könnte das Schild dann platzieren/über die Visible-Variable wieder einblenden.

==Rollbänder==
* Fahrtzieldarstellung:
Bei diesem Fahrtziel-Anzeigen-Typ befinden sich alle Zielschilder des aktuellen Hofs auf einem Rollband. Je nach Fahrtrichtung wird dieses Rollband in die entsprechende Position gedreht, sodass das aktuelle Fahrtziel
von außen sichtbar ist.
* Bedienung/Umsetzungsvorschlag:
In der Realität werden (bzw. wurden) Rollbänder entweder von Hand gekurbelt oder über Stellmotore eingestellt.
Bei einer Einstellung über Stellmotore erfolgt die Steuerung kann tastend, schrittweise oder zielbasiert erfolgen. Bei der tastenden und schrittweisen Steuerung besitzt das Steuergerät pro Motor zwei Taster, einen für jede Drehrichtung.
Der Motor dreht sich so lange in die gewählte Richtung, wie der Taster betätigt wird. Bei einer tastenden Steuerung bleibt das Rollband nach dem Auslassen in der aktuellen (Zwischen-)Position stehen, währdend es sich bei einer schrittweisen Steurung bis zur nächsten Rastposition weiterdreht.
Bei einer zielbasierten Rollbandsteuerung kann die Zieleingabe entweder über das IBIS oder ein separates Steuerpanel erfolgen. Sobald das Ziel eingegeben und bestätigt wurde, dreht sich das Rollband selbsttätig zur gewählten Position.
Es können wie in den SDs die Dateinamen der Rollband-tgas aus der *.hof-Datei ausgelesen werden.

==ANNAX==
* Fahrtzieldarstellung:
Die von M&R bereits in OMSI1 inkludierte ANNAX-Matrix bietet eine gerasterte Ziel-Anzeige für zwei Zeilen á 16 Zeichen sowie eine Linienanzeige für 3 Zeichen. Dabei wird jedes Zeichen nacheinander, erst die obere Zeile von links nach rechts, dann die untere Zeile von links nach rechts umgeschaltet.
* Bedienung/Umsetzungsvorschlag:
Da die ANNAX-Matrix starr gerastert ist, kann die Wechsel-Animation soweit vereinfacht werden, dass immer ein ganzes Zeichen aktualisiert wird.
Die Bedienung erfolgt über das IBIS oder ein separates Matrix-Steuergerät. Nach der Eingabe der neuen Informationen schildert die Anzeige diese selbsttätig.

==FlipDots==
* Fahrtzieldarstellung:
Die namengebenden FlipDots sind kleine Plättchen, die auf der einer Seite schwarz und auf der anderen Seite in einer dazu kontrastreichen Farbe (beispielsweise weiß oder neongrün) ausgeführt sind. Die Matrix besteht, um das Schriftbild darzustellen, aus entsprechend vielen dieser Plättchen. Um die Plättchen zu drehen, ist jedes einzelne mit einem kleinen Elektromotor ausgestattet. Um Verkabelungs-Aufwand zu sparen werden die Elemente über eine Matrixschaltung Spalten- oder Zeilenweise geschaltet.
* Bedienung/Umsetzungsvorschlag: Aufgrund der schrittweisen Aktualisierung der Fahrtzielanzeige und möglichen zufälligen Fehldarstellungen muss der Inhalt vom Script aufgrund der Informationen in der Hof-Datei dynamisch generiert werden. Grundsätzlich kann man bei FlipDot-Zielanzeigen zwei Typen unterscheiden:
** Aktualisierung von oben nach unten: Hier lassen sich verschiedene Methoden andenken. Da die Anzahl der Zeilen überschaubar ist, kann man hier mehr mehr Varianten andenken als bei der Aktualisierung von links nach rechts.
# Abwandlung des "BUSE-Matrix-Script", sodass nicht Punkt- sondern Zeilenweise aktualisiert wird.
# Abwandlung der "Busfanat-Vollmatrix", sodass nicht Spalten- sondern Zeilenweise aktualisiert wird.
# Das Matrix-Script aus dem O405N aus dem kommerziellen Hamburg-Addon, deren Funktionsweise nicht öffentlich bekannt ist.
** Aktualisierung von links nach rechts: Für OMSI 1 ist hier bislang nur die "Busfanat-Vollmatrix" bekannt. Ab OMSI 2 gibt es als Alternative die Krüger-Matrix, die von M&R im EN92 bzw. GN92 mitgeliefert wurde.
Die Bedienung erfolgt über das IBIS oder ein separates Matrix-Steuergerät. Nach der Eingabe der neuen Informationen schildert die Anzeige diese selbsttätig.

==LED/LCD-Display==
* Fahrtzieldarstellung:
Bei LED-Matrizen werden die namengebenden Leuchtdioden über eine Matrixschaltung gesteuert. Dabei werden die LEDs für ein scheinbares Dauerleuchten (meist zeilenweise) gemultiplext. Das hat neben einem wesentlich geringeren
Verkabelungsaufwand auch den Vorteil eines geringeren Stromverbrauchs, weil nicht alle "angeschalteten" Dioden gleichzeitig mit Strom versorgt werden müssen. Zudem erfolgt der Zielwechsel scheinbar augenblicklich.
LCD-Displays arbeiten nach einem anderen Funktionsprinzip, einer der größten offensichtlichen Unterschiede ist, dass nicht die Bildpunkte selbst leuchten, sondern von hinten beleuchtet werden müssen und zur Darstellung
des Matrixbilds die Bildpunkte einen Teil der Hintergrundbeleuchtung absorbieren, beziehungsweise nicht durchscheinen lassen.
Die Bedienung erfolgt über das IBIS oder ein separates Matrix-Steuergerät. Nach der Eingabe der neuen Informationen schildert die Anzeige diese selbsttätig.
* Bedienung/Umsetzungsvorschlag: Da alle Punkte zeitgleich aktualisiert werden, bieten sich mehrere Möglichkeiten an:
** Die "Busfanat-Vollmatrix" im LED-Modus (in der Const-Datei einstellbar)
** (ab OMSI2) Abwandlung des Krüger-Matrix-Scripts von M&R, sodass nicht spaltenweise sondern alles auf einmal aktualisiert wird.
** Abwandlung des "BUSE-Matrix-Script", sodass nicht Punktweise sondern alles auf einmal aktualisiert wird..
** Man nutzt die "Rollband-tga" als Wechseltextur, wie es von Thiago im Volvo 9900 umgesetzt wurde.
Bei den beiden letzten Varianten wird eine bessere Performance durch eine aufwändigere Erstellung der Hof-Informationen erkauft. Ob sich das auszahlt, muss jeder selbst entscheiden.

Die Bedienung erfolgt über das IBIS oder ein separates Matrix-Steuergerät. Nach der Eingabe der neuen Informationen schildert die Anzeige diese selbsttätig.

=Beschreibung bekannter Scripts=
Es folgt eine Ablaufbeschreibung der bekannten Scripts.
==ANNAX==
=== Zusammenfassung ===
Die ANNAX fragt vom IBIS/Matrix-Steuergerät/whatever drei Variablen ab: Liniennummer, Kursnummer (Liniensuffix) und Ziel-Index. In der M&R-Standard-Konfiguration heißen die Variablen: IBIS_LinieKurs, IBIS_Linie_suffix und

IBIS_TerminusIndex.
Die Liniennummer wird im Script in einen String umgewandelt, evtl. durch die Kursnummer noch manipuliert und kann dann angezeigt werden.
Beim Ziel ist es ähnlich, mit dem abgerufenen Zielindex werden aus der Hof-Datei die relevanten Strings geladen. Diese werden kurz für die Texttextur vorverarbeitet und können ebenfalls angezeigt werden.
Da bei der ANNAX jedes Zeichen in seinem eigenen Raster angezeigt wird und jedes Rasterkästchen (für sich betrachtet) ohne Übergangsanimation auf einmal aktualisiert wird, ist die Übergangsanimation relativ simpel.
Abhängig vom Fortschritt wird der aktuell angezeigte String vom neuen String stückweise überschrieben.
=== Funktionsablauf ===
* Auslösen des Wechselzyklus'
Der Anzeigenwechsel wird bei der Zielmatrix von einer Änderung des Zielindex', bei der Linienmatrix entsprechend durch eine Änderung der Liniennummer oder des Kurses ausgelöst.
* Auswertung Liniennummer und Kursnummer
Die Liniennummer ist in der Variable IBIS_LinieKurs gespeichert. Der Name ist verwirrend, denn die Variable enthält nur die Liniennummer. Die Kursnummer ist in der Variable IBIS_Linie_suffix gespeichert.
Zunächst wird die Liniennummer mittels $IntToStr in einen String umgewandelt. Ist die Kursnummer eine Linienbeeinflussende, wird der erhaltene Linienstring noch entsprechend modifiziert
* Beschaffung der Information aus der Hofdatei
Bei dieser Matrix werden bis zu drei Strings aus der Hofdatei ausgelesen: Frontanzeige oben, Frontanzeige unten und Seitenanzeige. Da mit dem Systemmacro (M.V.GetTerminusString) nur ein String zum Index in der Hofdatei und nicht zur

Zielnummer, die im IBIS eingegeben wird, gesucht werden kann, muss dieser Index zur vom IBIS übergebenen Variable IBIS_TerminusIndex mit dem Systemmacro (M.V.GetTerminusIndex) entsprechend gesucht werden. Nachdem mit dem nun bekannten

Index die benötigten Strings aus der Hofdatei geladen wurden, werden die herausgelesenen Strings nur noch ins entsprechende Format gebracht und können auf die Matrix geschrieben werden.
* Wechselanimation
Aufgrund des fixen Buchstabenrasters kann man hier mit einer Wechsel-Fortschrittsvariable einfach die ersten x Zeichen der neu ermittelten Zielanzeige nutzen, gleich viele Zeichen von der bereits geschilderten Anzeige "wegschneiden", die

beiden Zwischenstrings zusammenfügen und dann in den Texturstring, der dann mit der Texttextur angezeigt wird, speichern.
=== Vor- und Nachteile ===
+ performancefreundlich durch geringen Berechnungsaufwand
+ unterstützt M&R-Standard-Hofdatei
+ Linien- und Zielanzeige voneinander unabhängig
- fixe Zeichenanzahl pro Zeile (sonst wäre Zentrierung falsch)
==BUSE-Matrix-Script==
=== Zusammenfassung ===
Beim BUSE-Matrix-Script handelt es sich um die erste bekannte Möglichkeit, eine Vollmatrix in OMSI darzustellen. Technisch ist es ein modifiziertes ANNAX-Script, wie es aus den SD- und D-Bussen von OMSI1 bekannt ist.
Als Unterschied zu diesem werden in der Hof-Datei nicht die Zeileninhalte gespeichert, sondern die "vorgerenderten" Punkte der Matrix. Beim Wechsel des Ziels wird dieses Punkt für Punkt aktualisiert und das neue Zeil erscheint
von oben nach unten. Die Linienmatrix unterscheidet sich kaum vom M&R-ANNAX-Script.
Der erste Veröffentlicher dieses Scripts ist der User "Kosak", der diese Variante mit seinem Bus "Renault Karosa Citybus" veröffentlicht hat.
=== Funktionsablauf ===
* Auslösen des Wechselzyklus'
Der Anzeigenwechsel wird bei der Zielmatrix von einer Änderung des Zielindex', bei der Linienmatrix entsprechend durch eine Änderung der Liniennummer oder des Kurses ausgelöst.
* Auswertung Liniennummer und Kursnummer
Die Liniennummer ist in der Variable IBIS_LinieKurs gespeichert. Der Name ist verwirrend, denn die Variable enthält nur die Liniennummer. Die Kursnummer ist in der Variable IBIS_Linie_suffix gespeichert.
Zunächst wird die Liniennummer mittels $IntToStr in einen String umgewandelt. Ist die Kursnummer eine Linienbeeinflussende, wird der erhaltene Linienstring noch entsprechend modifiziert
* Beschaffung der Information aus der Hofdatei
Bei dieser Matrix wird nur ein String, die vorgerenderte Frontanzeige, aus der Hof-Datei ausgelesen. Da mit dem Systemmacro (M.V.GetTerminusString) nur ein String zum Index in der Hofdatei und nicht zur Zielnummer, die im IBIS eingegeben

wird, gesucht werden kann, muss dieser Index zur vom IBIS übergebenen Variable IBIS_TerminusIndex mit dem Systemmacro (M.V.GetTerminusIndex) entsprechend gesucht werden. Nachdem mit dem nun bekannten Index der benötigte String aus der

Hofdatei geladen wurde, kann der ausgelesene String auf die Matrix geschrieben werden.
* Wechselanimation
Da der anzuzeigende String ein vorgerendertes Punktemuster ist, kann man hier mit einer Wechsel-Fortschrittsvariable einfach die ersten x Zeichen der neu ermittelten Zielanzeige nutzen, gleich viele Zeichen von der bereits geschilderten

Anzeige "wegschneiden", die beiden Zwischenstrings zusammenfügen und dann in den Texturstring, der dann mit der Texttextur angezeigt wird, speichern.
=== Vor- und Nachteile ===
+ erstes Script dieser Art
+ performancefreundlich durch geringen Berechnungsaufwand
- spezielle Hof-Datei erforderlich
- Liniennummer wird mit den Zieltext-Punkten in der Hofdatei gespeichert -> AI-Fahrzeuge schildern möglicherweise falsche Liniennummer, wenn sie das Ziel schildern
- Jede Anzeige mit diesem Script hat die gleiche Auflösung (ließe sich zwar ändern, aber dann wäre das Hof-Dateien-Chaos perfekt)
==Busfanat-Vollmatrix==
=== Zusammenfassung ===
Bei der "Busfanat-Vollmatrix" handelt es sich um die erste bekannte Möglichkeit, eine Vollmatrix in OMSI darzustellen, die mit den M&R-Standard-Hofdateien arbeiten kann.
Die erste Version dieser Matrix wurde mit dem Bus "Mercedes-Benz O405N2" von TramDüsseldorf veröffentlicht, in der am 02.06.2013 veröffentlichten Version unterstützt das Script drei Anzeigetypen:
Liniennummer, Zielschild ohne Liniennummer und Zielschild mit Liniennummer.
=== Funktionsablauf ===
* Auslösen des Wechselzyklus'
Der Anzeigenwechsel wird durch eine Änderung des Zielindex, der zu schildernden Linie oder der Kursnummer ausgelöst. Vor dem Wechsel wartet das Script dann noch, bis der Wechselziel-Timer abgelaufen und die letzte Anzeige vollständig

geschildert ist.
* Auswertung Liniennummer und Kursnummer
Die Liniennummer ist in der Variable IBIS_LinieKurs gespeichert. Der Name ist verwirrend, denn die Variable enthält nur die Liniennummer. Die Kursnummer ist in der Variable IBIS_Linie_suffix gespeichert.
Abhängig von der Kursnummer wird die Liniennummer direkt mittels $IntToStr in einen String umgewandelt oder zusätzlich noch mit Buchstaben/Sonderzeichen ergänzt oder auch durch diese ersetzt.
* Beschaffung der Informationen aus der Hofdatei
Bei dieser Matrix werden zwei Strings aus der Hofdatei ausgelesen: Frontanzeige oben und Frontanzeige unten. Da mit dem Systemmacro (M.V.GetTerminusString) nur ein String zum Index in der Hofdatei und nicht zur Zielnummer, die im IBIS

eingegeben wird, gesucht werden kann, muss dieser Index zur vom IBIS übergebenen Variable IBIS_TerminusIndex mit dem Systemmacro (M.V.GetTerminusIndex) entsprechend gesucht werden. Nachdem mit dem nun bekannten Index die benötigten

Strings aus der Hofdatei geladen wurden, werden die herausgelesenen Strings zunächst auf Steuerzeichen abgeprüft. Nachdem die Steuerzeichen abgearbeitet wurden, wird aus den verbleibenden Strings mittels des Fontfile-Scripts in ein

Punktemuster "gerendert", das dann auf den Matrixflächen angezeigt werden kann. Dieses Punktemuster wird, um die FlipDot-Animation zu ermöglichen, in 19 Strings, die jeweils eine Punkte-Zeile der Matrix enthalten, gespeichert.
* Wechselanimation
Sowohl von der derzeit geschilderten, als auch von der zu schildernden Anzeige sind die gerenderten Punktemuster in jeweils 19 Zeilen-Strings vorhanden. Anhand einer Wechsel-Fortschritt-Variable werden die entsprechenden ersten x Zeichen

jeden zu schildernden Zeilenstrings mit den bereits geschilderten Zeilenstrings, die um die gleiche Anzahl an Zeichen am Anfang des Strings gekürzt wurden, zusammengefügt. Anschließend werden die fertigen Zeilenstrings, die bereits die

Wechsel-Animation enthalten, durch "@"-Zeichen verbunden, die auf der Texttextur zu Zeilenumbrüchen werden, und in die Strings, die zur Erstellung der Texttexturen dienen, gespeichert.
=== Vor- und Nachteile ===
+ unterstützt M&R-Standard-Hofdatei (in OMSI1 lässt sich eine für die Busfanat-Vollmatrix formatierte Hofdatei auch vollständig ANNAX-kompatibel gestalten)
+ einzige bekannte Möglichkeit in OMSI1, eine FlipDot-Matrix, die von links nach rechts aktualisiert, darzustellen
+ durch Befehlszeichen in Hofdatei äußerst flexibel einsetzbar
+ durch zahlreiche Optionen in Const-File an verschiedenste Anforderungen anpassbar, unter anderem variable Breiten der Anzeigen
+ Sonderanzeigen möglich
- durch erheblichen Berechnungsaufwand performanceunfreundlich
- nicht für OMSI2 optimiert
- Schriftart muss textbasiert geändert werden
- Zeichenanzahl Zieltext auf 25 Zeichen pro Zeile begrenzt (bedingt durch das Fehlen des $CutSpaces-Befehls in OMSI1)
- benötigt je nach Ausführung bis zu 5 Texttexturen
==Krüger-Vollmatrix==
=== Zusammenfassung ===
Das ab OMSI2 verfügbare Krüger-Matrix-Script von M&R.
=== Funktionsablauf ===
* Auslösen des Wechselzyklus'
Der Anzeigenwechsel wird von einer Änderung des Zielindex', der Liniennummer oder des Kurses ausgelöst.
* Auswertung Liniennummer und Kursnummer
Die Liniennummer ist in der Variable IBIS_LinieKurs gespeichert. Der Name ist verwirrend, denn die Variable enthält nur die Liniennummer. Die Kursnummer ist in der Variable IBIS_Linie_suffix gespeichert.
Zunächst wird die Liniennummer mittels $IntToStr in einen String umgewandelt. Ist die Kursnummer eine Linienbeeinflussende, wird der erhaltene Linienstring noch entsprechend modifiziert
* Beschaffung der Information aus der Hofdatei
Bei dieser Matrix werden zwei Strings aus der Hofdatei ausgelesen: Frontanzeige oben und Frontanzeige unten. Da mit dem Systemmacro (M.V.GetTerminusString) nur ein String zum Index in der Hofdatei und nicht zur Zielnummer, die im IBIS

eingegeben wird, gesucht werden kann, muss dieser Index zur vom IBIS übergebenen Variable IBIS_TerminusIndex mit dem Systemmacro (M.V.GetTerminusIndex) entsprechend gesucht werden. Nachdem mit dem nun bekannten Index die benötigten

Strings aus der Hofdatei geladen wurden, kann die Matrix-Textur bearbeitet werden. Zunächst wird aufgrund der Breite der anzuzeigenden Strings (Also die Breite des Textes auf der Textur, nicht die Anzahl der Zeichen) die passendste

Schriftart ausgewählt. Danach werden die Texte auf eine temporäre Textur geschrieben.
* Wechselanimation
Die temporäre Zwischentextur wird pixelweise ausgelesen und von links nach rechts auf die anzuzeigende Scripttextur aufgemalt.
=== Vor- und Nachteile ===
+ zusammen mit OMSI2 entwickelt
+ durch neue OMSI2-Script-Funktionen relativ performancefreundlich
+ unterstützt M&R-Standard-Hofdatei
+ Sonderanzeigen möglich
- nicht mit OMSI1 kompatibel
- Jede Anzeige mit diesem Script hat die gleiche Auflösung (ließe sich zwar ändern, aber dann wären die Sonderanzeigen-Texturen nicht einheitlich)
==Mobitec-Matrix-Script==
=== Zusammenfassung ===
Diese Variante wurde als erstes im "Volvo 9900" von Toastmeister als "Mobitec-Matrix-Script" veröffentlicht und von Thiago entwickelt.
=== Funktionsweise ===
Im Prinzip ist dieses Script ein Rollbandscript ohne Rollanimation. Am Steuergerät wird direkt der Ziel-Index in der Hofdatei, nicht wie beim IBIS eine Zielnummer, ausgewählt und das entsprechende Bild über einen Texturtausch auf die

Anzeige gebracht.
=== Vor- und Nachteile ===
+ performancefreundlich, da nur fertige Bilder auf eine Fläche geladen werden
- kleine Änderung der Hof-Dateien erforderlich, wenn das Steuergerät aus dem Volvo 9900 verwendet wird.
==Rollbänder==
Bei OMSI muss man bei den Rollbändern zunächst zwischen Rollbändern mit einer fixen und Rollbändern mit einer script-gesteuerten Abfolge der eingerollten Bilder unterscheiden.
Ein Beispiel für eine fixe Abfolge sind die Linienrollbänder der M&R-Standardbusse. Scriptseitig wird hier nur der Index des anzuzeigenden Bildteils angegeben.
Ein Beispiel für eine script-gesteuerten Abfolge sind die Zielrollbänder der M&R-Standardbusse. Der Dateipfad der anzuzeigenden Bilder wird aus der Hof-Datei ermittelt.
Um den Roll-Effekt zu erziehlen, müssen zwei aufeinanderfolgende Zielbilder gleichzeitig auf zwei verschiedene Faces geladen werden, die sich aber in der 3D-Datei an der exakt gleichen Stelle befinden.
Im Anschluss entsteht der Roll-Effekt durch eine Verschiebung der Textur über eine Animationsvariable.
===Darstellung der Liniennummer===
==== Zusammenfassung ====
Scriptseitig läuft hier nur eine Variable auf und ab, die den Index der anzuzeigenden Textur angibt.
==== Vor- und Nachteile ====
+ nur eine 3D-Fläche pro Band benötigt
- Reihenfolge der angezeigten Bilder in cfg vordefiniert
===Darstellung des Fahrtziels===
==== Zusammenfassung ====
Für die beiden Texturverschiebungen läuft hier jeweils eine Variable. Zusätzlich zur Texturverschiebung erfolgt noch ein Texturtausch, damit nicht immer das selbe Ziel durch die Fläche scrollt.
==== Vor- und Nachteile ====
+ Reihenfolge der angezeigten Bilder durch Script steuerbar
- zwei 3D-Flächen pro Band benötigt

Scriptsystem

2013-07-05T20:21:47Z

Busfanat: /* String-Operationen */ Hinweis, dass $SetLength(L/R) einen kleinen Bug beim Float-Stack haben, hinzugefügt

''Hinweis: Dieser Artikel wurde noch nicht ins Englische übersetzt!''

Das Scriptsystem in OMSI ermöglicht es, dass Szenerieobjekte und vor allem Fahrzeuge mit individuellen Systemen ausgestattet werden können, die über Variablen und Funktionsaufrufe mit dem Hauptprogramm und der Grafik- und Soundengine kommunizieren.

Der hier beschriebene Stand des Scriptsystems entspricht OMSI Version 1.01.

== Dateien des Scriptsystems ==

Das Scriptsystem umfasst folgende Dateien:

* Scriptdateien mit ausführbarem Code (*.osc)
* Varlist- und Stringvarlist-Dateien im OMSI\program-Verzeichnis zur Definition von Systemvariablen
* Varlist- und Stringvarlist-Dateien zur Definition von Uservariablen
* Constfile-Dateien zur Definition von Userkonstanten und Funktionstabellen

Abgesehen von den Dateien zur Definition von Systemvariablen müssen alle benötigten Dateien für jedes Fahrzeug/Szenerieobjekt (im folgenden kurz: Objekt) in dessen [[Konfigurationsdatei]] angemeldet werden.

Hierfür gibt es die Befehle ''[script]'', ''[varnamelist]'', ''[stringvarnamelist]'' und ''[constfile]''. Der erste Eintrag jedes Befehls ist die Anzahl der Dateien, darauf folgen die entsprechenden Dateinamen (inkl. Pfad relativ zur Konfigurationsdatei. Die Namen der Dateien sind nicht relevant, solange sie korrekt in die Listen eingetragen werden.

Auf die Funktion der jeweiligen Dateien wird im Laufe der Beschreibung der Scriptsprache eingegangen.

== Grundlagen der Scriptsprache ==

Das OMSI-Scriptsystem arbeitet mit der [http://de.wikipedia.org/wiki/Umgekehrte_Polnische_Notation umgekehrten Polnischen Notation]. Hierbei steht der Operator hinter den beiden Operanden; vereinfacht gesagt bedeutet es, dass die Operation " 1 + 2 " stattdessen folgendermaßen notiert wird: " 1 2 + ". Ein komplizierteres Beispiel: " (1 + 2) * (4 + 5) " entspricht " 1 2 + 4 5 + * ".

Ganz wichtig ist die Tatsache, dass die OMSI-Textdateien und insbesondere die Scriptsprache [http://de.wikipedia.org/wiki/Case_sensitivity Case-Sensitive] ist! D.h. es ist immer auf die Groß- und Kleinschreibung zu achten!

=== Stack und Register ===

Bei der Verarbeitung der Scripts verfügt OMSI über einen String-Stack und einen [http://de.wikipedia.org/wiki/Stapelspeicher Stack] für [http://de.wikipedia.org/wiki/Gleitkommazahl Gleitkommazahlen]. Im folgenden ist mit "Stack" immer der Stack für Gleitkommazahlen gemeint, andernfalls wird von "String-Stack" gesprochen.

Beide Stacks enthält 8 Speicherplätze, welche von 0 bis 7 durchnumeriert sind. Jede Script-Operation kann nun einen oder mehrere neue Werte in einen der Stacks einfügen (push), wobei der neue Wert auf die Position 0 gesetzt wird und alle folgenden Werte "einen Platz aufrücken", oder sie kann einen oder mehrere Werte aus dem Stack herausziehen (pop/pull) oder lediglich auslesen (peek).

Fürs temporäre Ablegen von Zahlen gibt es zusätzlich acht indizierte Speicherplätze, welche direkt geschrieben oder gelesen werden können, die sich im sogenannten Register befinden - hier gibt es jedoch nur einen Register für die Gleitkommazahlen.

=== Beispiel-Operationen ===

Beispiel: Die Operation 1 + 4. Der Code hierfür lautet:

<pre>
1 4 +
</pre>

In der folgenden Tabelle wird demonstriert, wie sich hierbei der Stack verhält:

<pre>
Operation: Stack: 0 1 2 3 4 ...
-----------------------------------------------------------------------------
vorher: 0 0 0 0 0
"1" 1 0 0 0 0
"4" 4 1 0 0 0
"+" 5 0 0 0 0
</pre>

Im Ausgangszustand ist der Stack nur mit Nullen (oder unbekannten/zufälligen Werten) gefüllt. Der Befehl "1" schiebt die Eins in den obersten Stackplatz und schiebt alle weiteren Werte (Nullen) nach hinten. Der Befehl "4" schiebt die Vier auf den 0. Platz und alle folgenden Werte, also insbesondere die Eins auf den jeweils nächsten Platz. Im nächsten Schritt "+" werden die obersten beiden Werte aus dem Stack herausgezogen - also 4 und 1 - und summiert. Das Ergebnis (5) wird wiederum in den Stack geschoben. Die beiden ursprünglichen Zahlen sind im Stack nicht mehr vorhanden.

Ein zweites Beispiel:

(1 + 2) * (4 + 5) muss wie bereits erwähnt folgendermaßen notiert werden:

<pre>
1 2 + 4 5 + *
</pre>

Der Stack verhält sich somit folgendermaßen:

<pre>
Operation: Stack: 0 1 2 3 4 ...
-----------------------------------------------------------------------------
vorher: 0 0 0 0 0
"1" 1 0 0 0 0
"2" 2 1 0 0 0
"+" 3 0 0 0 0
"4" 4 3 0 0 0
"5" 5 4 3 0 0
"+" 9 3 0 0 0
"*" 27 0 0 0 0
</pre>

Am Ende befindet sich also das korrekte Ergebnis auf Stackplatz 0!

=== Gleitkommazahlen und Strings ===

Das OMSI-Skriptsystem arbeitet ausschließlich mit den Datentypen Gleitkommazahl (einfache Präzision mit Vorzeichen) und String. Beide Datentypen haben getrennte Stacks. Deshalb laufen die Verarbeitung von Gleitkommazahlen und Strings im Allgemeinen unabhängig nebeneinander. Jedoch kann es natürlich vorkommen, dass bestimmte Funktionen z.B. Zahlen in Strings umwandeln und somit gleichzeitig auf beide Teilbereiche zugreifen.

Auf boolische Variablen wurde verzichtet. Für boolische Werte werden im Allgemeinen die Zahlenwerte 0 und 1 verwendet.

== Script-Schlüsselwörter ==

=== Kommentare ===

Kommentierungen sind nur möglich, indem in der auszukommentierenden Zeile ganz vorne ein Apostroph ['] gesetzt wird:

<pre>
'Ich bin eine Kommentarzeile
'Ich bin KEINE Kommentarzeile!
</pre>

=== Einstiegs- und Ausstiegspunkte, Makros und Trigger ===

Alle Befehle müssen zwischen einem Einstiegs- und einem Ausstiegspunkt liegen.

Der Einstiegspunkt wird durch eins der folgenden Schlüsselwörter gekennzeichnet:

* {frame} Im Laufe jedes Frames ruft OMSI über diesen Einstiegspunkt die frameweise Scriptverarbeitung auf, sofern er vorhanden ist.
* {init} Bei der Initialisierung ruft OMSI über diesen Einstiegspunkt die Script-Initialisierung auf.
* {frame_ai} Hierbei handelt es sich um eine Variante des {frame}-Einstiegspunktes, welcher bei Fahrzeugen dann aufgerufen wird, wenn diese nicht im Fokus des Benutzers stehen, z.B. wenn sie als KI-Fahrzeug unterwegs sind. Ist dieser Einstiegspunkt jedoch nicht vorhanden sondern nur {frame}, dann wird dieser alternativ aufgerufen. Bei Szenerieobjekten kommt dieser Eintrittspunkt nicht zur Anwendung.
* {macro:''name''} Dieser Einstiegspunkt ruft ein Subsektion (Makro) auf, welche '''stets nach dem Aufruf''' definiert werden muss.
* {trigger:''name''} Dieser Einstiegspunkt wird vom Hauptprogramm aufgerufen, wenn der Benutzer die Tastenkombination oder das Maus-Event mit der Bezeichnung ''name'' aufruft - es gibt auch bestimmte Trigger, die direkt vom Hauptprogramm aufgerufen werden, z.B. wenn OMSI bei KI-Bussen die Anzeige wechselt u.Ä.

{end} ist der universelle Ausstiegspunkt. Er muss stets den Block abschließen, der mit einem der obigen Befehle eröffnet wird.

==== Makroaufruf ====

Der Aufruf eines Makros erfolgt über (M.L.''name''). Der Aufruf des Makros muss ''immer'' vor dessen Definition erfolgen. Andernfalls meldet OMSI, dass das Makro nicht gefunden wurde.

==== Aufteilung des Scripts in mehrere Dateien ====

Bei einfachen Scripts (z.B. bei reinen KI-Fahrzeugen oder Szenerieobjekten) reicht es im Allgemeinen eine *.sco-Datei zu erstellen, welche über einen {frame}...{end}- und ggf. einen {init}...{end}-Block verfügt.

Handelt es sich jedoch um ein komplettes Fahrzeugscript, dann empfiehlt es sich für die verschiedenen Subsysteme getrennte Dateien anzulegen. Hierbei sollte folgendermaßen vorgegangen werden:

* Es gibt ein Hauptscript und die nötigen Subsystemdateien. Die Hauptdatei enthält dabei die {frame}- und {init}-Blöcke, die jedoch nur Makros aufrufen, welche in den Subsystemdateien definiert sind.
* Für jedes Subsystem gibt es eine *.sco-Datei und je nach Bedarf eine eigene Varlist und Constfile mit den zum System gehörenden Variablen. Außerdem werden auch hier die Trigger für die Tastenbefehle einsortiert.
* Die Makros sollten sinnvollerweise folgendermaßen benannt werden: {macro:''subsystem''_frame} und {macro:''subsystem''_init}.
* Damit die Makros vom Hauptscript aufgerufen werden, muss dieses in der Liste der Scripts in der Objekt-Konfigurationsdatei als erstes aufgerufen werden. Die Reihenfolge der Scripts untereinander muss ebenfalls so gewählt werden, dass alle dateiübergreifenden Makroaufrufe stets vor der jeweiligen Makrodefinition stehen.

Die Einschränkung, dass Makros immer hinter dem Aufruf definiert werden müssen, kann zwar bisweilen hinderlich sein, ist aber ein sehr wirksamer Schutz gegen Zirkelschlüsse und Endlosschleifen.

==== Trigger ====

Wie schon geschrieben wurde, kann ein {trigger:''name''}...{end}-Abschnitt durch verschiedene Möglichkeiten aus dem Hauptprogramm heraus aufgerufen werden. Hierzu zählen:

* Auslösung per Tastatur. Wurde die Tastenkombination mit dem Namen ''tastkomb'' bezeichnet, wird {trigger:tastkomb} aufgerufen, wenn die Taste gedrückt wird und {trigger:tastkomb_off}, wenn die Taste losgelassen wird.
* Auslösung per Maus. Wurde ein Mesh angeklickt mit der [mouseevent]-Bezeichnung ''mouse_ev'', so wird {trigger:mouse_ev} aufgerufen, wenn die Maustaste gedrückt wird, {trigger:mouse_ev_drag}, während die Maustaste gehalten wird und {trigger:mouse_ev_off}, wenn die Maustaste losgelassen wird.
* Außerdem gibt es noch eine Reihe von [[System-Trigger|System-Triggern]].

=== Operationen ===

==== Stack-Operationen ====

{| class="wikitable" style="font-size:95%;"
|- class="hintergrundfarbe5"
| align="left" |%stackdump%
| align="left" |Gibt eine Dialogbox mit dem Gleitkomma-Stackinhalt aus. Sollte deshalb natürlich nur zu Debug-Zwecken eingesetzt werden.
|-
| align="left" |s0, s1, ..., s7
| align="left" |Speichern des aktuellen Stackwertes im durch die Ziffer angegebenen Register. Der Wert verbleibt hierbei im Stack
|-
| align="left" |l0, l1, ..., l7
| align="left" |Laden des entsprechenden Registerwertes und Verschiebung in den Stack. Registerwert bleibt erhalten.
|-
| align="left" |d
| align="left" |Dubliziert den obersten Stackwert; alle weiteren Stackwerte rücken nach hinten.
|-
| align="left" |$msg
| align="left" |Schreibt den obersten String-Stack-Wert in die Debug-Zeile von OMSI - egal, ob es sich um ein User-, KI-Fahrzeug oder Szenerieobjekt handelt.
|-
| align="left" |$d
| align="left" |Dubliziert den Stringstack-Wert analog zu "d".
|}

==== Logische Operationen ====

Die logischen Operationen arbeiten nach dem Prinzip 0 = FALSE, alles andere ist TRUE.

{| class="wikitable" style="font-size:95%;"
|- class="hintergrundfarbe5"
| align="left" |&&
| align="left" |UND, d.h. wenn einer der beiden obersten Stackwerte gleich 0 ist, ist das Ergbnis 0, sonst 1.
|-
| align="left" |<nowiki>||</nowiki>
| align="left" |ODER
|-
| align="left" |<nowiki>!</nowiki>
| align="left" |Verneinung
|}

==== Vergleichsoperationen ====

Die Vergleichsoperationen vergleichen die Werte in den beiden jeweils obersten Stackplätzen und fügen dann je nach Ergebnis eine "1" oder "0" im obersten Stackplatz ein. Die Größer-/Kleinerzeichen stehen dabei entsprechend für der Reihenfolge, in der die Werte zuvor angegeben wurden. Das bedeutet:

4 2 > ist wahr, weil die intern durchgeführte Operation in diesem Fall "4 > 2" ist.

{| class="wikitable" style="font-size:95%;"
|- class="hintergrundfarbe5"
| align="left" |=
| align="left" |"1", falls die obersten Stackwerte identisch sind, sonst "0".
|-
| align="left" |<
| align="left" |"1", falls Stackwert 1 kleiner ist als Stackwert 0, sonst "0".
|-
| align="left" |>
| align="left" |... größer ist ...
|-
| align="left" |<=
| align="left" |... kleiner als oder gleich ist ...
|-
| align="left" |>=
| align="left" |... größer als oder gleich ist ...
|-
| align="left" |$=
| align="left" |Wie "=" nur für die obersten beiden Stringstack-Plätze.
|-
| align="left" |$<
| align="left" |Kleiner als (String). Die Ungleich-Operationen bei Strings prüfen auf alphabetische Reihenfolge. "A" ist also kleiner als "B".
|-
| align="left" |$>
| align="left" |Größer als (String).
|-
| align="left" |$<=
| align="left" |Kleiner oder gleich (String).
|-
| align="left" |$>=
| align="left" |Größer oder gleich (String).
|}

==== Mathematische Operationen ====

{| class="wikitable" style="font-size:95%;"
|- class="hintergrundfarbe5"
| align="left" |+
| align="left" |Plus
|-
| align="left" |-
| align="left" |Minus (Stackplatz 1 - Stackplatz 0, also vom Prinzip her wie bei den Größer/Kleiner-Operationen)
|-
| align="left" |*
| align="left" |Mal
|-
| align="left" |/
| align="left" |geteilt (Stackplatz 1 / Stackplatz 0)
|-
| align="left" |%
| align="left" |Rest der Division (folgendermaßen erweitert für Gleitkommazahlen: Stack0 - trunc(Stack1 / Stack0) * Stack1 )
|-
| align="left" |/-/
| align="left" |Vorzeichenwechsel
|-
| align="left" |sin
| align="left" |Sinus
|-
| align="left" |min
| align="left" |Wahl des kleineren der beiden obersten Stackwerte
|-
| align="left" |max
| align="left" |Wahl des größeren der beiden obersten Stackwerte
|-
| align="left" |exp
| align="left" |Exponentialfunktion zur Basis e (e^Stack0)
|-
| align="left" |sqrt
| align="left" |Quadratwurzel
|-
| align="left" |sqr
| align="left" |Quadrat
|-
| align="left" |sgn
| align="left" |Rückgabe des Vorzeichens; je nachdem entweder -1, 0 oder 1
|-
| align="left" |pi
| align="left" |Kreiszahl pi
|-
| align="left" |random
| align="left" |ganzzahlige Zufallszahl 0 <= x < Stack0
|-
| align="left" |abs
| align="left" |Rückgabe des Absolutwertes
|-
| align="left" |trunc
| align="left" |Abrunden auf nächste ganze Zahl
|}

==== String-Operationen ====

{| class="wikitable" style="font-size:95%;"
|- class="hintergrundfarbe5"
| align="left" |"''bla''"
| align="left" |Einfügen des Strings ''bla'' auf dem obersten String-Stack-Platz
|-
| align="left" |$+
| align="left" |Zusammenfügen zweier Strings. "Omnibus" "simulator" $+ ergibt "Omnibussimulator"
|-
| align="left" |$*
| align="left" |Der oberste Stack-String wird sooft wiederholt, bis die resultierende Zeichenlänger gerade noch kleiner oder gleich des obersten Stackwertes ist. Beispiel: "nu" 6 $* ergibt "nununu"
|-
| align="left" |$length
| align="left" |Gibt die Anzahl der Zeichen des obersten Stack-String zurück in den Stack.
|-
| align="left" |$cutBegin
| align="left" |Schneidet ''stack0'' Zeichen vorne vom obersten Stack-String ab.
|-
| align="left" |$cutEnd
| align="left" |Schneidet ''stack0'' Zeichen hinten vom obersten Stack-String ab.
|-
| align="left" |$SetLengthR
| align="left" |Passt die Länge des obersten Stack-Strings auf ''stack0'' rechtsbündig an, indem am Anfang Zeichen entfernt oder Leerzeichen ergänzt werden.
VORSICHT Bug! Der Befehl entfernt den Float-Operator nicht vom Stack. Der Wert, auf dessen Länge der String gekürzt wurde, verbleibt also auf Stack0.
|-
| align="left" |$SetLengthL
| align="left" |Passt die Länge des obersten Stack-Strings auf ''stack0'' linksbündig an, indem am Ende Zeichen entfernt oder Leerzeichen ergänzt werden.
VORSICHT Bug! Der Befehl entfernt den Float-Operator nicht vom Stack. Der Wert, auf dessen Länge der String gekürzt wurde, verbleibt also auf Stack0.
|-
| align="left" |$IntToStr
| align="left" |Rundet ''stack0'' ab und wandelt die resultierende Ganzzahl um in einen String.
|-
| align="left" |$IntToStrEnh
| align="left" |Die erweiterte Version von IntToStr. Hierbei wird der oberste Stack-String verwendet, um das Format der String-Umwandlung zu bestimmen: Das erste Zeichen im String wird zum Auffüllen der fehlenden Zeichen verwendet, die folgenden Zeichen müssen eine Zahl ergeben, die die Stellen angibt. Beispiel: 35 " 5" $IntToStrEnh führt zu " 35" und 123456789 "011" $IntToStrEnh führt zu "00123456789". Falls ein Fehler vorliegt, wird "ERROR" ausgegeben.
|-
| align="left" |$StrToFloat
| align="left" |Wandelt den obersten Stack-String in eine Gleitkommazahl um, falls möglich. Andernfalls wird eine -1 geschrieben.
|-
|}

=== Variablenzugriff ===

Es wird unterschieden in Systemvariablen und in lokale Variablen. Die Systemvariablen gelten OMSI-weit, die lokalen Variablen werden zum Fahrzeug/Objekt zugehörig gespeichert.

Bei den lokalen Variablen gibt es stets einen Grundstamm an Variablen, welcher von OMSI vordefiniert werden. Darüber hinaus können beliebig viele Variablen mit Hilfe der Varlist-Dateien ergänzt werden.

{| class="wikitable" style="font-size:95%;"
|- class="hintergrundfarbe5"
| align="left" |(L.S.''varname'')
| align="left" |Lädt die Systemvariable ''varname'' in den obersten Stackplatz
|-
| align="left" |(L.L.''varname'')
| align="left" |Lädt die lokale Variable ''varname'' in den obersten Stackplatz
|-
| align="left" |(L.$.''varname'')
| align="left" |Lädt die lokale String-Variable ''varname'' in den obersten String-Stackplatz
|-
| align="left" |(S.L.''varname'')
| align="left" |Speichert den obersten Stackplatz in die lokale Variable ''varname''
|-
| align="left" |(S.$.''varname'')
| align="left" |Speichert den obersten String-Stackplatz in die lokale String-Variable ''varname''
|}

Eine detaillierte Beschreibung der einzelnen Systemvariablen und der vordefinierten lokalen Variablen finden Sie hier: [[System- und vordefinierte lokalen Variablen]]

=== Konstanten und Funktionen ===

Lokale Konstanten und [http://de.wikipedia.org/w/index.php?title=Datei:Linear_interpolation.svg&filetimestamp=20080226155013 stückweise definierte lineare Funktionen] können in den Konstantendateien (''constfiles'', ''~_constfile.txt'') definiert werden. Der Aufbau jeder Konstantendatei entspricht der der [[Konfigurationsdateien|Konfigurationsdatei]]. Es gibt lediglich drei Schlüsselwörter. Zu beachten ist: Bisher können keine Strings, sondern nur Fließkommazahlen als Konstanten definiert werden.

[const] definiert eine neue Konstante und gibt ihren Wert an:

<pre>
[const]
name
wert
</pre>

Beispiel:

<pre>
[const]
leistung
200
</pre>

[newcurve] leitet die Definition einer neuen (stückweise linearen) Funktion ein:

<pre>
[newcurve]
name
</pre>

[pnt] fügt der zuvor mit [newcurve] definierten Funktion ein neues x-y-Paar hinzu. Jede Funktion sollte normalerweise über mindestens zwei Paare verfügen. Die Reihenfolge der Paare ''muss'' in x-Richtung aufsteigend sein!

<pre>
[pnt]
x
y
</pre>

Beispiel:

<pre>
[newcurve]
Drehzahl_Drehmoment_Kennlinie

[pnt]
50
0

[pnt]
300
400

[pnt]
1000
600
</pre>

Konstanten werden über den Befehl (C.L.''konstantenname'') in den Stack geladen.

Funktionen werden über den Befehl (F.L.''funktionsname'') aufgerufen. Dabei wird stets der zuvor auf oberster Stackposition befindliche Wert als x-Parameter übergaben und der resultierende y-Wert der Funktion stattdessen auf dem obersten Stackplatz gespeichert. Bewegt sich der x-Wert außerhalb der Grenzen der durch die [pnt]-Einträge definierten Eckpunkte, wird stets der y-Wert des nächstliegenden Eckpunktes verwendet. Die Funktion wird also vor dem ersten und hinter dem letzten Eckpunkt ins Unendliche waagerecht verlängert.

=== Sound-Trigger ===

Soundtrigger sind nicht mit den weiter oben erwähnten Triggern zu verwechseln!

Sie stellen vielmehr eine Möglichkeit dar, direkt einen gewünschten Sound abzuspielen. Hierbei gibt es zwei Möglichkeiten:

(T.L.''soundtriggername'') ist ein einfacher Soundtrigger. Der so markierte Sound wird (einmalig) abgespielt.

(T.F.''soundtriggername'') ist ein Soundtrigger mit Dateiwechselfunktion. Hierbei wird der oberste Stackstring ausgelesen und als Dateiname verwendet, wobei der Dateipfad relativ zum Sound-Ordner des Objektes interpretiert wird.

Beispiel:

Angenommen, die Sounddatei lautet "diese.wav" und ist mit dem Trigger ''MeinTrigger'' verknüpft, dann spielt

(T.L.MeinTrigger)

die Datei "diese.wav" ab und

"andere.wav" (T.F.MeinTrigger)

die Datei "andere.wav". Alternativ zu (T.L.''soundtriggername'') kann beim Befehl (T.F.''soundtriggername'') auch ein "Nullstring" im Stack liegen (also der String: "").

=== System-Makros ===

Die bisherigen Methoden erlauben dem Script folgende Kommunikationsmöglichkeiten mit OMSI:

* Lesen von Werten über System- und vordefinierte lokale Variablen
* Schreiben von Werten über ebendiese
* Empfangen von Tastatur-, Maus- oder Systemtriggern

Schließlich gibt es noch eine weitere Methode, um mit dem Hauptprogramm zu kommunizieren, die sogenannten System-Makros, gelegentlich auch unpräzise als "Callback-Funktionen" bezeichnet.

In bestimmten Situationen ist es nötig, dass das Script Werte von OMSI bekommt, die in größeren Datenbanken vorliegen und daher nicht über vordefinierte Variablen übermittelt werden können, z.B. die Inhalte der Hofdatei. Hier kommen nun die System-Makros ins Spiel.

Diese arbeiten scriptseitig sehr ähnlich wie die lokalen, selbstdefinierten Makros: Der Aufruf (M.V.''macroname'') ruft das System-Makro auf ("V" stand ursprünglich für "Vehicle-Macro", gilt aber genauso auch in Szenerieobjekten), das sich während der Ausführung Werte aus den beiden Stacks holt und/oder in diese schreibt. Eine Aufstellung aller System-Makros findet sich hier: [[System-Makros]]

=== Bedingungen und Schleifen ===

Die einzige Steuerung des Programmablaufs ist zur Zeit nur mit der IF-Bedingung möglich.

==== IF-Bedingung ====

<pre>
'Hier muss eine Bedingung stehen, z.B.:
(L.L.bla) 1 =
{if}
'Dieser Abschnitt wird ausgeführt, wenn bla = 1 ist:
2 3 +
{else}
'Dieser Abschnitt wird andernfalls ausgeführt:
3 4 +
{endif}
(S.L.blub)
{end}
</pre>

Dass erst die Bedingung formuliert wird und dann erst das Schlüsselwort {if} folgt, sollte einleuchten: Zunächst muss an oberster Stelle des Stacks der Wert abgelegt werden und erst dann folgt das Schlüsselwort {if}, welches diesen Wert prüft. Hierbei bedeutet ähnlich wie bei && und || Gleichheit mit Null gleichbedeutend mit ''False'', alle anderen Werte bedeuten ''True''.

Wenn also im obigen Beispiel ''bla'' den Wert 1 hat, wird ''blub'' auf den Wert 5 gesetzt, andernfalls auf den Wert 7.

Verschachtelungen der IF-Bedingung dienen als Ersatz für die (nicht vorhandenen) "Else-If"-Konstruktionen:

<pre>
'Hier muss eine Bedingung stehen, z.B.:
(L.L.bla) 1 =
{if}
'Dieser Abschnitt wird ausgeführt, wenn bla = 1 ist:
2 3 +
{else}
(L.L.bla) 5 =
{if}
'Dieser Abschnitt wird ausgeführt, wenn bla = 5 ist:
3 4 +
{else}
'Dieser Abschnitt wird andernfalls ausgeführt:
13
{endif}
{endif}
(S.L.blub)
{end}
</pre>

Hierbei ist insbesondere auf das doppelte {endif} zu achten! Hier gilt:

* bla = 1 ==> blub = 5
* bla = 5 ==> blub = 7
* sonst ==> blub = 13

[[Kategorie:Nachschlagewerk für Addon-Entwickler]]