Brauchen wir eine bessere Skript-Modding-API?

Willkommen in der Transport Fever Community

Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.

 

Die Registrierung und Nutzung ist selbstverständlich kostenlos.

 

Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.

Das Team der Transport-Fever Community


  • ich habe mich in letzter Zeit ein wenig mit Bahnhof-Mods beschäftigt und mir sind dabei ein paar grundsätzliche Probleme aufgefallen, die ich gerne lösen würde

    • Kompatibilität zwischen Mods: Skript-Mods überschreiben entweder einzelne Funktionen oder ganze Dateien. Wenn zwei Mods die gleiche Funktion überschreiben, geht eine Änderung verloren, obwohl die beiden Mods prinzipiell kompatibel sein könnten.
      Viele Modder lagern deswegen ihre Funktionalität in separate Objekte aus, was aber schade ist, weil es durchaus erwünscht sein kann, verschiedene Mods zu kombinieren (z.B. gebogene Bahnhöfe mit mehr Gleisen und Geschwindigkeitsbegrenzungen - 3 verschiedene Mods)
    • keine Standardmethoden: es gibt häufig wiederkehrende Aufgaben, die jeder Modder selbst lösen muss, z.B. Optionen im Baumenü hinzufügen/verändern. Eine erweiterte Modding-API würde Entwicklungsaufwand sparen, Kompatibilität zwischen Mods erhöhen und Standardaufgaben robust und sicher lösen.
    • Ladereihenfolge: beim Laden von Mods gilt first come first serve, und das obwohl es im Spiel nicht mal eine einfache Möglichkeit gibt, die Ladereihenfolge von Mods zu verändern. Das Problem mit der Ladereihenfolge auf den einzelnen Anwender auszulagern halte ich nicht für sinnvoll.
    • Lokale Funktionen: Etliche Funktionen in den Lua-Skripten von TpF sind als lokal deklariert. Das bedeutet, dass man für kleinste Änderungen oft hunderte Zeilen Code kopieren muss und damit das Kompatibilitätsproblem noch verschärft.

    welche Anforderungen sollte eine erweiterte Modding API erfüllen?

    • 100% Kompatibilität mit allen Mods, die nicht die erweiterte API benutzen wollen (sonst macht man nur den Code von Anderen kaputt und die sind dann berechtigterweise sauer)
    • Standardmethoden, um alle bestehenden Funktionen (auch lokale Funktionen) beliebig oft zu erweitern (nicht einfach überschreiben)
    • die Reihenfolge, in der Erweiterungen definiert werden, kann für jede Funktion neu bestimmt werden und wird im Code der Mod festgelegt (unabhängig von der Ladereihenfolge im Spiel)
    • eine kleine Standardbibliothek, die robuste Lösungen für häufig verwendete Aufgaben anbietet
    • umfassende und verständliche Dokumentation für Modder, mit Codebeispielen

    über die Umsetzbarkeit habe ich mir schon einige Gedanken gemacht und ich glaube, dass es machbar wäre, eine Modding API zu bauen, die diesen Ansprüchen genügt.


    Was mich aber jetzt interessieren würde: Was haltet ihr überhaupt von der Idee? Würdet ihr als Modder eine solche API nutzen? Welche Features vermisst ihr, welche möchtet ihr auf keinen Fall haben? Brauchen wir sowas überhaupt?

  • Das Problem kenne ich, aber in diesem Fall haben wir genau 0 Standards.
    Ob dieser Vorschlag hier der eine Standard wird, ist mir relativ egal. Ich bitte hier um Input, damit wir schon in der Designphase möglichst viele Probleme berücksichtigen, aber jeder der möchte kann natürlich weiter sein eigenes Ding machen. Ein paar der beschriebenen Probleme kann man einzelner Modder nicht lösen (insb. das Kompatibilitätsproblem), allein schon deshalb wäre es vielleicht sinnvoll, überhaupt mal ein Framework zu definieren.

  • Eine brauchbare, vor allem gut dokumentierte API sehe ich grundsätzlich als nützlich an. Auch könnten hierdurch Fehler und Inkompatibilitäten vermieden werden.


    Jedoch ist es überhaupt nicht notwendig eine solche API zu haben, um eben diese Dinge zu vermeiden. Dies liegt einzig beim Modder.
    Arbeitet der Modder sauber, so ist sein Mod IMMER kompatibel zu:

    • Savegames
    • anderen Mods

    Gegenseitiges Code-Überschreiben z.B. gehört nicht zum sauberen arbeiten. Da nützt auch keine API etwas, wenn derartige Basics vom Modder nicht bedacht werden.


    LG Enno :)

    Auch ein alter Fuchs schaut gern ein Huhn, selbst wenn er's nicht mehr Reißen kann. ^^

    163393-cpuz-ryzen9-5900-png

  • Gegenseitiges Code-Überschreiben z.B. gehört nicht zum sauberen arbeiten. Da nützt auch keine API etwas, wenn derartige Basics vom Modder nicht bedacht werden.

    Hmm, das wäre mir neu, ehrlich gesagt. Ein Beispiel aus der Bahnhofswelt (da kenne ich mich momentan am besten aus):

    • Mod A will alle Vanilla-Bahnhöfe so anpassen, dass mehr Bahnsteige gebaut werden können und überschreibt zu dem Zweck die Funktion paramsutil.makeTrainStationParams.
    • Mod B will ebenfalls die Vanilla-Bahnhöfe so anpassen, dass eine Höchstgeschwindigkeit im Bahnhofsbereich definiert werden kann und überschreibt zu dem Zweck die Funktion paramsutil.makeTrainStationParams.

    Wie lösen das die Modder jetzt, ohne ein gemeinsames Framework zu verwenden?

    • Sie können einen eigenen Bahnhof erstellen, dann kann man aber keinen Bahnhof haben, der mehr Bahnsteige und das Geschwindigkeitslimit gleichzeitig hat
    • Sie können eine darauf folgende Funktion überschreiben, z.B. railstationconfigutil.makeTrainStationConfig, aber auch hier ist die Anzahl der verfügbaren Funktionen stark begrenzt und eine Koordination ist trotzdem nötig

    Wie würdest du das lösen?

  • aber in diesem Fall haben wir genau 0 Standards.

    Doch, nämlich die Mindestmenge der benötigten Elemente, die nötig sind damit TpF eine Mod als funktionierenden Bahnhof akzeptiert.

    damit wir schon in der Designphase möglichst viele Probleme berücksichtigen

    Wie lang soll das dauern? Wann kennen wir alle bzw. die meisten Probleme? Wann sollen die ersten Mods erscheinen?

    insb. das Kompatibilitätsproblem

    Das hat man aber nur, wenn man ein "one to rule them all" macht.

    deshalb wäre es vielleicht sinnvoll, überhaupt mal ein Framework zu definieren.

    Hmm - schwierig. Ich weiß heute noch nicht, was ich oder Kollegen, die mein Script verwenden, morgen brauchen und wie ich es dann implementieren werde.
    Ich bevorzuge da agile Entwicklung...


    Edith zum letzten Post direkt oben drüber:


    Wie würdest du das lösen?

    Ich habe es für mich entschieden, in dem ich nach meinen ersten Mods den Beschluß gefasst habe,
    die Finger von dem UG-Code zu lassen. Er erfüllt in keinster Weise die von dir genannten Ansprüche...

  • @Tom deine Argumente kann ich allesamt verstehen. Es ist völlig klar, dass wir nicht jedes Problem mit einem Framework lösen können und ich sehe auch ein, dass es Leute gibt, die sich mit dem aktuellen Stand ganz wohl fühlen.


    Aber du bietest auch keine Lösungen für die oben beschriebenen Probleme an. Beim Kompatibilitätsproblem geht es nicht um "one to rule them all", sondern um die Frage, warum ich nur Feature A oder B oder C nutzen kann, aber nicht alle zusammen, und der einzige Grund der dagegen spricht ist dass wir es als Entwickler untereinander nicht koordiniert bekommen. Wieso also gar nicht erst den Versuch wagen, das Problem zu lösen?


    Ich habe es für mich entschieden, in dem ich nach meinen ersten Mods den Beschluß gefasst habe,die Finger von dem UG-Code zu lassen. Er erfüllt in keinster Weise die von dir genannten Ansprüche...

    es geht mir auch nicht um UG-Code vs. Eigenentwicklung. Wäre es nicht praktisch, wenn die Höchstgeschwindigkeits-Mod auch mit deinen Bahnhöfen funktionieren würde? Ohne dass du irgendwas an deinen Mods anpassen musst? Das meine ich mit Kompatibilität.

  • Wie würdest du das lösen?

    In dem erwähnten Beispiel mit den Vanilla-Bahnhöfen wäre für mich die Sache klar:
    Ich überschreibe keine Vanilla-Bahnhöfe! Niemals nicht!

    • Es kann immer sein, dass UG Änderungen vornimmt, welche zu Problemen mit meinem Code führen.
    • Andere Modder machen eventuell den gleichen Unsinn und verändern Vanilla-Bahnhöfe. Hier sind Probleme vorprogrammiert.

    Möchte ich die Funktionalität der Vanilla-Bahnhöfe erweitern/ändern, so erschaffe ich neue Bahnhöfe aus besagten Bahnöfen. Alle notwendigen Skript-Änderungen erfolgen in eigenen Dateien und völlig separat von Vanilla-Skripten.
    Dies ist übrigens auch der Weg, welchen @Tom geht und so diese Inkompatibilitäten vermeidet.


    LG Enno :)

    Auch ein alter Fuchs schaut gern ein Huhn, selbst wenn er's nicht mehr Reißen kann. ^^

    163393-cpuz-ryzen9-5900-png

  • sondern um die Frage, warum ich nur Feature A oder B oder C nutzen kann, aber nicht alle zusammen

    Wenn man mit dem UG-Code rum frickelt, bleibt es nicht aus. Er ist nicht für eine flexible Wiederverwendung konzipiert.

    Aber du bietest auch keine Lösungen für die oben beschriebenen Probleme an.

    Doch. Mein Script wird laufend um neue Möglichkeiten erweitert, die zusammen genutzt werden können.
    Was momentan die Sache etwas einschränkt, ist die bekloppte UI.

    Wieso also gar nicht erst den Versuch wagen, das Problem zu lösen?

    Mach ich doch...


    Tante Edith zu @Klamanns Edit:


    wenn die Höchstgeschwindigkeits-Mod auch mit deinen Bahnhöfen funktionieren würde?

    Was macht den diese Mod? Kenne sie nicht...

  • @Tom Nur damit wir uns richtig verstehen: Ich bin ein Fan von deinen Bahnhof-Mods und habe Respekt für die Arbeit, die du da reinsteckst.


    Deine Lösung ist, möglichst alles in deine Mods zu integrieren, was man so braucht. Jetzt haben wir aber eine Menge großartiger Mods, wie sloped stations und die gebogenen Bahnhöfe, die verdammt schwer zu implementieren sind und die du nicht einfach so übernehmen kannst. Die werden also nie mit deinen Bahnhöfen zusammenarbeiten können, obwohl es technisch kein Problem wäre, weil die genannten Mods nichts neues definieren, sondern nur bestehende Strukturen transformieren.


    Vielleicht gefallen dir die genannten Mods sowieso nicht und überhaupt willst du nur alleine entscheiden, was auf deinen Bahnhöfen geschieht - ist in Ordnung, kein Problem.
    Aber auf einer abstrakteren Ebene: Wir haben mittlerweile ein paar sehr generische Lösungen für recht komplexe Probleme und es ist weder sinnvoll, noch nötig diese Funktionalität in jeder einzelnen Mod nachzuimplementieren. Warum nicht die Mods so bauen, dass sie grundsätzlich mit anderen kombiniert werden können? Und das ganz unabhängig von den Bahnhof-Beispielen, über die wir hier reden. Es gibt noch viele andere Stellen, an denen man sehr nützliche Funktionen problemlos miteinander kombinieren könnte, wenn es denn die technischen Voraussetzungen dafür gäbe. Daran würde ich gerne arbeiten.

  • @Klamann, über geneigte Bahnhöfe kann man streiten. Ich bin da wie das Vorbild kein Fan von.
    Das Biegen von Bahnhöfen wird bei mir auch möglich sein - wenn es bei einem Bahnhof Sinn macht.

    Wir haben mittlerweile ein paar sehr generische Lösungen für recht komplexe Probleme und es ist weder sinnvoll, noch nötig diese Funktionalität in jeder einzelnen Mod nachzuimplementieren.

    Da haben wir ganz unterschiedliche Meinungen und daraus resultierende Ansätze.
    Ich mag das 0815-Schema der "Standard"-Bahnhöfe nicht. Ich mag Abwechslung.
    Für mich ist jeder Bahnhof, den ein Kollege mit meiner Hilfe bauen möchte, ein Unikat.
    Das fängt schon bei den Lanes an und hört bei der Gleis-/Bahnsteig-/Gebäudeanordnungen auf.
    Und das ist mit dem UG-Ansatz nicht zu machen.


    Außerdem muss auch nicht jede einzelne Mod da etwas nach implementieren.
    Der Modder muss nur auf die entsprechende Version meines Scripts gehen und sein con-Datei entsprechend anpassen.
    Schon kann er alles nutzen, was diese Version bietet...


    Und schon wieder Tante Edith zu dieser Hochgeschwindigkeits-Mod:


    Im Thread dort:


    Zitat von Atomic Dad


    Hey BR84.
    Wenn ich deine Mod aktiviert habe, dann sind meine Bahnhöfe bereits im Jahr 1850 elektrifiziert. Es ist keine Änderung möglich, da es noch kein
    Upgrade für Schienen zu der Zeit gibt. Auch kann ich beim Bahnhofsupgrade nichts an den Oberleitungen ändern.


    Jetzt die Frage. Wo liegt der Fehler?

    Scheint also mit meinen Bahnhöfen zu funktionieren, denn jetzt weiß ich wenigstens, warum ein Spieler sich bei meinen Bahnhöfen über die nicht änderbare
    Elektrifizierung im Jahr 1850 ausließ und das Scheiße bei meinen Bahnhöfen fand.


    Ich habe keinen Bock auf mich treffende Shitstorms, die ich nicht selber auslöse...

  • Haven't fully read the topic, but you can make suggestion to [email protected]


    Personally I did two proposal last months, better size control on param panel and more informatios needs in "params" variables for updateFn (you can have a look into params by using datadumper, there are some environement variables, I suggest they put more thing like the edge info around the cursor)


    xkcd.com/927/


    Lol, make me recall the evolution of ETCS/ERTMS!


    Local functions: a number of capabilities in the Lua scripts of TpF are declared as local. This means that you must copy for small changes often hundreds lines of code and thus exacerbated the compatibility issue.

    This is performance issue of Lua, local is much faster than global.


    That's why I made a lib of my own: I have control over everything. Unfortunately this made me each update is for all mods..


    In fact the thing could be done in this way:


    You have seen in mod.lua you have hooks, but the effect are global.


    I don't know if for UG it's possible to make is effect local, if it's possible, let them add a hook of function! :D


    I think your proposal means to add hooks in framework functions so a mod overrides callbacks instead of the function(well, callbacks are themselves functions), the problem for them is where to place them...and so they need to make a standard process for construct everything... The problem is, the capacity of vanilla script is very limited..


    And the de-facto standard for modder is Tom's script.

    This guy is too lazy to create a signature. 8o

BlueBrixx