The English version can be found here: Mod Settings (Modder)
1 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:
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.
2 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 ), 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:
Jede Option wird dann durch verschiedene Parameter bestimmt:
option1 = { -- interne ID der Option, mit der sie später ausgelesen werden kann
type = "number", -- "boolean", "number", "string", "table" (Seit TPFMM Version 1.0.32)
name = _("Option1"), -- Name der im TPFMM für diese Option angezeigt wird (kann mit der strings.lua übersetzt werden)
-- optionale Parameter
description = _(""), -- genauere Beschreibung was diese Option beeeinflusst, wird im TPFMM als Tooltip angezeigt
default = 0, -- Standardwert, wenn nicht angegeben, wird für "boolean" false, für "number" 0, für "string" "" und für "table" {} genutzt
min = -2147483647,
max = 2147483648, -- minimal und maximal möglicher Wert (nur bei "number")
values = { -- mögliche Werte für die Mehrfachauswahl (nur bei "table")
{
text = _("this is a 100"), -- Text der im TPFMM für diese Option angezeigt wird
value = 100, -- Wert, der in die Tabelle geschrieben wird, wenn diese Option ausgewählt wurde
},
},
},
Display More
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:
local modUtil = require "merk_modutil_1"
local settings_def = {
option1 = {
type = "boolean",
name = _("Option1"),
},
option2 = {
type = "number",
name = _("Option2"),
},
}
function data()
return {
info = {
-- ...
},
settings = settings_def,
runFn = function(settings)
modUtil.userSettings.create("mod_id", settings_def)
end
}
end
Display More
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.
3 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:
In allen anderen Dateien ist folgender Code sinnvoller (damit man nicht jedes mal das ModUtil Script einbinden muss):
if merk_modutil and merk_modutil[1] then
local options = merk_modutil[1].userSettings.get("mod_id")
-- Einstellungen verarbeiten
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.
Comments 1
Newly created comments need to be manually approved before publication, other users cannot see this comment until it has been approved.
Newly created comments need to be manually approved before publication, other users cannot see this comment until it has been approved.
VacuumTube
Wie hier schon geschrieben habe (CommonAPI2), wäre es nützlich, wenn Änderungen von Mod Einstellungen über die GUI der CommonApi im laufenden Spiel direkt von den Mods erfasst werden könnten. Dazu ist wahrscheinlich eine Art Interface notwendig.
Konzeptidee:
Momentan werden ja die Einstellungen einmal beim Laden des Spiels von settings.lua eingelesen und gespeichert. Da manche Mods möglicherweise sehr oft die Einstellungen mit local options = merk_modutil[1].userSettings.get("mod_id") aufrufen, wäre es wahrscheinlich ineffizient, jedes Mal die Datei auszulesen. Daher sollte die CommonApi beim Ändern eines Wertes dieses modutil informieren, sodass die geänderten Einstellungen erkannt und aktualisiert werden. Rufen Mods danach wieder ihre Einstellungen ab, erhalten sie die neuen Werte.