Modding - Einsteigerfragen

Ich weiß nicht genau was du vorhast.. Es klingt als würdest du Modelle via Konstruktion ins Spiel bringen wollen.

Lua und Scriptmodding decken ja aber noch viel mehr ab. Wie du gemerkt hast, gibt es dafür keine wirklichen Tutorials. Das muss man sich größtenteils durch andere Mods und Trial and Error erlernen. Das wiki ist dennoch ein guter Startpunkt, weil es eine gute Übersicht über die Modding Möglichkeiten gibt.

Vielen hilft es, in andere Mods zu schauen und an Beispielen zu lernen. Such dir einfach Mods raus, die du schon benutzt und verstehe, wie die funktionieren. Hier gibt es allerdings das Dilemma, dass kleinere Script Teile von Moddern, die wenig mit Lua machen, manchmal unnötig kompliziert sind und so manchmal die Fehler von anderen kopiert werden - auf der anderen Seite sind umfassendere Script Mods oft schwer für Einsteiger zu durchblicken, weil Script Modder den Code mit eigenen Funktionen optimieren (was langfristig den Code besser macht).

Zum Lua lernen: https://www.lua.org/pil/contents.html

Lua hat seine Eigenarten und ist manchmal etwas umständlich, aber wenn man damit klarkommt, ist es gar nicht schwer. Grundprinzip: alles ist eine Table, also eine Art dict, was Lua aber auch als Array nutzt.

Der ParamBuilder ist ein Interface für Parameterdefintionen und die Ermittlung vom ausgewählten Wert in der updateFn. Man sollte schon wissen wie Parameter funktionieren: https://www.transportfever2.co…ding:constructionbasics&s[]=parameter

Man kann damit die interne Darstellung als Integer umgehen und direkt die Werte nutzen um die es eigentlichen geht (Strings, Dateinamen, ...)

Texturen auswählbar heißt mehrere Modelle, schätze ich. Skalierung ist eines der meist gemachten Dinge, daher schau einfach wie andere Mods das machen. Manche beschreiben die Transf Matrix direkt; der saubere Weg ist, die Scale Funktion der transf.lua zu benutzen.

Das Modding-Wiki ist knapp aber gerade eben so ausreichend - man muß aber mehrmals lesen und dahinterkriechen, was die Leute meinen. Wichtig ist erst einmal, daß Du verstehst, wie die einzelnen Komponenten einer Mod zusammenarbeiten:

- Die "Steuerzentrale" ist meist die .con-Datei. Das Spiel klappert anfangs alle Mods ab und sammelt (u. a.) alle .con-Dateien. In der .con gibt es die Funktion data(), die bei dieser Gelegenheit ausgeführt wird. Dort definierst Du allerhand Daten für die Mod, die Parameter und eine updateFn, die jedes Mal ausgeführt wird, wenn ein Modell am Mauszeiger hängend angezeigt werden soll oder tatsächlich gebaut oder modifiziert wird. In dieser werden die Modelle hingestellt.

Die Modelle werden in der .mdl-Datei definiert, und diese greift für das Mesh auf die .msh und .msh.blob zu, sowie für die Textur auf die .mtl-Dateien, in ihren jeweiligen Ordnern unterhalb von res/model.

Die .mtl-Datei greift wieder auf die Texturen zu.

Dann gibt es noch die mod.lua, die notwendig ist, meistens aber nur allgemeine Daten liefert (mit der runFn und der postRunFn kann man auch mehr machen, aber das ist für Fortgeschrittene - versuche am Anfang nicht die Mods zu untersuchen, die damit herumspielen).

Für die Lokalisierung (=Übersetzungen) gibt es noch die strings.lua. An Deiner Stelle würde ich sie gleich anlegen, sonst jagst Du dauern irgendwelchen noch nicht übersetzten Strings hinterher. Die Anwendung ist einfach: Jeder String, der irgendwie im Spiel angezeigt werden soll, wird in der .con (oder wo er sonst aufgerufen wird) in _() eingepackt, also z. B. _("adfasd"). Wenn dieser String in strings.lua unter der vom Spieler eingestellten Sprache zu finden ist, wird die Übersetzung angezeigt, sonst der String.

Mit

en = {
adfasd = "Intelligent Example",
},
de = {
adfasd = "Intelligentes Beispiel",
},

bekommst Du auf Englisch "Intelligent Example", auf Deutsch "Intelligentes Beispiel" und auf Hebräisch oder Französisch "adfasd" im Spiel angezeigt.

Vom CommonAPI würde ich für den Anfang auch die Finger lassen, selbst wenn das Teil nützlich ist. Der ParamBuilder ersetzt das manuelle Füllen der Parameter-Struktur in der .con durch einen Funktionsaufruf mit gleich vielen Parametern. Bei der ersten Mod ist es besser, das zunächst zu Fuß zu probieren, damit Du ein Gefühl dafür bekommst, was der ParamBuilder machen soll. Ob Du ihn dann hinterher benutzt, ist Deine Sache.

Die "Typenlosigkeit", bzw. auf neudeutsch duck typing, ist mir auch ein Graus. Der Programmierer spart sich ein Wort und jeder, der den Code benutzen will, muß sich durch -zig Dateien und tausende Zeilen wühlen, bis er weiß, was wirklich in ein Funktionsargument geschrieben wird. Aber das ist in Python auch nicht besser. Da braucht es keinen Obfuscated Code Contest mehr, das ist schon eingebaut.

Große c++ Projekte außerhalb bestehenden APIs sind auch nicht besser.

LUA ist aber im Gegensatz zu anderen Sprachen extra kompakt und einfach aufgebaut.

Zu beachten gilt noch, bzw. Stolpersteine von anderen Sprachen:

LUA Array Index beginnt bei 1.

Da TPF2 aber in C++ geschrieben ist, nutzt es halt 0, zum Beispiel bei API aufrufen oder wenn du zum Beispiel terminals baust.

LUA Tabellen sind immer Referenzen. (ggf. bei komplexen Code wichtig, in seltenen Fällen braucht man ein deepcopy)

Man muss sich entscheiden, wenn eine Tabelle ein Array sein soll, müssen die Keys 1..x fortlaufend sein. (ipairs läuft sonst nicht!)

Man kann beides in eine LUA Tabelle stecken, da rate ich aber von ab.

Dateinamen Plattformunabhängig gestalten:

Daher keine Unicodezeichen oder Umlaute in Dateinamen verwenden und Groß und Kleinschreibung beachten. Linux, Mac Nutzer werden es dir danken.

Um die Fehlersuche zu erleichtern, Dateinamen so gestalten, das man dich als Entwickler wieder finden kann. Damit vermeidet man dann auch Probleme von gleichen Dateinamen in verschiedenen Mods.