Einstellungen für Mods

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Ein kurzes Tutorial zur Verwendung der neuen "Mod Einstellungen" im TPFMM.
    The English version can be found here: Settings for Mods

    Einleitung


    Mit hat es schon öfter gestört, dass man, wegen kleiner Anpassungen an die Vorlieben der Nutzer, zwei nur leicht verschiedene Mods oder einen Hauptmod mit Zusatzmods anbieten musste. Meine Lösung war ein einfaches Lua Script (settings.lua), das im Ordner des Mods liegt und alle Optionen in der Form Option = Wert enthält:

    Lua Source Code: settings.lua

    1. return {
    2. option1 = true,
    3. option2 = 4,
    4. }
    Diese Datei kann dann entweder direkt ausgelesen werden oder man nutzt die dafür vorgesehenen Funktionen meines ModUtil Scripts (einfach den Inhalt des angehängten Archivs in den Mod Ordner kopieren). Erstgenannte Variante ist etwas komplizierter und nur zu empfehlen, wenn man sich mit Lua auskennt. Daher werde ich hier auch nur die Variante mit dem ModUtil Script vorstellen.

    Optionen definieren


    Um den Mod Nutzern die Mühe zu sparen, die settings.lua selbst mit einem Texteditor zu bearbeiten, war @Xanos so freundlich dem TPFMM ein weiteres Fenster zu spendieren (eines großes Danke dafür :thumbup: ), in dem die Optionen grafisch dargestellt und bearbeitet werden können. Natürlich kann der TPFMM das aber nur leisten, wenn er die möglichen Optionen und deren erlaubte Werte kennt.
    Wir haben uns dazu entschlossen, die dafür nötigen Informationen aus der mod.lua auszulesen, dazu müssen sie dort aber erst definiert werden. Das geht über den Eintrag settings, zusätzlich zum Eintrag info, wo man beliebig viele Optionen definieren kann:

    Lua Source Code: mod.lua

    1. function data()
    2. return {
    3. info = {
    4. -- ...
    5. },
    6. settings = { -- optionen },
    7. }
    8. end
    Jede Option wird dann durch verschiedene Parameter bestimmt:

    Lua Source Code

    1. option1 = { -- interne ID der Option, mit der sie später ausgelesen werden kann
    2. type = "number", -- "boolean", "number", "string", "table" (Seit TPFMM Version 1.0.32)
    3. name = _("Option1"), -- Name der im TPFMM für diese Option angezeigt wird (kann mit der strings.lua übersetzt werden)
    4. -- optionale Parameter
    5. description = _(""), -- genauere Beschreibung was diese Option beeeinflusst, wird im TPFMM als Tooltip angezeigt
    6. default = 0, -- Standardwert, wenn nicht angegeben, wird für "boolean" false, für "number" 0, für "string" "" und für "table" {} genutzt
    7. min = -2147483647,
    8. max = 2147483648, -- minimal und maximal möglicher Wert (nur bei "number")
    9. values = { -- mögliche Werte für die Mehrfachauswahl (nur bei "table")
    10. {
    11. text = _("this is a 100"), -- Text der im TPFMM für diese Option angezeigt wird
    12. value = 100, -- Wert, der in die Tabelle geschrieben wird, wenn diese Option ausgewählt wurde
    13. },
    14. },
    15. },
    Display All
    Die ID der Option sollte innerhalb des Mods einzigartig sein. Anders gesagt, wird immer nur die zuletzt definierte Option, mit dieser ID, verwendet.
    Sofern nicht anders angegeben, stellen bei den optionalen Parametern, die in diesem Bespiel genutzten Werte, auch die Standarwerte dar, falls dieser Parameter fehlt.

    Wird das ModUtil Script verwendet, ist es sinnvoll die Optionen erst in einer Variable zu speichern damit diese dann sowohl für den TPFMM als auch für das Script verwendet werden kann:

    Lua Source Code: mod.lua

    1. local modUtil = require "merk_modutil_1"
    2. local settings_def = {
    3. option1 = {
    4. type = "boolean",
    5. name = _("Option1"),
    6. },
    7. option2 = {
    8. type = "number",
    9. name = _("Option2"),
    10. },
    11. }
    12. function data()
    13. return {
    14. info = {
    15. -- ...
    16. },
    17. settings = settings_def,
    18. runFn = function(settings)
    19. modUtil.userSettings.create("mod_id", settings_def)
    20. end
    21. }
    22. end
    Display All
    Mit der Zeile modUtil.userSettings.create("mod_id", settings_def) wird dem Script mitgeteilt, welche Optionen erwartet werden. Außerdem werden automatisch die settings.lua des Mods ausgelesen (sofern vorhanden) und die dort angegeben Werte für die spätere Verwendung gespeichert. Die "mod_id" wird intern genutzt, um zu unterscheiden, von welchem Mod die Einstellungen stammen. Zwei unterschiedliche Mods sollten also nicht die gleiche ID haben. Meiner Meinung nach bietet sich daher der Ordnername des Mods an.

    Optionen auslesen


    Nachdem das Script die settings.lua ausgelesen hat, kann jederzeit auf die Werte der Optionen zugegriffen werden und zwar in jeder beliebigen Scriptdatei (runFn der mod.lua, .con, .mdl, .msh, etc.). Wenn man direkt nach der Definition darauf zugreifen möchte (also noch in der runFn der mod.lua), empfehle ich folgenden Code:

    Lua Source Code

    1. local options = modUtil.userSettings.get("mod_id")
    In allen anderen Dateien ist folgender Code sinnvoller (damit man nicht jedes mal das ModUtil Script einbinden muss):

    Lua Source Code

    1. if merk_modutil and merk_modutil[1] then
    2. local options = merk_modutil[1].userSettings.get("mod_id")
    3. -- Einstellungen verarbeiten
    4. end
    "mod_id" bestimmt in beiden Fällen von welchem Mod man die Einstellungen haben möchte. Im Normalfall wird es also die gleiche ID wie bei "create" sein, man kann aber auch die Einstellungen eines anderen Mods auslesen (z.B. wenn der eigene diesen nur ergänzt und daher auch zum Teil die gleichen Optionen nutzt). Der Zugriff auf die einzelnen Optionen funktioniert ebenfalls in beiden Fällen identisch, z.B. mit options.option1.
    Files
    • modutil.zip

      (4.31 kB, downloaded 380 times, last: )

    4,466 times viewed

Comments 16

  • SD70M -

    @Merk Ist es mit dem ModUtil auch möglich Multiple-Units auszublenden?

    (Mir ist bisher nur die Funktion modUtil.vehicles.hideObject("vehicle/.../xy.mdl") bekannt, welche direkt im models-Ordner startet)

    • MaikC -

      Das kann ich beantworten da ich das gleiche auch schon gefragt hatte. Grundsätzlich sollte es möglich sein aber aufgrund eines kleinen Bugs im Script geht es noch nicht.

    • Yoshi -

      Der Umweg über einen eigenen Filefilter geht auf jeden Fall. So wird es z.b. bei der BR 423 realisiert.

  • Gordon Dry -

    Nun, ich habe massig Mods, die in der mod.lua in der ersten Zeile das haben:
    local modUtil = require "merk_modutil_1"
    und die auch im Unterordner die Datei res\scripts\merk_modutil_1.lua haben und trotzdem allesamt in der stdout.txt dies ausspucken:
    [ModUtil|UserSettings] Could not read settings file ...

    Was ist da los?

    • Gordon Dry -

      Das sind sie:

      [ModUtil|UserSettings] Could not read settings file "mods/grimes_v200_1/mod.lua".
      [ModUtil|UserSettings] Could not read settings file "mods/grimes_einheitskesselwagen_1/mod.lua".
      [ModUtil|UserSettings] Could not read settings file "mods/grimes_ggthsbromberg_1/mod.lua".
      [ModUtil|UserSettings] Could not read settings file "mods/grimes_v60_1/mod.lua".
      [ModUtil|UserSettings] Could not read settings file "mods/maikc_br442_basis_1/mod.lua".
      [ModUtil|UserSettings] Could not read settings file "mods/bbb_218_1/mod.lua".
      [ModUtil|UserSettings] Could not read settings file "mods/grimes_vt175_1/mod.lua".
      [ModUtil|UserSettings] Could not read settings file "mods/grimes_hecht_1/mod.lua".
      [ModUtil|UserSettings] Could not read settings file "mods/merk_4yg_1/mod.lua".
      [ModUtil|UserSettings] Could not read settings file "mods/grimes_silberlinge_1/mod.lua".
      [ModUtil|UserSettings] Could not read settings file "mods/emny_coradia_a_ter_db_br_641_1/mod.lua".

    • Merk -

      Das heißt wahrscheinlich einfach nur, dass du noch keine Einstellungen geändert hast und die settings.lua (nicht mod.lua wie in den Meldungen) daher nicht vorhanden ist. Hat keine Auswirkungen, außer das die Standardeinstellungen genutzt werden.

  • homieforever -

    Kleine Info (vielleicht ein Nachtrag wert). Geht man nach dem Eintrag hier vor (wie ich gestern) bekommt man am ende eine Fehlermeldung und denkt sich erstmal mhm wasn da los, ich war zu schnell beim Kopieren und einfügen und da ist ne kleine Unstimmigkeit wenn man es eben kopiert. Unszwar wird hier im Beispiel die mod util über diesen Befehl eingebunden:

    local modUtil = require "merk_modutil_1"

    und weiter unten unter Optionen auslesen wird dann auf mod_util zugegriffen was so dann natürlich nicht vorhanden ist da unter modUtil geladen. Ist jetzt zwar kein wirklicher Fehler an sich aber für leute die eh nicht so viel Ahnung von LUA haben denke ich dennoch hilfreich :)

    • Merk -

      Habs korrigiert, das kommt davon, wenn man die Sachen aus unterschiedlichen Dateien zusammenkopiert. ;)

  • Freahk -

    Tolle Sache.
    Das wird dann wohl meine Settings.lua ersetzen und die Mod direkt über den TPFMM konfigurierbar machen.

    In der Settings.lua gebe ich allerdings bisher unter anderem die Straßentypen an die im UI auftauchen sollen.

    Es wäre super wenn man die types die das Script kennt noch um enums, also einer Auflistung der erlaubten Werte, ergänzen könnte.
    Wenn TPFMM dann noch gewisse Auflistungen vordefinieren könnte, wie z.B. die Liste aller geladenen Gleis-/Straßennamen wäre das genial.

    • Merk -

      Welche Straßen und Gleise verfügbar sind, kann der MM doch gar nicht wissen, oder verstehe ich da was falsch?
      Bezüglich Enum muss ich mich mal mit Xanos unterhalten. Soll denn immer nur ein Wert auswählbar sein, oder beliebig viele?

    • Freahk -

      Ich habe keine Ahnung ob der MM das weiß.
      Theoretisch könnte er das wissen, da er ja weiß welche Mods aktiviert sind und er wissen dürfte welche Dateien die Mods enthalten.
      Straßen liegen immer in res/config/street und Gleise in res/config/track bzw. deren Unterordnern.

      Mehrere Werte wären praktisch. Ansonsten tut es aber auch ein Wert, dann muss ich eben für jeden Button eine eigene Option machen.

    • Merk -

      Also für eine Option bestimmte Werte vorzugeben, wird auf jeden Fall eingebaut. Ob auch eine Mehrfachauswahl möglich ist, steht noch nicht fest, da man das eigentlich auch über eine Reihe von Bool Eingaben lösen könnte.
      Zu den vordefinierten Listen: Der MM weiß bestenfalls welche Mods installiert sind, aber keinesfalls welche aktiviert sind. Und bezüglich des Nutzens einer Liste aller installierten Gleise und Co., habe ich doch so meine Zweifel.

    • Freahk -

      Eine Liste aller installierten Straßen/Gleise würde ja auch schon reichen.
      Nun ich werde dann wohl weiterhin im UI M1, M2, M3, M4 bei der Auswahl des Gleistypen im Depot anzeigen und dahinter die ersten 4 geladenen Mod Gleise verstecken, anstatt den Namen des Gleises dort anzuzeigen.
      Praktisch dind die Einstellungen aber trotzdem. Helfen mir dann nur in diesem einen Fall nicht wirklich weiter.

  • bayernbubi -

    Ich verstehe nur Bahnhof. Kann mir das jemand mal etwas einfacher erklären? Sorry!!!

    • Merk -

      Hast du vor einen Mod zu erstellen? Denn dafür war der Eintrag hauptsächlich gedacht. Um als Nutzer die Einstellungen vorzunehmen, ist der TPFMM die beste Wahl.

    • bayernbubi -

      Ahhh OK, jetzt hab ich verstanden!!! Vielen Dank!!!