[Denkansatz] Konstanten über die HOF-Datei definieren

Das Forum befindet sich im reduzierten Betrieb. Die Addon- und Supportforen bleiben weiterhin verfügbar.
Bitte beachte, dass OMSI nicht mehr weiterentwickelt wird. Ein Teil der Entwickler widmet sich inzwischen der Entwicklung eines neuen Simulators. Weitere Informationen zum LOTUS-Simulator findest Du hier.
Ein communitybetriebenes Nachfolge-Forum wird hier verlinkt, sobald es gegründet und bereit ist.

    Moin,


    Wir alle kennen ja das Problem, dass für kleinste Unterschiede immer separate .bus-Dateien erstellt werden müssen.
    Zwar gibt es die Constfiles, in denen auch Anfänger relativ einfach Werte ändern können, aber auch diese müssen über eine extra .bus-Datei geladen werden.


    Ich habe mir hierzu Gedanken gemacht und bin auf eine Lösung gekommen, die ich euch hier präsentieren möchte: HOF-abhängige Konstanten.
    Natürlich gibt es offiziell keine Möglichkeit, Konstanten über die HOF-Datei zu definieren, sonst wüsstet ihr davon.

    :)


    Stattdessen definiere ich die Konstanten als Busstop-Einträge.


    Die Konstanten meines Türskriptes sehen z.B. so aus (Rheinhausen.hof):


    Der Name der Konstanten ist als Busstop-Ident definiert, der Wert als String #0, getrennt durch ein Tab, mehr ist nicht erforderlich.
    Im Gegensatz zur constfile wären hier sogar Strings oder mehrere Werte pro Konstante möglich.


    In Spandau möchte man nun ein anderes Verhalten der Türsteuerung als in Rheinhausen und würde z.B. den folgenden Abschnitt in die Spandau.hof kopieren:


    Schon hätte man zwei verschiedene Türsteuerungen im selben Bus, ohne umständliches Anlegen einer neuen .bus-Datei.


    Diese "Konstantenblöcke" lassen sich übrigens mühelos in jede .hof einfügen.
    Es ist kein Eingliedern in die bestehende Busstop-Liste nötig und es funktioniert auch in Zusammenspiel mit dem alten .hof-Format.


    Sowas hier ginge also auch:


    Das Auslesen ist ganz einfach über die Busstop-Funktionen möglich (GetBusstopIndex sowie GetBusstopString).
    Der Wert in Stringform wird dann noch per $StrToFloat in eine Gleitkommazahl umgewandelt, damit wir ihn in if-Abfragen verwenden können.


    Zur Vereinfachung kann man sich eine kleine Funktion schreiben, etwa so:

    Code
    1. {macro:GetSettingsValue}
    2. (M.V.GetBusstopIndex) 0 (M.V.GetBusstopString) $StrToFloat
    3. {end}


    Über diese Funktion kann der Wert dann während der Laufzeit ausgelesen, oder (was ich persönlich bevorzuge), beim Laden des Busses einmalig in Variablen gespeichert werden:


    Ich habe hier zwecks Übersichtlichkeit den Variablen das Präfix "CONST_" gegeben, aber das muss man natürlich nicht.


    Die Verwendung der Konstanten im Skript funktioniert dann wie bisher, nur werden sie anstatt über (C.L.xxxxx) mit (L.L.CONST_xxxxx) abgerufen.


    Zu beachten ist noch, dass bei nicht definierten Konstanten der Wert immer -1, also negativ ist.
    Zur Lösung dieses "Problems" (wenn man es denn als solches ansieht) nutze ich den folgenden Code:

    Code
    1. "frontdoor_needs_stopbrake" (M.L.GetSettingsValue) s0 -1 = {if} 1 {else} l0 {endif} (S.L.CONST_frontdoor_needs_stopbrake)
    2. "backdoor_needs_stopbrake" (M.L.GetSettingsValue) s0 -1 = {if} 1 {else} l0 {endif} (S.L.CONST_backdoor_needs_stopbrake)
    3. "frontdoor_sets_stopbrake" (M.L.GetSettingsValue) s0 -1 = {if} 0 {else} l0 {endif} (S.L.CONST_frontdoor_sets_stopbrake)
    4. "backdoor_sets_stopbrake" (M.L.GetSettingsValue) s0 -1 = {if} 0 {else} l0 {endif} (S.L.CONST_backdoor_sets_stopbrake)
    5. "frontdoor_locks_stopbrake" (M.L.GetSettingsValue) s0 -1 = {if} 0 {else} l0 {endif} (S.L.CONST_frontdoor_locks_stopbrake)
    6. "backdoor_locks_stopbrake" (M.L.GetSettingsValue) s0 -1 = {if} 1 {else} l0 {endif} (S.L.CONST_backdoor_locks_stopbrake)
    7. "frontdoor_separated" (M.L.GetSettingsValue) s0 -1 = {if} 1 {else} l0 {endif} (S.L.CONST_frontdoor_separated)
    8. "backdoor_automatic" (M.L.GetSettingsValue) s0 -1 = {if} 1 {else} l0 {endif} (S.L.CONST_backdoor_automatic)
    9. "stopbrake_persistent" (M.L.GetSettingsValue) s0 -1 = {if} 0 {else} l0 {endif} (S.L.CONST_stopbrake_persistent)
    10. "AI_always_open_frontdoor" (M.L.GetSettingsValue) s0 -1 = {if} 1 {else} l0 {endif} (S.L.CONST_AI_always_open_frontdoor)


    Dieser weist bei nicht definierten Konstanten (-1) automatisch einen Standardwert zu, so ist frontdoor_needs_stopbrake z.B. standardmäßig aktiviert (1).


    Vielleicht kann ja jemand mit meinen Erkenntnissen bzw. Ideen etwas anfangen.
    Am Besten wäre natürlich eine offizielle Unterstützung von Konstanten in der HOF-Datei in kommenden OMSI-Versionen.
    Bis dahin fährt man mit meiner Lösung aber ganz gut, denke ich.


    Wer mal ein bisschen damit rumexperimentieren möchte, kann sich hier mein gemoddetes door-Script für NL202 / NG272 laden.
    Hinweis: Die Konstante frontdoor_separated ist zurzeit funktionslos, die habe ich noch nicht eingebaut. Auch ansonsten erhebt das Skript keinen Anspruch auf Vollständigkeit.


    Freue mich auf Kritik & Anregungen.

    :)


    Gruß,
    SchulterSack

    Die Idee ansich gefällt mir schonmal sehr gut. Auch wenn ich nicht dein Scriptverständnis habe, kann ich zumindest deinen Gedankengang folgen.


    Einige Fragen dazu habe ich aber noch.
    Derzeit hat jeder Bus seine eigene Türsteuerung. Muß dann die gesamte Türsteuerung irgendwie neutral gesetzt werden ? Oder muß nur dein Abschnitt in der door.osc eingesetzt werden ? Oder muß jeder Bus eine ganz bestimmte Türsteuerung haben ?


    Diese Einträge beziehen sich ausschließlich auf die Türsteuerung oder umfassen diese Werte auch andere Teile die mit der Tür zu tun haben ? (Haltestellenbremse notwendig/nicht notwendig, mit oder ohne Gasstoß, usw) Ich meine die Frage jetzt nur in Bezug auf das was du bisher umgesetzt hast, nicht was du damit noch zusätzlich umsetzen möchtest.


    Der Sinn der Sache ist eigentlich klar und für mich ergeben sich dort etliche Vorteile. Das wäre eine schöne Erweiterung für die universelle Hofdatei.
    Der größte Vorteil daraus ergibt sich, daß man nicht erst nach einer bestimmten Türsteuerung suchen muß für einen bestimmten Bus. Das bringt mehr Realität ins Spiel.


    Schöne Idee, SchulterSack.

    Zitat von Tatra

    Einige Fragen dazu habe ich aber noch.
    Derzeit hat jeder Bus seine eigene Türsteuerung. Muß dann die gesamte Türsteuerung irgendwie neutral gesetzt werden ? Oder muß nur dein Abschnitt in der door.osc eingesetzt werden ? Oder muß jeder Bus eine ganz bestimmte Türsteuerung haben ?


    Ja, im Prinzip muss jeder Bus ein "spezielles" Türskript nutzen. Speziell in der Hinsicht, dass es von den herkömmlichen Konstanten auf die "HOF-Konstanten" umgeschrieben wurde.
    Dazu kommt natürlich noch, dass ich in mein Skript viele neue Funktionen eingearbeitet habe, die im Original gar nicht vorgesehen sind.
    So gibt es im Standard-Türskript von M+R z.B. keine Konstante "frontdoor_sets_stopbrake".


    Im Idealfall hat man also für jeden Bus so ein erweitertes Türskript, welches die gleichen Konstantennamen nutzt.
    Davon sind wir aktuell aber leider noch weit entfernt, viele Busbauer nutzen total vermurkste Skripte, die man erstmal von Grund auf neu schreiben müsste.


    Zitat von Tatra

    Diese Einträge beziehen sich ausschließlich auf die Türsteuerung oder umfassen diese Werte auch andere Teile die mit der Tür zu tun haben ? (Haltestellenbremse notwendig/nicht notwendig, mit oder ohne Gasstoß, usw) Ich meine die Frage jetzt nur in Bezug auf das was du bisher umgesetzt hast, nicht was du damit noch zusätzlich umsetzen möchtest.


    Die obigen Beispiele beziehen sich auf die Türsteuerung (also den Oberbegriff, wozu ich auch Sachen wie Haltestellenbremse notwendig zähle).
    Es würde aber genauso auch mit IBIS, Motor, Bremse, Scheibenwischer, etc.pp. funktionieren.

    :)

    Die Idee an sich finde ich klasse. Das würde den Mapbauern noch mehr individuelle Gestaltungsmöglichkeiten geben. Ich sehe nur eben das Problem, das allen Busbauern klar zu machen, dass diese Umsetzung sinnvoll wäre und so das volle Potenzial auszunutzen, indem alle dieselben Namen für die Konstanten verwenden.


    Übrigens ein kleiner Vorschlag, dessen Umsetzung meiner Meinung nach noch sinnvoll wäre:


    Spoiler anzeigen

    “Half of seeming clever is keeping your mouth shut at the right times.” ― Patrick Rothfuss, The Wise Man's Fear

    Servus,


    sorry, aber die Idee finde ich genial. Wenn man nämlich weiterdenkt, kann man damit die GlobalStrings auch in OMSI 1 nutzen, womit ich noch einen Grund weniger hätte, mir OMSI2 zu holen.
    Das könnte dann so aussehen:

    Code
    1. "..\..\Announcements" 0 (M.L.GetDepotStringGlobal) "\" $+ $+ (L.$.act_busstop) $+

    statt

    Code
    1. "..\..\Announcements" 0 (M.V.GetDepotStringGlobal) "\" $+ $+ (L.$.act_busstop) $+


    und das ausführende Macro würde dann bspw. so aussehen:

    Code
    1. s7 "DepotStringGlobal" (M.V.GetBusstopIndex) l7 (M.V.GetBusstopString)

    und die Haltestelle in der Hof-Datei bspw. so:

    Code
    1. [addbusstop]
    2. DepotStringGlobal
    3. Spandau
    4. Spandau
    5. Spandau_94
    6. 35
    7. 36
    8. 28

    Hier muss man nur aufpassen, dass man nicht mehr GlobalStrings hat als HST-Strings bei "normalen" Haltestellen. Daher sollte man vllt. auf die Termini ausweichen, wo man standardmäßig 6 Strings hat, anstatt der 4 bei den Busstop-Einträgen.


    Auch die Ergänzung von faaabiii finde ich gut, weil man damit dann auf den vom Nutzer leichter anpassbaren Bus-Standard zurückfällt.


    Mich hast du von dieser Idee begeistert, ich bin gespannt, ob die Busbauer das auch umsetzen werden. (Wahrscheinlich nicht, aber die Hoffnung stirbt zuletzt)


    Schönen Abend noch,


    Busfanat

    "per Anhalter durch die Galaxis" und OMSI haben etwas gemeinsam!
    Es gibt eine Antwort auf alle Fragen.
    Bei "per Anhalter durch die Galaxis" ist es die 42,
    bei OMSI ist es das OMSI-Wiki!

    Freut mich, dass die Idee bei euch so gut ankommt.

    :)


    Zitat von faaabiiii

    Ich sehe nur eben das Problem, das allen Busbauern klar zu machen, dass diese Umsetzung sinnvoll wäre und so das volle Potenzial auszunutzen, indem alle dieselben Namen für die Konstanten verwenden.


    Ja, das sehe ich genauso.
    Die Skripte umzuschreiben wäre gar nicht unbedingt das Problem.
    Ich (oder jemand anders) könnte ein kleines Windows-Tool schreiben, das diese Aufgabe übernimmt.


    Das Problem ist einfach, dass für meinen Geschmack viel zu wenig auf universelle Skripte gesetzt wird.
    M+R haben diese Möglichkeit in ihren Bussen mit den constfiles ja schon wunderbar demonstriert.
    Der Trend geht heute leider in Richtung "eine door.osc pro Türsteuerung" (siehe z.B. Morphi-Soundmods, alterr Solaris, usw.).
    Dabei könnte man das alles universell über ein Skript regeln.
    Der Solaris setzt dem Ganzen mit seinen getrennten Skriptordnern jetzt noch die Krone auf.

    :pinch:


    Zitat von faaabiiii

    Übrigens ein kleiner Vorschlag, dessen Umsetzung meiner Meinung nach noch sinnvoll wäre:


    Wow, vielen Dank. Das ist echt 'ne gute Idee. Werde ich ab sofort in meinen Skripten auf jeden Fall so nutzen.

    :thumbup:


    Zitat von Busfanat

    Wenn man nämlich weiterdenkt, kann man damit die GlobalStrings auch in OMSI 1 nutzen, womit ich noch einen Grund weniger hätte, mir OMSI2 zu holen.


    Ich teile deine Abneigung gegenüber OMSI 2 zwar nicht, aber ja, das ginge wohl auch problemlos.

    ^^


    Zitat von Busfanat

    Hier muss man nur aufpassen, dass man nicht mehr GlobalStrings hat als HST-Strings bei "normalen" Haltestellen. Daher sollte man vllt. auf die Termini ausweichen, wo man standardmäßig 6 Strings hat, anstatt der 4 bei den Busstop-Einträgen.


    Mit den Termini habe ich angefangen, das war mir aber zu unflexibel, weil man immer fixe Nummern vergeben muss.
    Hier wäre eine Funktion "GetTerminusIndexByIdent" vonnöten.


    Alternativ ginge aber auch das:

    Code
    1. {macro:GetDepotStringGlobal}
    2. s7 "DepotStringGlobal" l7 $IntToStr $+ (M.V.GetBusstopIndex) 0 (M.V.GetBusstopString)
    3. {end}


    und in der .hof:


    Weiß jetzt nicht, ob OMSI 1 damit klarkommen würde, ansonsten müsste man das noch mit Leerzeilen auffüllen (das geht mit addbusstop_list deutlich einfacher - einer der Vorteile von OMSI 2 ;)).

    Guten Abend,


    Zitat von SchulterSack

    Ich teile deine Abneigung gegenüber OMSI 2 zwar nicht, aber ja, das ginge wohl auch problemlos.

    Naja, ehrlich gestanden ist es eine Abneigung gegen Steam, keine direkte Abneigung gegen OMSI2, aber das ist OT. Die vielen geposteten "OMSI-2-Bugs" scheinen großteils wie schon zu OMSI1-Zeiten nutzergeneriert zu sein.

    Zitat von SchulterSack

    Mit den Termini habe ich angefangen, das war mir aber zu unflexibel, weil man immer fixe Nummern vergeben muss.
    Hier wäre eine Funktion "GetTerminusIndexByIdent" vonnöten.

    Stimmt, das habe ich vergessen. Naja, die OMSI2-Standard-Globalstrings mit den Indizes 4, 5 und 6 beziehen sich sowieso auf die Liniensuffixe bei N/M/X-Linien, was zur OMSI1-Zeit eh wurscht ist. Ich denke aber, dass ich hier selbst kompetent genug bin, hier zu improvisieren

    ;)
    Zitat von SchulterSack

    Das Problem ist einfach, dass für meinen Geschmack viel zu wenig auf universelle Skripte gesetzt wird.
    M+R haben diese Möglichkeit in ihren Bussen mit den constfiles ja schon wunderbar demonstriert.
    Der Trend geht heute leider in Richtung "eine door.osc pro Türsteuerung" (siehe z.B. Morphi-Soundmods, alterr Solaris, usw.).
    Dabei könnte man das alles universell über ein Skript regeln.

    Grundsätzlich schließe ich mich dem an. Allerdings ist meiner Meinung nach zu beachten, dass das Scripten "neu" in der Bussim-Szene ist. 3D-Modelle, Texturen und Sounds gab es schon zu vBus-Zeiten, während die Scripts durch OMSI neu sind. Ich denke, es haben sich einfach noch zu wenige wirklich intensiv mit den Möglichkeiten der Scripts auseinandergesetzt. Möglicherweise ist der Unterschied auch jener, dass M&R bzw. jetzt M&J es mehr Leuten "Recht machen" wollten, damit sich OMSI2 besser verkauft, während die Freeware-Entwickler auch einfach nach der "Friss-oder-stirb"-Methode ihren Favoriten bauen können, ohne zwingend auf die Nutzerschaft zu achten. Was diesen aber auch nicht zu verübeln ist, denn sonst müsste es 5000 und mehr Konstanten geben, wo dann die lesefaulen/Readme-blinden/whatever Nutzer den Thread vollballern, wie man den Bus ihrer Heimat "Hinterwelt-Kaffingen" am besten nachstellt und am besten noch eine dritte/vierte Tür per Const schaltbar (geht zwar schon allein wegen der Pfade nicht, aber das weiß ja von denen, die das fordern, keiner). Ein Loch ohne Boden.


    Trotzdem Danke nochmal für deinen genialen Grundgedanken,


    Schönen Abend,


    Busfanat

    "per Anhalter durch die Galaxis" und OMSI haben etwas gemeinsam!
    Es gibt eine Antwort auf alle Fragen.
    Bei "per Anhalter durch die Galaxis" ist es die 42,
    bei OMSI ist es das OMSI-Wiki!

    Ja SchulterSack, deine Idee ist nichtnur was neues, sondern wirklich auch etwas sehr geniales. Die Möglichkeiten, die damit neu möglich sind, sind derzeit noch garnicht richtig vorstellbar.


    Aber eine klitzekleine Bitte an euch hätte ich noch:
    Könntet ihr eure Ideen auch auf deutsch schreiben ?


    Zitat von SchulterSack

    Zitat von »faaabiiii«
    Übrigens ein kleiner Vorschlag, dessen Umsetzung meiner Meinung nach noch sinnvoll wäre:



    Wow, vielen Dank. Das ist echt 'ne gute Idee. Werde ich ab sofort in meinen Skripten auf jeden Fall so nutzen.

    :thumbup:



    Bitte was ??? Sorry, Leute aber ich verstehe kein Wort. Ihr könntet genausogut auf japanisch schreiben. (achso ...., japanisch kann ich mit google übersetzen).


    Zitat von Busfanat

    Allerdings ist meiner Meinung nach zu beachten, dass das Scripten "neu" in der Bussim-Szene ist.


    Ich denke mal das nicht die wenigen Scriptfähigen User das Problem sind. Du kennst das aus eigener Erfahrung, Busfanat. Deine Vollmatrix war auch etwas absolut geniales, aber die Umsetzung kommt nicht richtig in Schwung. Nicht weil deine Vollmatrix kompliziert wäre, sondern einfach der Fakt das es etwas neues ist. Was der Bauer nicht kennt, daß frisst er nicht. Man kann nicht einfach mal ebend etwas aus einem Bus kopieren, wenn es viele Busse gibt aus dennen ich etwas kopieren kann, wo ich weiß das es funktioniert.
    Das Problem sehe ich weiterhin in der fehlenden Kommunikation. Und wie ihr schon festgestellt habt: Jeder macht sein eigenes Ding ohne Rücksicht auf die Userschaft. Und leider möchte schon jemand "jeden" Bus nach genau seinen eigenen Vorstellungen haben. Also nutzt man lieber etwas altbewährtes, statt neues umzusetzen - oder zum Ursprung zurück zugehen.


    Das selbe Problem habe ich mit meiner Idee der "universellen Hofdatei". Und was mich persöhnlich besonders freut ist der Fakt, daß man die Idee von SchulterSack, problemlos in die universellen Hofdatei einsetzen kann. Aber auch für eine universelle Hofdatei, müßen Änderungen in den Scripten des Busses vorgenommen werden. Das ist auch bei der Idee von SchulterSack zwingend erforderlich. Und genau da beginnt das Problem.
    Aber meine Unterstützung hat SchulterSack auf jeden Fall. Ich habe da auch eine kleine Idee, die ich mal ankurbeln werde. Gebt mir bitte etwas Zeit. Und übersetzt mir bitte eure "geheime Scriptsprache" bitte.

    Zitat von Tatra

    Und übersetzt mir bitte eure "geheime Scriptsprache" bitte.


    Die Idee von faaabiiii war, die Ersatzwerte, wenn eine Konstante in der HOF-Datei fehlt, aus der constfile zu entnehmen, anstatt, wie in meinem Ursprungspost, fix im Skript anzugeben.
    So kann man - theoretisch - nach wie vor das alte System mit den constfiles nutzen, ohne die HOF-Datei auch nur anrühren zu müssen, d.h. bessere "Abwärtskompatibilität".

    :)


    Wenn du sonst noch etwas nicht verstehst, frag gerne nach.
    Ich schreibe den Code gerne bewusst so kompakt wie möglich, worunter leider die Lesbarkeit etwas leidet.


    Das Beispiel könnte man z.B. ausführlich auch so schreiben:

    Code
    1. "frontdoor_needs_stopbrake" (M.L.GetSettingsValue) s0 -1 =
    2. {if}
    3. (C.L.frontdoor_needs_stopbrake)
    4. {else}
    5. l0
    6. {endif}
    7. (S.L.CONST_frontdoor_needs_stopbrake)


    Vielleicht kannst du das ja besser entziffern.

    :)

    Sorry SchulterSack, du nimmst an das ich eine gewisse Scriptfähigkeit habe. Die liegt eher bei Null oder weit drunter.


    Aus deinem Scriptbeispiel verstehe ich folgendes:


    Die Fronttür benötigt (Braucht) die Haltestellenbremse
    sonst
    10


    Sorry - keine Ahnung wieso 10.


    Das ist nur ein Beispiel, darum bat ich ja es mir auch deutsch zu übersetzen:

    Zitat von SchulterSack

    Die Idee von faaabiiii war, die Ersatzwerte, wenn eine Konstante in der HOF-Datei fehlt, aus der constfile zu entnehmen, anstatt, wie in meinem Ursprungspost, fix im Skript anzugeben.
    So kann man - theoretisch - nach wie vor das alte System mit den constfiles nutzen, ohne die HOF-Datei auch nur anrühren zu müssen, d.h. bessere "Abwärtskompatibilität".

    :)


    Das ist deutsch, das verstehe ich.
    Wenn ich einen Bus, oder auch mehrere umstelle ist es die eine Sache die eine gewisse Zeit in Anspruch nimmt. Aber eine Hofdatei für jede einzelne Karte umstellen, bei den ganzen Karten die es gibt, ist eine genauso lange Zeit die Verwendet werden muß. Aber es gibt viele User die Hofdateien erstellen. Jeder macht sein eigenes Ding. Mit der Idee von faaabiii ist es nicht zwingend notwendig alle Hofdateien anzupassen und der Bus würde trotzdem weiterhin auf allen Karten (oder besser gesagt, mit allen Hofdateien) weiterhin funktionieren. Das verstehe sogar ich, schöner Gedanke von faaabiii und eine Klasse Idee.


    Vielen Dank für die Übersetzung.

    Okay, verstanden. Wenn du also noch eine Frage hast, sag gerne Bescheid, dann versuche ich, es zu übersetzen.

    :)


    Ich kommentiere dir noch kurz den Abschnitt, damit du verstehst, was da passiert:

    Spoiler anzeigen

    Das ist für mich, so wie du es beschrieben hast, verständlich. Schön aufgeschlüsselt. So wird es auch mir Möglich mal ein Teil eines Scriptes zu verstehen. Busfanat macht das auch schon seit einiger Zeit, wofür ich ihm unendlich dankbar bin, besonders für seine Gedult dabei. Und auch dir SchulterSack, vielen Dank für die Erklärung.

    Zitat von SchulterSack

    Zudem wird dieser über s0 (S für "Schreiben") auf den 0ten Stackplatz gespeichert, oder vereinfacht ausgedrückt, in die Kiste mit der Aufschrift "0" gelegt.


    Hier erlaube ich mich eine kleine Korrektur, hoffentlich verständlich für Tatra:
    Der Wert wird mit s0 in das Register mit der Nummer 0 geschrieben und mit l0 von dort gelesen. Man könnte auch s4 und l4 nehmen. Ein Stack (zu Deutsch Stapel) hat ja die Eigenschaft, dass es sozusagen einen nur single point of access gibt, nämlich den obersten Platz. Nimmst du bei einem Stapel von Kisten (um bei dem Bild zu bleiben) mittendrin eine raus, kollabiert der ganze Stapel. Darum geht das bei einem Stack nicht. Die Register kann man hingegen beliebig lesen und schreiben. Der Stack ist im OMSI-Script sozusagen die Arbeitsebene, auf der die ganzen Operationen wirken. Um zwei Werte zu addieren, müssen diese auf den obersten beiden Stackplätzen (in den oberen beiden Kisten des Stapels) liegen. l0 packt einfach den Wert aus Register 0 in eine neue Kiste und legt diese oben auf den Stapel. s0 kopiert (heißt: die Kiste bleibt oben drauf liegen) den Wert aus der obersten Kiste des Stapels in den Register 0.


    Wo wir gerade dabei sind: Ist der Zugriff auf die Register in OMSI-Script eigentlich auch performanter als der auf lokale Variablen?


    Und zu guter Letzt: Eine interessante Idee! Konstanten in Hofdateien hatte ich mir auch schon des Öfteren gewünscht. Dass die Busbauer mitspielen, bezweifle ich jedoch.

    :|

    Beim Solaris hatte ich mich ebenfalls schon gefragt, warum nicht das gute Türscript vom NL/NG als Basis genommen wurde. Würde das Modden deutlich vereinfachen, doch das Interesse der Busbauer an solchen Dingen scheint gering zu sein.

    Zitat von ACMG

    Hier erlaube ich mich eine kleine Korrektur, hoffentlich verständlich für Tatra:
    Der Wert wird mit s0 in das Register mit der Nummer 0 geschrieben und mit l0 von dort gelesen.


    Stimmt, da habe ich Stack und Register verwechselt.


    Zitat von ACMG

    Und zu guter Letzt: Eine interessante Idee! Konstanten in Hofdateien hatte ich mir auch schon des Öfteren gewünscht. Dass die Busbauer mitspielen, bezweifle ich jedoch.

    :|


    Ja, das dürfte eine große Hürde darstellen.
    Mit deutschen Busbauern, die hier im Forum aktiv sind, kann man sich ja zumindest noch unterhalten, das ist bei den vielen internationalen Usern, die teils nichtmal Englisch sprechen, leider nicht möglich.
    Aber natürlich gibt es auch die Möglichkeit, Mods für die verschiedenen Busse herauszubringen, wie ich es oben für den NL/NG gemacht habe.
    Gerade bei beliebten Bussen wie dem Citaro oder jetzt dem Solaris würde man damit sicher eine Menge User erreichen.
    Glücklicherweise basieren fast alle Türskripte (wenn auch exrem vermurkst) auf dem M+R Original.

    Zitat von jfwds

    Was mir grade aufgefallen ist: Muss ich noch irgendwelche Einträge vor dem Einfügen löschen oder ändern? Ich wollte ein wenig experimentieren.


    Welche Einträge meinst du jetzt genau? Im Skript? In der HOF-Datei?


    Zitat von jfwds

    Geht das auch bei einem Dreitürer?


    Ich habe hier ja nur ein Konzept vorgestellt, wie man das Auslesen von Konstanten etwas dynamischer gestalten kann.
    Das funktioniert prinzipiell mit jedem Bus und jedem Skript, man muss es nur entsprechend anpassen.
    Wenn du mein oben verlinktes Türskript meinst: Dies ist für den NL202/NG272 vorgesehen und funktioniert nicht (oder nur sehr eingeschränkt) mit anderen Bussen.