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

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Gearbest Tablet-PC Promotion promotion
    • Aus Gründen der Abwärtskompatibilität würde ich einfach wie gewohnt die params speichern und zusätzlich in einer anderen table die data.
      Man muss die data table nicht nutzen, aber sie kann hilfreich sein. Die params muss man so oder so mit speichern, ansonsten müsste man aus data den Zustand der UI rekonstruieren.

      Die Möglichkeit für Teilbereiche einer Konstruktion eine eigene UI zu definieren wäre natürlich noch viel besser, das stimmt wohl. Vermutlich aber auch noch viel aufwändiger.
      Ein UI flag für die models wäre mit Sicherheit auch eine einfache und effektive Lösung.
      Dieser Beitrag wurde bereits ∞ mal editiert, zuletzt von Freahk (Vor π Minuten)
      mediziner, Merk, Darth Vader, Stepke, eis_os, tomdotio, mikael, weberba, Freahk, Gott und 42 weiteren gefällt das.
    • 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.
    • eis_os schrieb:

      Ich hab dazu noch eine Idee über einen Cache d.h. man muss ggf. sein Savegame nochmalig laden.
      jap, das funktioniert.
      Den cache müsste es aber pro savegame geben und an den namen vom save kommt man nur über Umwege und es macht Stress wenn man das save mal unter einem anderen Namen speichern möchte...
      Vielleicht hast du da aber noch einen anderen Hack im Ärmel, ich bin gespannt.

      Der Stand sieht sinnvoll aus und wird bei mir dann wohl sehr bald objdata ablösen, da es im Endeffekt das Selbe mit einer etwas schöneren API macht. Objdata war eh nur so eine schnelle und einfache Lösung mit ein paar wenigen Zeilen code, weil ich gefragt wurde, ob ich in die Depots denn auch Schmalspurgleise legen kann.

      p.s. das Objekt gedöns für die UI parameter klingt auch sinnvoll.
      Wäre cool, wenn du davon mal einen Link zum sorce geben könntest, damit ich mir überlegen kann ob ich das irgendwie sinnvoll mit meinem param script, welches ich in der unterführung erstmalig veröffentlicht habe, verdreht bekomme.
      Darauf werden vermutlich demnächst viele meiner mods aufbauen, da es mir und ggf. Nutzern die die mod etwas an anpassen wollen das Verbinden von config, UI und construction Modulen ziemlich leicht macht, also bin ich auch sehr an einer vernünftigen Anbindung an die repo API interessiert.
      Dieser Beitrag wurde bereits ∞ mal editiert, zuletzt von Freahk (Vor π Minuten)
      mediziner, Merk, Darth Vader, Stepke, eis_os, tomdotio, mikael, weberba, Freahk, Gott und 42 weiteren gefällt das.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Freahk ()

    • 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.
    • eis_os schrieb:

      Lade Dateien, Nutzer klickt ein Konstruktion auf.
      Du kannst dir über einen modifier einen "onload hack" basteln, indem du eine ~ready.lua multiple unit definierst. Dein modifier weiß dann ziemlich sicher, dass alle anderen modifier durch sind, wenn diese geladen wird.
      An den namen des saves kommt man, falls es denn ein savegame und kein neues Spiel ist, ebenfalls recht hacky über die stdout.txt ran.

      Nun, ich hatte gehofft du hättest da eine etwas schönere Lösung gefunden^^
      Dieser Beitrag wurde bereits ∞ mal editiert, zuletzt von Freahk (Vor π Minuten)
      mediziner, Merk, Darth Vader, Stepke, eis_os, tomdotio, mikael, weberba, Freahk, Gott und 42 weiteren gefällt das.
    • 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.
    • eis_os schrieb:

      Ich hab eine Lösung um Dateien zu finden bevor die loadConstrunction durchlaufen, aber nach weiteren Test war dies schon wieder eine Sackgasse.
      Ich hatte in die Richtung auch mal Versuche gemacht. Am Ende bin ich zu dem Schluss gekommen, dass man es höchstens über shell/cmd builtins gehen könnte. Ziemlich hässlicher Weg, zumal ich immer vermutet habe, dass es wohl eher ein Fehler ist der mal irgendwann behoben wird, dass man aus mods heraus einfach fröhlich commands über die shell/cmd ausführen kann.
      Dieser Beitrag wurde bereits ∞ mal editiert, zuletzt von Freahk (Vor π Minuten)
      mediziner, Merk, Darth Vader, Stepke, eis_os, tomdotio, mikael, weberba, Freahk, Gott und 42 weiteren gefällt das.
    • 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)
    • Es wird also keine entsprechende lib geben?
      Schade, aber durchaus verständlich. Ist schon ziemlich lästig nach Wegen zu suchen und am Ende doch keinen zu finden der gut funktioniert.
      Dieser Beitrag wurde bereits ∞ mal editiert, zuletzt von Freahk (Vor π Minuten)
      mediziner, Merk, Darth Vader, Stepke, eis_os, tomdotio, mikael, weberba, Freahk, Gott und 42 weiteren gefällt das.
    • 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.
    • eis_os schrieb:

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

      This is what UG said months ago:



      So the bad news is, I figured out what the problem is and it´s rather simple: Constructions are loaded before modifiers. So it just can´t work that way.

      The “good” news: We discussed it and added an entry to the to-do list which should take care about that problem.

      Probably not something we can manage to fix until the next patch, but I hope we can provide a solution at some point.

      I think just need to remind them about this.

      In fact if they can improve their track param generation by default it will be good enough, and of couse they need to add an api to do this.
      This guy is too lazy to create a signature. 8o
    • 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?
    • eis_os schrieb:

      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?
      Sometimes they did update quick sometimes not.

      Of example the UI, they forgot to do it in the April update, and I just send one mail with angry disappointment the second day



      Hello,

      It's quiet disappointing to find out in the latest test version of the game, the panel size stays with the same limits as before.

      It's an important concerned issue for almost all station and infrastructure modders, we have many options and they can't be separated into different menu items, is it really so hard to improve this?


      then they did a hotfix the forth day.

      Same as the terrain alignement calculate issue on open cut station.
      This guy is too lazy to create a signature. 8o
    • There are just more to-dos then we have time to implement. So yes: Not all of them will find their way into the next patch.

      Not everybody (in particular modder vs. regular player) has the same wishes, priorities or needs. Finding a balance which suits everybody is difficult. And after each patch, everybody will still miss something …

      But @Enzojz is correct. “Nagging” and letting us know why things are important for you (like @eis_os) has an influence. So don´t give up! :)

      PS: Perhaps it was a rhetorical question, but It took 4 updates ;) ... but without modders asking for it, it would have not been changed at all.
      Community-Manager und Projekt-Manager bei Urban Games
    • Ich ärger mich immer gerne, wenn etwas nicht so geht wie ich es gern hätte, schreibe den armen Tom dann an und irgendwann kommt eine Rückmeldung. Beim nächsten patch waren dann immer einige Punkte über dich ich mich gefreut habe mit drin. Natürlich nicht alle, aber ich finde schön, dass sich etwas tut.

      Bis dahin: Einfach drüber ärgern, dass es nicht geht :D

      p.s. ja die Schnittstellen von TpF sind im Vergleich zu anderen Spielen häufig echt starr und eigenartig, aber die verwenden meistens auch eine der großen engines. Ob es nun die richtige Entscheidung war eine eigene zu basteln anstatt eine der großen zu verwenden mag ich nicht bewerten.
      Dieser Beitrag wurde bereits ∞ mal editiert, zuletzt von Freahk (Vor π Minuten)
      mediziner, Merk, Darth Vader, Stepke, eis_os, tomdotio, mikael, weberba, Freahk, Gott und 42 weiteren gefällt das.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Freahk ()

    • @tomdotio: Was das Thema Parameter angeht, gibt es glaube ich gerade einige Punkte, die einige Modder von "coolen" Dingen abhalten. Wenn es da beim nächsten Update eine kleine Ecke für gibt, würde das sicher einige Freuen.
      Hier mal die Punkte die mir spontan einfallen, ohne Priorisierung:
      • Parameter für weitere Bereiche (seien es Signale [denkmal daran, wieviel mögliche Signalbilder es allein in Deutschland gibt, das sind sicher über die Signaltypen hinweg > 100], Straßen Gleise usw.)
      • Dynamische Defition der Parameter (damit sind z.B. dynamische Menues basierend auf Selektion möglich, oder mit jetztigen mitteln das Reagieren auf andere Mods. Bei mir liegen da aktuell z.B. Haltestellen mit dynamsicher Straßenauswahl an.)
      • Mehr UI-Elemente für das Menu, damit so dinge wie Steigungen/Radien/Gleisanzahl... nicht über einzelne Buttons definiert werden müssen. (Wobei da über die dynamischen Menus villeicht schon mehr machbar ist als aktuell)
      Soweit mal die Punkte die mir gerade einfallen. Nebem vielem anderem was am besten gleich morgen eingebaut ist ;)
    • Benutzer online 1

      1 Besucher

    • Advertising