Posts by Tatra

The forum is in reduced operation. The Addon and Support forums remain open.
Please note that OMSI is no longer under development. Some of the developers are now working on a new simulator. Further information concerning the LOTUS-Simulator can be found here.

    Da dort alles stimmt, liegt der Fehler in der light.osc. Dort stimmt etwas nicht mit dem Fernlicht.

    Geht das Fernlicht überhaupt an?


    Bitte beim nächsten Mal nur den notwendigen Abschnitt kopieren und nicht das gesamte Script.


    Und prüfe bitte auch die Variable in der model.cfg für den Fernlichthebel. (S.L.light_fern).

    Gibt's noch Anmerkungen zu eventuellen Fehlerquellen?

    Ganz wichtig. Frage bei langanimierten Objekten nicht den Endzustand ab. Manchmal hängt eine Tür und in der laststn.osc steht die Türstellung nicht immer genau auf 0, sondern auf über 0.0000001. Omsi schaut bis in die 7.Stelle nach dem Komma.

    Daher bei den Türen immer einen Mindestwert abfragen:

    (L.L.door_x) 0.01 <

    Du kannst den Wert noch weiter runtersetzen oder erhöhen. Die Werte in der Abfrage sind prozentuale Angaben.

    0.01 = 1%

    0.27 = 27%

    0.5 = 50%

    usw.

    Frage also nicht nach den Animationsweg von 0%, sondern immer etwas darüber (1% [0.1], oder einem halben Prozent[0.005] oder einen viertel Prozent [0.0025]). Aber untertreibe es nicht.

    Untertreibst du es, kann es passieren, dass die Nivauregulierung erst anspricht, wenn der Dämmpfungswert der Tür ausgelaufen ist, was unter Umständen einige Sekunden in Anspruch nehmen kann. Am besten sind Werte zwischen 1 und 5 %. Besonders bei anderen Bussen würden sich solche Sachen negativ bemerkbar machen, wenn der Bus z. B. eine Hubverriegelung hätte. Dann schließt die Tür bis 5% und dann wird die Tür langsam angehoben, bis der minimale Wert erreicht ist. Überprüfe die geschlossene Türstellungen in der laststn.osc in dem Map-Ordner.


    dass OMSI versteht, die Feststellbremse und die Haltestellenbremse stehen in der Oder-Beziehung und nicht alle anderen Bedinungen auch?

    Sorry, aber ich vestehe nicht was du willst. Ich vermute, du möchtest es so umsetzen, das alle vorherigen Bedingungen (NUmmer 2 bis 10 stattfinden sollen, entweder mit der Haltestellenbremse oder der Feststellbremse.


    Edit: Jetzt habe ich es verstanden was du meintest. Das liegt an deiner Schreibweise. Omsi arbeitet deine Liste von oben nach unten ab. Daher mußt du die Bremsen ganz oben setzen, damit zuerst abgefragt wird, ob eine der beiden Bremsen aktiv ist, damit der Rest weiter berechnet wird. Am Ende geht es nicht, weil du nicht mehr als 8 Stackplätze belegen kannst (Stack 0 bis Stack 7).

    Oder du nutzt die schattenvariable Bremsabfrage.

    Bei deiner Schreibweise wird jeder einzelne Punkt eingelesen und berechnet, dann der nächste eingelesen und berechnet, dann der nächste ... usw.


    In der Model.cfg steht die Variable, wann ein Kontrollicht auf die Leuchttextur umschaltet:

    [matl_change]

    normale Textur.bmp

    0

    Variable X

    usw.


    Im Script mußt du dann den Abschnitt finden, wo die Kontrollleuchten eingestellt sind (meist im Script: cockpit.osc

    Dirt mußt du nach dem Abschnitt (meist innerhalb eines Marcos) suchen. wo die Variablen abgefragt werden, wann ein Kontrolllicht blinken soll.

    Das Ergebnis wird in der Variable X (S.L.Variable_X) gespeichert. Der Variablenname muß mit dem Eintrag der Variable in der model.cfg überein stimmen. Dann kann Omsi auf die jeweilige Nachttextur umschalten die du unter dem Befehl [matl_lightmap] oder [matl_nightmap] findest.

    (L.L.elec_busbar_main) (C.L.elec_busbar_minV) >

    Bedeutet: (Abfrage der Bordspannung) (Abfrage der Konstante-Mindestwert der Bordspannung) größer als

    Auf deutsch: der Mindestwert der Bordspannung muß größer sein als die Bordspannung, dann ...


    Die Abfrage der Busgeschwindigkeit lautet: (L.L.velocity) ...

    Beispiel: (L.L.velocity) 2 < heißt, wenn die Geschwindigkeit unter 2 km/h liegt, dann ...


    Irgendwo im Script gibt es ein {Macro:Name der Nivauregulierung} die diese Regulierung, also das ausführen selbiger, steuert.

    Darunter gibt es Bedingungen, wann diese gesteuert wird. Hier müßen die Bedingungen geändert werden.

    Mit den beiden Variablen (L.L.bremse_halte) und (L.L.bremse_feststell) werden die Bedingungen abgefragt, ob diese aktiv sind. Andere Bedingungen müßen gegebenenfalls gelöscht werden (aber nicht alle!!!). Beispielweise müssen Türen entfernt werden, ob diese offen sind, oder angepasst werden, damit diese geschlossen sind (L.L.door_x). Andere Abfragen müßen bleiben, wie beispielsweise der Luftvorrat.

    Sehr gut, Danke für die Rückmeldung. Da hilft man gern.


    Wäre es bei eine max. Höhe von 24 anders geworden dann wäre das Format richtig, aber die Darstellung der Scripttexturen wäre fehlerhaft gewesen. Wenn ich mir deine Screenshots anschaue, dann hast du Pixelgenau gemappt.

    Hallo Sven,


    Hast du alle Font neu erstellt? Überprüfe sicherheitshalber Mal, im welchen Code die Fontdatei erstellte wurde. Korrekt wäre ANSi. UTF-8 kann keine Umlaute erkennen. Für die kleine Schrift stimmt es. Denn es fehlen lediglich die Zeichen vom deutschen Layout.


    Was passiert mit den Umlauten, wenn du die Schrifthöhe auf 24 begrenzt? Ich nehme mal an, das du Scripttexturen verwendest? Oder sind das Texttexturen?

    Hier einige Tipps:

    zuerst die Schalterfunktion ändern. Wenn der schon animiert ist, kannst du die Funktion in der model.cfg ändern:


    [mouseevent]
    Funktionsvariable

    statt Funktionsvariable steht ein anderes Wort da. Das muß geändert werden. Im Script für die Klimaanlage muß du nun nach der Variable schauen, welche die Klimaanlage einschaltet. Diese Variable muß dann unter [mouseevent] erscheinen.


    Dein Problem ist allerdings:

    ... nicht die geringste Ahnung was man da ändern muss, ...

    Damit wird es kaum möglich sein, die richtige Variable zu finden, damit die Klimaanlage auch aktiviert werden kann.

    Gibt es irgendwo eine Liste, was genau neu ist? Und eine Übersicht über alle vorhandenen Linien. Auf der WebDisk ist die Liste entweder nicht vollständig oder es wurden Linien gelöscht.


    Mir geht es um die Linie ALX. Also die reine Autobahnlinie, direkt zwischen den Hauptbahnhöfen.

    Sind die Schattenhaltestellen gesetzt worden, damit die Haltestellenansagen nicht zu früh abgespielt werden und die Passagiere nicht zu früh auf den Ausstieg warten?

    Ich fürchte bisher nur, dass es extrem anstrengend wird, auf den Bildern zu erkennen, ob das Cockpit jetzt um bspw. 65° oder 70° zum Boden geneigt ist.

    Nein ist es nicht. Erstelle ein einfaches 3D-Objekt mit mindestens 4 Ecken (es darf auch rund sein). Das Objekt sollte (oder muß zwingend) eben sein. Dann lege es auf das Rundinstrument, Bildschirm, Oberfläche des Amaturenbrettes. Nun nur noch solange anpassen, bis es ganz knapp darüber liegt. Ein Grad Veränderung, sollte zeigen, dass dein Probeobjekt versinkt. Die korrekten Winkel kannst du dann einfach auslesen.

    Trotzdem weiß ich jetzt schon, dass es mich extrem nerven wird, die ganzen Winkel der Schalter zum Rest und Neigungen des Cockpits selbst einzustellen. Ich lass mich aber mal überraschen wie es wird.

    Es ist wie bei allem anderen was du bisher gemacht hast, immer das selbe. Der Anfang ist echt zum kotzen. Aber wenn du weißt, wie es geht, wird es immer einfacher. Heißt, der erste Schalter wird eine Mordsarbeit, alle folgenden sind dann Kinderleicht. Wenn du einmal weißt wie es geht, dann geht es schnell von der Hand. Du arbeitest mit Blender? Dann frage ma einen Profi, der sich mit Blender auskennt (Lukas[rumpelhans]), wie die sache mit dem Objektursrpüngen ist. Ich arbeite mit zModeler, da ist es zwar das selbe, aber mit einer anderen Menüführung. Da arbeite ich mit duplizierten Objekten. Das Einstellen ist aber im Grunde einfach. Mit der Taste "N" rufst du das Menü dafür auf und stellst die Winkel ein. Wenn es passt, haste doch schon alles. Ich glaube mich zu Erinnern, dass die Winkeleinstellungen rechts oben waren.


    Wenn du da mehr zu weißt und mich an deinem Wissen teilhaben lassen willst, sehr gerne :)

    Deswegen meinen Kommentar. Wieviele Polygone hat dein Lüftergitter? Wieviele benötigt man Maximal? Genau 12 Polygone! Für eine einfache Variante. Es geht noch einfacher, aber nicht plastisch.

    1. baue einen Kasten in Blender. Die Vorderseite besteht aus 2 Polygone. mehr braucht es nicht. Dazu baust du die Seitenwände, wobei die Sichtflächen nach innen, in den Kasten zeigen. Die Rpückwand zeigt ebenso nach innen. Nur die Front zeigt nach außen.

    2. Mappen! Hier ist die Textur entscheidend:

    Links oben die Textur für außen. Im Beispiel nur eine einfache 08/15-Skizze. Rechts daneben ist der Alphakanal. Beide Bilder fügst du mit einem Bildbearbeitungsprogramm zusammen (oder mit DXTBmp Manipulator [kostenlos]) Alles was auf der Alphatextur schwarz ist wird durchsichtig, mit grau wird es nicht ganz so durchsichtig. Was weiß ist, ist undurchsichtig und erhält die Textur. Der Rest vom Kasten bekommt eine gefleckte Textur, wie unten, nur viel dunkler. Gern mit einem dunkelgrauen Bild vom Motor. Man sieht ohnehin nicht sehr viel durch das Gitter. Aber es scheint, als wenn etwas dahinter wäre. Weil es so dunkel ist kann man es nur erahnen.

    Das ganze benötigt keine Scripte, sehr wenige Texturen und ist recht einfach zu erstellen, wenn man es einmal gemacht hat. Der Katen sollte eine Tiefe von wenigen Centimetern aufweisen (5-10 cm, wenn der Platz vorhanden ist). Je größer die Löcher in den Gitter sind, desdo dunkler muß der Hintergrund werden. Denn der ist meistens recht dunkel. Nur ein komplettes Schwarz, macht den Effekt zunichte. Wobei man bei einem fahrbaren Busmodell, die Farben schwarz und weiß nicht benutzt (außer in der Alphatextur). Schwarz hat einen negativen Effekt, den man sich bei KI-Fahrzeugen zu nutze macht. Der Innenraum ist komplett schwarz oder Radkästen, womit du nichtmehr erkennen kannst ob das ganze ausmodelliert wurde oder sehr polygonarm erstellt wurde.


    Soweit verstanden?

    Da ich bisher schon hart am Cockpit verzweifelt bin,

    Womit hast du denn genau Probleme? Vielleicht kann man dir hier das ein oder andere erklären, wie man etwas umsetzt und baut.



    Damit wird OMSI, soweit ich weiß, nicht klarkommen. Sprich, ich werde später hingehen, und die Menge an ausmodellierten Details reduzieren und sowas wie einzelne Schrauben oder ausmodellierte Lüftungslöcher in Texturen brennen lassen.

    Für die Lüftungsgitter gibt es mehrere Möglichkeiten, einerseits Polygonarm zu bauen und andererseits einen plastischen Eindruck zu bekommen.

    Dazu hast du zwei Möglichkeiten:


    - Entweder suchst du den Eintrag im Script für das Fernlicht (S.L.light_fern) und schreibst darunter

    0 (S.L.nebelschw) Suche bitte nach dem richtigen Befehl, der kann von Bus zu Bus unterschiedlich sein.


    - Oder du suchst im Abschnitt vom Nebellicht (S.L.nebelschw) und trägst darüber be den Bedingungen dazu

    (L.L.light_fern) ! &&


    Das war es dann schon. Aber bitte nur eine der beiden Möglichkeiten nutzen.

    Das kommt auf den Bus an. Einige Busse, besonders bei osteuropäischen Buserbauern, sind die Kennzeichen statisch. D.h. diese wurden über die Textur festgesetzt. Hier muß man über die Textur die Kennzeichen ändern. Um von Omsi generierte Kennzeichen zu erstellen, ist es zwigend notwendig, mit einem 3D-Programm neue Meshs für die Texttextur zu erstellen. Ohne diese Flächen geht es nicht. Dann kann man diesen Flächen einen Font (Schriftart) zuweisen und die Kennzeichen werden von Omsi nach der Vorgabe erstellt. Also entweder über die Kennzeicheneingabe bei der Busauswahl oder über die Eintragungen der Busdatei und der Fahrzeugnummern in der Registrierungsdatei.
    Scriptarbeiten sind dafür nicht erforderlich, solange man kein zweizeiliges Kennzeichen am Heck sehen möchte.

    Falsch. Das ist die Berechnung der Türbewegung. Soll die Tür blinken? Das geht auch, ist aber wenig sinnvoll.


    Schau mal ob es ein Display-Script gibt. Dort steht, wann die Türkontrolle aktiv sein soll. Das von der 2. Tür sowie von der 3. oder eventuell 4. Tür.


    Das ganze Script, das du hier einkopiert hast, kann ich mit einer einzigen Variable abfragen
    (L.L.door_4) 0.2 >
    Das ist alles!


    Der Abschnitt mit dem Bereich timegap ist für die Zeit, die die Tür braucht um zu öffnen oder zu schließen.

    aber verschiebt sich dann der Objektursprung mit? Denke ja. (?)


    Kommt drauf an. Es gibt eigentlich drei wichtige Punkte in Blender.
    1. Der Nullpunkt des Koordinatensystems in Blender. Meist nur durch helle Linien dargestellt die nie enden.
    2. Der Objektursprung. Das sind die kleinen drei Pfeile. Und diese kannst du verschieben
    3. Das Objekt ansich, was du natürlich verschoben hast.
    Ich kenne mich mit Blender nicht aus, weil ich nur mit dem zModeler arbeite. Aber dort wird es vermutlich genauso gehandhabt.
    1. Das Objekt erstellen, wobei der Objektnullpunkt an der Stelle liegt, wo Blender seinen Nullpunkt hat.
    2. Dann wird das Objekt an die Stelle verschoben, wo das Objekt hingehört.
    Beispiel
    X=0.2
    Y=4.5
    Z=1.4
    3. Nun wird der Objektursprung auf das Blender-Koordinatensystem zurück gesetzt. Also X, Y und Z = 0. Der Schalter bleibt auf seiner Position!
    4. Nun wird das Objekt und der Objektursprung nochmals verschoben, auf die Stelle wo das Objekt sitzen soll.
    Also nach Beispiel auf
    X=0.2
    Y=4.5
    Z=1.4
    Dabei verschiebt sich der Schalter auf
    X=0.4
    Y=9
    Z=2.8
    Damit haben wir drei Punkte.
    A - Den Nullpunkt von Blender = Nullpunkt des Busses.
    B - Objektursprung auf der Position des Tasters
    C - Objekt befindet sich außerhalb vor dem Bus.


    Omsi setzt den Schalter ein und setzt den Objektursprung auf die 0-Koordinate des Busses. damit ist der Schalter im Amaturenbrett. Für die Animation und nur für die Animation setzt Omsi den Bewegungsursprung dorthin, wo der Objektursprung in Blender war.
    Dann kommt in der model.cfg
    [newanim]
    origin_from_mesh


    Bleibt der Objektursprung in Blender auf der Blender-Nullkoordinate dann schreibst du
    [newanim]
    origin_trans
    0.2
    4.5
    1.4
    (siehe Beispiel oben)
    Darunter kommen dann die Verdrehungen des Objektursprung, da sich in Omsi alle Objekte ausschließlich um die X-Achse drehen und nur um die X-Achse.
    origin_rot_x
    xyz


    origin_rot_y
    xyz


    origin_rot_z
    xyz


    Prinzip soweit klar?


    ---------------------------------------------------------------------
    Zu deinen Kommentaren in rot:

    [mouseevent]
    cp_kneel_up_toggle


    Gibt an was passiert wenn ich auf das Objekt klicke (steht im Trigger)


    Das ist die Triggervariable. Also im Prinzip hast du recht. Diese Variable soll sich ändern, wenn die Maus dort geklickt wird. Aber richtig heißt es: Die Variable cp_kneel_up_toggle wird von Zustand 0 auf 1 gesetzt, wenn der Zustand vorher 0 war. Ansonsten wird er von 1 auf 0 zurück gesetzt.

    {trigger:cp_kneel_up_toggle} Ist der Befehl für das Mausevent
    (T.L.ev_VDV_toggle_on) Ist ein Sound Trigger
    1 (S.L.cp_kneel_up_mode) Steht auch in der Model. wann das Objekt bewegt wird
    {end}


    Genau das wird ausgeführt
    Ein weiterer Klick und es wird ein weiterer Trigger ausgeführt.

    {trigger:cp_kneel_up_toggle_off}
    0 (S.L.cp_kneel_up_antirepeat) (S.L.cp_kneel_up_mode) s1
    (T.L.ev_VDV_toggle_off)
    {end}


    Mit dem ersten Klick wird die variable cp_kneel_up_mode auf den Zustand 1 gesetzt. Ein weiterer Klick geht bei diesem Trigger nicht, weil die Variable cp_kneel_up_mode schon den Zustand 1 hat. Also wird der folgende Trigger ausgelöst. Damit wird der Zustand des Objektes auf den Zustand 0 gesetzt. Das ganze wiederholt sich immer wieder, solange die Klickst. Jeder klick verändert den Trigger einmalig und beläst ihn dann dort. Das kannst du dann auch in der lastsnt.osc im Mapordner überprüfen
    cp_kneel_up_mode
    0
    oder
    cp_kneel_up_mode
    1



    Die Frage kannst du dir allein beantworten, wenn du das grüne liest.


    Das ganze nochmal:


    Das sollte deine frage beantworten.



    Wenn cp_kneel... (was im Trigger steht wann es eintritt?) dann rotiert das Objekt um 8


    Um 20°. Alle Angaben sind in Grad. Somit rotiert das Objekt um den (in Blender positionierten) Objektursprung. Dabei verändert sich der Winkel um 20 °. Also von 10° nach -10° = 20° gesamt.


    Wenn der erste Teil den Schalter von Position 0 in Position 1 bringt, was soll der Schalter dann machen? Sofort wieder in Stellung 0 zurückgehen? Ist das dann ein Schalter oder ein Taster???
    Also macht der erste Trigger nur eine Bewegung. Er versetzt den Schalter von Position 0 auf Position 1. Wie soll der Schalter wieder zurück kommen? Das macht der zweite Trigger. Wenn die Variable cp_kneel_up_mode 1 ist, dann wird der erste Trigger ignoriert und der zweite Trigger wird berechnet. Also setzt der zweite Trigger das Objekt in den Originalzustand zurück und alles beginnt von vorn.


    Was macht der letze Teil?


    Der Teil ist eigentlich ein Macro. Er hat nichts mit dem Schalter zu tun, sondern mit dem Kneeling.
    (L.L.cp_kneel_down_sw) ! (S.L.cp_kneel_down_sw)
    Lese den Wert der Variable cp_kneel_down_sw aus.
    Dann negiere den Wert (also von 0 auf 1 oder von 1 auf 0) und speichere ihn in den Stack.


    (L.L.door_0) 0 =
    (L.L.door_1) 0 = &&
    (L.L.door_2) 0 = &&
    (L.L.door_3) 0 = &&
    (L.L.door_4) 0 = &&
    (L.L.door_5) 0 = &&
    (L.L.door_6) 0 = &&
    (L.L.door_7) 0 = &&
    Wenn alle Türen den Zustand 0 haben (also geschloßen sind) dann:
    0 (S.L.kneel_allowed) (S.L.kneel_locked) (S.L.kneel_auto_set)
    sind diese drei Variablen auch 0. Ist eine der Türen nicht geschloßen (oder nicht vollständig geschloßen) dann (ansonsten):
    1 (S.L.cp_kneel_down_mode) s1
    bleibt die Variable auf Zustand 1, solange bis alle Türen vollständig geschloßen sind.


    Vorsicht: Das ganze ist jetzt sehr vereinfacht erklärt und stimmt nicht zu 100%, denn das Kneeling wird hier garnicht berechnet, sondern nur ob das Kneeling ausgeführt werden soll oder nicht, bzw ob das Kneeling zurückgesetzt werden darf oder nicht. Hier wurden einige Sachen anders umgesetzt als es normalerweise gemacht wir. So wird ein Schalter nicht von 10° nach -10° bewegt, sondern von 0 nach 20°. Dann kommt die Kontrollabfrage, ob das Kneeling ausgeführt werden darf oder nicht in den Abschnitt Kneeling. Diese zusätzlichen Eintragungen sind der Grund dafür warum die Performance leiden kann, wenn viele solcher Fehldinge eingesetzt wurden. Also ist dein Ausschnitt für Erklärungen etwas ungeeignet. Daher habe ich es etwas anders erklärt, als es in Omsi wirklich passiert. Die grundlegende Wirkungsweise ist aber vollkommen gleich.

    warum tut er das aber so extrem?


    Weil in der o3d-Datei drin steht, wo sich der Objektursprung befindet. Und dieser befindet sich an der Stelle, wo sich der Rotationspunkt des Warnblickschalters befindet.


    Nun hast du den Schalter via Daueranimation verschoben. Und in der Modeldatei hast du eingetragen, das er den Objektursprung als Rotationspunkt verwenden soll.


    [newanim]
    origin_from_mesh


    Du hast NUR den Schalter via Daueranimation verschoben. Der Rotationsursprung befindet sich dort wo der Warnblinklichtschalter sitzt. Und genau diesen soll Omsi verwenden.
    Wo ist der Fehler

    ?(

    Vielleicht solltest du die Kalorifer (Lüftungsgitter) nicht ausmodellieren. Das frisst zu viele Polygone. Es gibt zwei Möglichkeiten, diese umzusetzen.


    Eine Variante wäre die Außenfläche teiltranzparent zu gestalten (so wie die Fenster) und dahinter ein schwarzes Mesh zu setzen. wahlweise geht auch ein schwarzes Lochmesh dazwischen.
    Die andere Variante wäre die Lüftungsschlitze allein über die Textur zu setzen.


    Du wirst im Laufe des Fahrzeugbaus noch mehrere Objekte haben, die reichlich Polygone fressen.


    Ansonsten sieht das Fahrzeug ansich schon sehr ansehnlich aus. Kritikpunkte kann ich keine geben, weil ich den Bus nicht real kenne.

    Schmeiß doch mal einer die Abschnitte aus dem Display-Script in einen Spoiler. Von der 3. und von der 2.Tür.


    Nutzt die Model.cfg. Dort stehen die Objektdateien drin. Aber unter den Modeleinträgen stehen vor allem Variablen drin, die man nutzen kann. Diese finden sich in den Scripten wieder. So ist ein finden einfacher.
    Ich habe keine Ahnung wie die heißen, aber ihr müßt in der model.cfg nach den variablen suchen, diese sucht ihr dann in den Scripten. Innerhalb der Macros MUSS dann auch die Zeitvariable stehen (L.L.timegap).
    Solche Variablen sind FEST und nicht frei wählbar. Die variable Timegap steht überall dort, wo etwas Zeitverzögert ist oder in Zeitintervallen funktionieren soll.

    Bei allem was du machst, mußt du sehr genau hinsehen. Später einen Schreibfehler zu finden ist eine sehr mühsame und zeitraubende Arbeit.


    Daher nochmal zur Erinnerung
    Scripte sind Dateien in dennen Berechnungen stattfinden. Diese befinden sich in dem Scriptordner und haben die Dateiendung .osc. Alles andere sind keine Scripte, Weder die Model-, Bus- Passengercabin-, Pfad-, Hof- Sound- oder auch Textdateien.
    Nimm dir als Grundlage irgendeinen anderen Taster aus dem oder einen anderen Bus. Der Rest ist dann nur noch kopieren, einfügen und anpassen.
    Alle Variablennamen sind deine Sache. Du kannst diese benennen wie du es willst. Triggernamen sind auch frei. Allerdings solltest du dir überlegen, ob einige Sache mittels Tastaturtasten funktionieren sollen. Man kann ja nur eine Taste mit einer Funktion belegen.
    Achte in den Scripten auf eine Übersichtliche Schreibweise. Das macht später den Durchblick einfacher. Besonders für andere User. Arbeite auch mit Kommentaren, die auskommentiert werden.
    Ein Hochstrich am Zeilenanfang ist dabei wichtig. Und alle Trigger sauber beenden {end}.


    Ansonsten bist du auf dem richtigen Weg, Omsi langsam zu verstehen und Änderungen umzusetzen. Bleib dran!