[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.
  • The idea is awesome--I just wish it weren't limited to data but could be extended to accommodate for logic as well. What I mean is something along the lines of:

    Code
    1. "map_name" (M.V.GetBusstopIndex) 0 (M.V.GetBusstopString) "_some_subsystem_name" $+ (S.$.delegatee_name)
    2. (M.L.(L.$.delegatee_name)) // impossible, as "OMSI-script" does not support reflection, i.e., dynamic macro invocation


    As a workaround, simple boolean expressions ("var1 && var2

    ||

    (!var3)") could be embedded as hof-specific constants' values--but, obviously, even if they were not arbitrary in length and composition, parsing them in the script would still be pure hell (but perhaps an OMSI plugin could handle the parsing and callback to the script with the expression's evaluated outcome once done). But there's of course always the additional insurmountable obstacle of having to declare everything in advance within the .bus file...


    Were there a practical workaround to this problem, map-specific logic could be transparently plugged into the scripts to extend their capabilities, by enhancing their "awareness" of their execution context. Suppose, for the sake of argument, that on some map "M" there is a tunnel between two stops, and that we would like AI buses to unconditionally switch their lights on while transiting between those two stops. The script could then have its default behavior overridden, by consulting the map-specific rules for the lighting subsystem (i.e., in the first hypothetical example, by delegating to some "M_lights_frame" macro); the latter, having full "knowledge" over the map's characteristics (distance between stops; stop profiles; anticipated min/max passengers boarding at a particular stop; etc.) could then forward this information to assist its caller in adapting in the most realistic way possible.


    Ah, daydreaming can be so much fun...

    :)
  • Es gäbe ja auch einfach die Möglichkeit, die Global Strings zu erweitern, zum Beispiel um einen 7. String für die Türsteuerung, etc.

    Wir sehen uns alle in der WebDisk wieder :-)

    https://reboot.omsi-webdisk.de/community/

  • Rumpelhans,
    Hast du es mal getestet, wie sich Omsi verhält? Ich habe es noch nicht probiert, ob Omsi einen weiteren String auslesen kann. Nicht alles ist so offen, wie die Halte- oder Endstellenbefehle. Bei vielen Befehlen ist die Anzahl der auszulesenden String fest vorgegeben.

  • Naja SchulterSack, ich habe es wirklich nie ausprobiert. Bei den Enstellen- und Haltestellenbefehlen, kann ich im Script festlegen, weile Strings ausgelesen werden sollen. Für die global_strings fehlt mir eine veränderbare Variable. Deswegen frage ich nach, ob es überhaupt möglich ist.


    Inwiefern das einfacher als meine ursprüngliche Lösung sein soll, kann ich aber nicht nachvollziehen.


    Wenn ich mal eine Theorie dazu aufstellen darf?


    Ursprünglich sieht deine Idee, wie folgt aus:

    Zitat

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



    Dazu sollte folgender Gedankengang beachtet werden. Ich finde diese Idee immernoch absolut brilliant. Leider, und das bedaure ich sehr) hat sich diese Idee nicht so umgesetzt, wie ich es mir gewünscht habe. Und es gibt nur sehr wenige Busse, wo man die Art der Türsteuerung ganz einfach mit einem Mausklick verändern kann. Das ist nicht falsch, ich finde es aber immernoch besser, wenn die Hofdatei (eine universelle Hofdatei) die Art der Türsteuerung festlegt. Allerdings könnte ich auch mit meiner Meinung dazu, auf einer einsamen Insel sitzen.


    Wenn man also solch eine Idee umsetzt, ist es auch zwingend erforderlich, diese Befehle zu verwenden. Wenn man das System umstellt, dass die Befehle nicht in der Hofdatei stehen, sondern nur in den Busscripten, mag es für die Umstellung im Editor unübersichtlich werden, aber mit einem Programm wie die HofSuite könnte man auf die Befehl in der Hofdatei verzichten und nur die Zahlen schreiben. Zudem kann man in dem Programm HofSuite das ganze auf deutsch schreiben ohne die Befehle zu ändern. Später kann man HofSuite auf viele weitere Sprachen ändern, so das auch User damit umgehen können die kein Englisch können. Beispiel Russich.
    Die Frage, ob es sich lohnt HofSuite in andere Sprchen zu übersetzen, lasse ich mal unberücksichtigt.