Mod API Diskussion (weiterführung aus dem Beta News Beitrag)

Zwischenstand meiner internen Entwicklung:

Der Vorteil für Mods wird sein, das man komplett ohne require auskommen kann um die Komponenten zu nutzen.
Somit kann man Mods schreiben die Kompatibel sind aber nicht erst selbst irgendwie herausfinden müssen ob den CommonAPI geladen ist um dann ein require auszuführen,

Im Mod Code kann man dann einfach commonapi bzw eine Komponente per ~= nil testen.
if (commonapi ~= nil) then
-- Mehr Gleise und co

else
-- Normaler Code

end

Dies funktioniert auch wenn commonapi als letztes Mod geladen wird (solange UG nicht die Strings anders lädt, ja wieder mal ein Hack)

Die einfache Version dieses Loaders funktioniert, dh. commonapi.repos lädt die Repository Komponente, commonapi.uiparameter usw.
Die erweiterte Version des Loaders, der auch bestimmte API Versionen Laden soll ist nicht fertig, ob ich Ihn verwende ist auch noch nicht sicher, die Parameter Erstellung ist jetzt erst mal wichtiger.

Repositories:
Die Repositories geben nicht einfach die Daten wieder sondern eine Tabelle mit ID, Filename und Data.
Damit ist es einfacher die Daten zu Filtern und wieder in der Repository zu finden.

Die API der Repositories sehen zurzeit so aus:
getByName(filename)
getById(id)
getEntries()
getFilteredEntries(filter)

Die Filter sind wie Filefilter aufgebaut (d.h. Sie können kombiniert werden), diese Funktion wird dann durch die UI genutzt um Strassen bzw. Eisenbahnbrücken zu erhalten.

Bei den UIParameter für Gleise versuche ich gekapselte Version per Objekt anzubieten
D.h. man erhält ein Objekt mit Funktionen zu Erstellung der Parameter und deren Abfrage.
Der Parameter Key und Beschreibung kann dabei natürlich überschrieben werden, auch hier gibt es die Möglichkeit per Filter unerwünschte Daten auszufiltern.
(Für verschiedene Gleistypen in einem Objekt)

Sinn der ganzen Sache soll eine sehr einfache Handhabe in der updateFn und beim Parameter bauen sein.
Für Strassen/Gleise möchte ich damit auch die Tram bzw. Oberleitung einbeziehen.

Sollte UG doch noch UI Elemente wie DropDown Felder anbieten kann das Zentral geändert werden ohne wieder alle Mods anzupassen.

Mir macht noch immer die Ladereihenfolge von Konstruktionen und der anderen Komponenten wie Gleismaterial, Straßen und co. Probleme. M1, M2 usw. sehen nicht schön aus.
Ich hab dazu noch eine Idee über einen Cache d.h. man muss ggf. sein Savegame nochmalig laden.
Bis UG das dann endlich sinnvoll löst, aber solche Sachen dauern eben immer sehr lang oder kommen erst in einem neuen Spiel.

Soviel erst mal zum Zwischenstand der Entwicklung.

Ja, ich möchte eine Vorab Version veröffentlichen sobald ich etwas funktionierendes ohne grobe Fehler habe. Ich hab noch ne ganze Menge TODOs zu lösen.

Zum Cache habe ich noch keine Idee wie man das Savegame spezifisch machen kann, Ideen sind wie immer willkommen.
Ich hab mir den interne Taskmanager für Missionen angesehen, aber ohne Mission ist das alles recht nutzlos, außerdem ist das auch wieder zu spät. Da die Konstruktionen zu dieser Zeit schon geladen sind.

Mein altes System hatte eine Datei in mods Ordner wo der Nutzer die Gleis/Brücken Dateien angeben konnte und es gab eine sortierte Liste mit Default Werten.
Wenn es beim Bauen einen Type nicht gegeben hat wurde ein Fallbacktyp genutzt, der Rest war mit M1,M2 Buttons erreichbar. Aber das ist weder ModManager kompatibel noch nutzerfreundlich.

Das angedachte Cache System:

Lade Dateien, Nutzer klickt ein Konstruktion auf.
Die Repo Liste ist an dieser Stelle komplett und kann abgespeichert werden. Beim nächsten Laden wird diese als Basis für die UI genutzt.
Das zerstört aber immer die ID Zuordnungen der UI bei verschiedenen Savegames.

Status Report:

Ich hab eine Lösung um Dateien zu finden bevor die loadConstrunction durchlaufen, aber nach weiteren Test war dies schon wieder eine Sackgasse.
Grund hierfür, nur wenn ein Mod auch einen res/script Ordner hat wird dieser in package.searchpath registriert.
Gerade für Steam Mods benötige ich den kompletten Pfad zum Mod, ich hab die ganzen Lua Variablen abgesucht, auch die debug.luaregistry und finde leider die Pfade nicht.

Daher kann ich den Pfad nicht durchsuchen.

Ohne etwas einlenken von UG scheine ich da keine Plattform übergreifende Lösung zu finden.
Auch eine Lua Erweiterung ist aussichtslos, da die Lua Runtime in der Exe/bin steckt und die Lua Runtime nicht exportiert wird.

Auch wenn Ihr wegen Kompatibilität die Lade Reihenfolge nicht ändert, wäre es schön wenn es eine Info über alle Mods und deren Pfade liefern könntet. Und auch Lua LFS (LuaFileSystem) einbinden, dann kann ich mir die Infos per LUA Script selbst zusammenbauen. Diese Info könntet Ihr vielleicht im settings Parameter der RunFn übergeben, dann bräuchtet Ihr noch nicht mal eine neue Funktion oder Variable definieren.

Ja, es ist eine Shell Lösung da LUA eben keine Möglichkeit bietet einen Verzeichnis auszulesen. Opendir oder ähnliches kennt LUA eben nicht.
Mit den anderen LUA Routinen kann man auch genügend Schaden anrichten.

Ich möchte aber nicht alle Mods auslesen, sondern wirklich nur die aktiven Mods.

Hab schon viel zu viel Zeit darauf verbraten um die Fehler oder Designentscheidungen im Spiel zu umgehen.
somit ist das mein letzter Beitrag hier.

The English translation sounds horrible, so now English Versions too:

Yes, it's a shell solution. Lua has no built-in way to get a folder list. Opendir or something similar is not known by LUA.
With other lua functions you can create enough harm too.

I don't want to read all mods but only the active ones.

Did already spend to much time on TPF to avoid bugs and workaround design decisions, so this will be my last post.

-Old Post translation-
I got a solution to find files when loadConstruction haven't run yet. However it was a dead end after all.

As not all mods have res/scripts thus won't be registered in package.searchpath. For Steam Mods I need to resolve the whole path. I searched the complete LUA variables but found no evidence of the mods, so I can't search the mod path for ressource files.

Without some help of UG I can't seem to find a cross platform solution.

A lua extension can't be programmed because the lua runtime isn't exposed by the exe/bin (no export)

Ich sehe keinen Sinn drin eine halbgare Lösung anzubieten. Ich hab da zwar noch eine ganze Menge an Ideen wie man es trotzdem schafft. Aber wenn UG meint dann popen zu killen hab ich wieder Zeit für nichts verbraten.
Oder man findet alle Adressen der Lua Runtime Funktionen der exe/bin und kann Sie dann ansprechen von einer Lua Erweiterung.
Dabei wären aber alle Mac Nutzer außen vor und wenn UGs Compiler meint es müsse etwas inline machen, geht auch alles wieder kaputt.

Die andere Variante wäre alle Mod Autoren dazu zu bringen Ihre Mods anzupassen. Auch mit guten Argumenten hat so etwas damals nicht bei Cities in Motion funktioniert und ich werde es diesmal erst gar nicht versuchen.
Es gibt ja jetzt schon genügend Mods die Basisdateien überschreiben mit unangenehmen Auswirkungen, das scheint mir ein einziges Minenfeld.

Es wird eine Lib für meine eigenen Mods geben aber keine generelle Version, die wird dann auch Support beinhalten für Mods die ich selber nutze.

This means when you are lucky you get this feature in an update for the next version of Transport Fever.
(TPF3.0 + Some Update around 2018/2019) They put fixed IDs for Resources to the their TODO List around release date of Transport Fever. I gave up in trusting UGs work for such things. Look at the construction ui mess, how many updates did it take so at least the buttons are reachable?

Naja, große Engine bedeutet nicht besser (siehe CIM2, das war eine Katastrophe gegen CIM1).

Wie gesagt, ich hab meine Ideen ja hier geschrieben und suche mir ab jetzt einfach meine private Lösung wie auch für Cities Skylines.
Ich werde mich nicht weiter beteiligen...