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

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


  • Hallo


    Für die Weiterführung der Diskussion in Gameplay-Patch angekündigt


    Hier also mal meine Ideen & Anregungen zur Modding Schnittstelle


    Die einzelnen Punkte werde ich dann noch mit Inhalt füllen,sobald mir die Zeit es zulässt.



    Zusammenfassung:

    • Dokumentation zu Parametern
    • Fehlerbehandlung
    • bessere API für das Laden von neuen Ressourcen (Gleise, Straßen, Tunnel)
    • Kontrolle über das Konstruktionsfenster per LUA. Ich möchte alle Internen UI Elemente (Knöpfe usw.) selber festlegen
      Daraus erstellt meine LUA Funktion eine Parameter Liste die in der Entity Konstruktion abgelegt werden kann.
    • Möglichkeit im Virtuellen Res Ordner nach Dateien zu suchen.
    • Pfad Auslesen/Speichern von Mod spezifischen Einstellungen.
    • Snappoints für Konstruktionen
    • Bessere Kontrolle über die Bodentätigkeiten eines Gleis. (Und auch keine Änderung Textur bei alignTerrain = false)
    • Abschalten von Tunnelwänden (Ich will nicht jedes Modgleis duplizieren um die Wände zu ändern)



    Dokumentation zu Parametern
    Damit wir beim erstellen von Mods keine bösen Überraschungen erleben wäre eine Übersicht der Grenzen von Parametern hilfreich:
    Beispiele: Max Min werte von slopeLow, slopeHigh


    Wie kurz darf ein Straßenstück sein das Snappoints hat? (wenn man ein größere Strasse anbaut, und die Verengung nicht mehr passt crasht das Spiel.)



    Fehlerbehandlung


    Die LUA Stack Traces sollten wenn möglich die Dateiname mit kompletten Pfadnamen des Modordners zeigen.


    Allgemein wäre es gut nicht nur den Mod ID sondern auch die Bezeichnung aus der mod.lua im stdout zu zeigen (Gerade für SteamWorkshop Mods)



    API für bessere Ressourcenmanagement


    Zurzeit hat TPF keine Möglichkeit die Mod Gleise, Strassen usw. Zentral per Code abzufragen.


    Daher Schlage ich eine API Schnittstelle vor, die internen Repositories für Gleise, Strassen, Brücken und so weiter zur Verfügung stellt.
    Leisten soll Sie: Die Anzahl der Typen auszugeben, die Daten per ID bzw. Namen zu erhalten, zwischen ID und Namen zu konvertieren.


    Als Beispiel:
    game.repositories.tracks / roads / bridges
    getCount()
    getById()
    getByName()
    convertIdtoName()
    convertNameToId()


    Damit wäre es Möglich die Gleisauswahl der parameterutils komplett dynamisch zu erstellen.
    Auch sind Fragen wie die Gleis oder Straßenbreite so zu erhalten. Ein Depot bauen mit Schmalspurgleis, dafür bräuchte man nur noch ein Depot.


    Objekte (Gleise, Strassen, Brücken) erhalten darüber hinaus noch einen shortUIName, und hideInUI Flag.
    (Keine Hacks mehr per Erscheinungsjahr um etwas zu verbergen)
    Die Filterung hierbei übernimmt ein LUA Script, damit kann dann auch nach anderen Kriterien gefiltert werden.
    Die starre paramsutil.makeTrackTypeParam Funktion wird durch eine neue ergänzt. shortUIName wird als Namen der (Gleis)typen genutzt


    Probleme / Änderungen am Spiel:


    Hierfür muss das Laden von Mods geändert werden, Gleise oder ähnliches müssen früher als Konstruktionen geladen werden oder das Konstruktionsfenster muss man updaten können.
    Die UI kann zurzeit nur komplette Parameter per Zeit ausblenden.




    Konstruktionen UI


    Neue API für UI Konstruktionen, da es eine Zweideutigkeit gibt zwischen param und param der updateFn, hier eine Unterscheidung:


    uilist = eine Liste mit der UI Beschreibung (params der Konstruktionsbeschreibung)
    settings = eine Liste der gewählten Einstellungen des Users, bzw. die vorhandenen oder neuen Einstellungen der Konstruktion. (also der UI Parameter Teil von updateFn, { param1 = 1, param2 = 2, ... })


    Es gibt keine Änderungen in den Namen der vorhanden Daten bzw. in der Funktion.


    Neue UI Elemente für die Uilist


    Es gibt einen neuen UI Type für jedes Element, sollte dieser nicht vorhanden sein wird type = "VALUELIST" angenommen (zwingend)
    Es muss immer auch eine values = {} angeben werden, dies soll verhindern das "alte" Mods zu viele Probleme bekommen, ist aber nicht zwingend.


    Hierbei ist zu beachten, damit nicht alles intern verändert werden muss das UI Elemente weiterhin auf uint32 begrenzt sind.
    Desweiteren gibt es die Möglichkeit mit hidden = true ein Element auszublenden,
    für kompaktere Layouts kann die Überschrift weggelassen werden. name = ""


    Einzelne Werte in values Listen sollten auch die Möglichkeiten habe per yearFrom yearTo Zeitabhängig ausgeblendet werden.
    Um auch hier die Kompatibilität zu erreichen, schlage ich eine Liste yearFromValues und yearToValues vor, die Liste hat für jeden Eintrag in values einen Wert.


    Die verschiedenen Typen:


    Wenn Values gefüllt ist, können diese Werte ausgewählt werden, anstatt einen Wert zwischen minValue, maxValue inklusive
    Für größere Wertelisten wäre eine Schnellwahl schön, vielleicht kann man da die Linienauswahl Fenster wiederverwenden.




    updateUIFn(uilist, settings)
    Erstellt eine neue UI für diese Konstruktion und ersetzt die uilist Definition,
    gibt als Rückgabewerte eine Tabelle wieder, analog der updateFn.
    Mögliche Rückgabewerte sind eine veränderte uilist und/oder eine neue settings Liste


    return {
    uilist = uilist,
    settings = settings
    }



    updateUIFn wird aufgerufen bevor eine Konstruktionsfenster erstellt wird, nachdem ein UI Element bedient wurde und nachdem die updateFn ausgeführt wurde.
    Die updateFn kann per result.uisettings die Einstellungen der UI ändern!:



    Weitere Punkte folgen...
    Ihr seit eingeladen eure Kritik / Fehler / API Wünsche zu äußern. Vielleicht hab ich ja noch irgendwo einen Denkfehler oder es gäbe eine bessere Alternative.

  • I add something


    It will be interesting to give information about environments, for example


    1. A track assert, should have chances to see the existing track edges that it catchs, so the assert can be calculated accordingly.
    2. A station, if snapped to some existing tracks, the information about snapped nodes(also nearby nodes) so the mod can recalculate accordingly.
    3. Any building, the terrain information, like slope.


    It will be interesting to add range based spinbox and multiple checkbox in the construction UI, also will be interesting to have two level construction UI (some items collapsed to one line by default)

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

  • Erstmal zu deinen Punkten:


    Bei der Dokumentation und der Fehlerbehandlung stimme ich dir vollkommen zu. Da sollte etwas getan werden.


    - Snappoints für Konstruktionen

    Steht auf meiner Wunschliste ganz Oben. Die Unterführung macht sowas zwar bereits, nutzt aber einen ziemlich hässlichen workarround den man auch nicht in allen Situationen nutzen kann.
    Weitere ähnliche workarrounds hatten wir dabei ebenfalls ausprobiert. Teilweise sind die in bestimmten Situationen nützlich, teilweise crashen die unter manchen Systemen (lustigerweise nicht unter allen) das Spiel.
    Die "stable" workarrounds arbeiten alle mit einer Kombination aus rail und road snaps und eben dies ist nicht in allen Situationen ohne weiteres möglich. Da muss eine Lösung her die snapping der lanes direkt ohne den Umweg über die edges (Straßen und Gleise) erlaubt.


    - Kontrolle über das Konstruktions und, hier ergänze ich, allgemein alle Parameter Fenster, steht bei mir auch ganz Oben auf der Wunschliste mit dabei.
    Mit "allgemein alle parameter Fenster" meine ich die der Gleise, Straßen und Signale (mag sein, dass ich noch was vergessen habe)
    Gleise haben so viele unterschiedliche Werte für die man Parameter verwenden könnte, um das Menü etwas aufzuräumen. Gleiches gilt für Straßen.


    - bessere API für das Laden von neuen Ressourcen (Gleise, Straßen, Tunnel):
    stimme ich dir prinzipiell zu. Fürs Erste sollte es dort aber reichen die Straßen zu laden bevor man die construction läd und deren Parameter Fenster initialisiert. Die ID to name Umwandlung könnte man dann notfalls per lua lib umsetzen, wenn man beliebige tables an eine entity kleben kann.
    Zusätzlich sollte das Spiel eine Liste aller geladenen Ressourcen dieser Art zur Verfügung stellen, damit man sich diese Liste nicht, wie aktuell, selbst über einen modifier zusammensammeln muss (ja, man kommt an diese Informationen bereits ran aber leider zu einen Zeitpunkt an dem es schon zu spät ist und es ist auch keine gute API, wenn man sich die Liste erst zusammen sammeln muss...)
    Dennoch muss ich dir zustimmen, dass eine solche API natürlich noch etwas besser wäre, mit Sicherheit aber auch mit einer Menge Aufwand verbunden wäre den UG imho lieber in andere API Verbesserungen investieren kann.


    - Möglichkeit im Virtuellen Res Ordner nach Dateien zu suchen:
    Auch hier stimme ich dir aber zu, dass es dazu eine Funktion geben sollte. Es gibt bereits einen Weg für mods eine solche Funktion im lua zu implementieren (außer für meshes) aber auch das ist eher ein nicht schöner workarround und unter Umständen, auf die man selbst keinen Einfluss hat funktioniert der workarround nicht.


    - Pfad Auslesen/Speichern von Mod spezifischen Einstellungen:
    Mir ist nicht ganz klar was du damit meinst? So etwas in der Art wie die config von Merk im Zusammenspiel mit dem MM von Xanos?
    Wenn ja stimme ich dir zu, dass das Spiel sowas direkt handlen können sollte, zumal es so scheint, dass dies mal angedacht war, es aber nicht ins Spiel geschafft hat.
    Allerdings würde ich das von der Priorität her ziemlich weit Unten ansiedeln.


    - Bessere Kontrolle über die Bodentätigkeiten eines Gleis. (Und auch keine Änderung Textur bei alignTerrain = false):
    Bei dem Punkt in Klammern stimme ich dir voll und ganz zu.
    Den anderen Teil davon verstehe ich auch nicht so recht. Was möchtest du da genau kontrollieren?


    - Abschalten von Tunnelwänden (Ich will nicht jedes Modgleis duplizieren um die Wände zu ändern):
    Tunnelwände komplett abzuschalten ist imho nur bedingt sinnvoll. Die Tunnelwände sollten meiner Meinung nach allerdings zum Tunnel und nicht zum Gleis gehören.
    Zusätzlich sollten diese optional sein, damit man keine transparente Textur verwenden muss, wenn man mal keine Wand haben möchte.


    So weit zu deinen Punkten.
    Meine Ergänzungen kommen Heute Abend oder Morgen, ich muss jetzt weg meinen Geburtstag feiern.

    Dieser Beitrag wurde bereits ∞ mal editiert, zuletzt von Freahk (Vor π Minuten)

  • ‎Is all the way top on my wish list. The subway makes something like this already but uses a pretty ugly workarround you can also not use in all situations. ‎
    ‎ More similar workarrounds we had tried out also here. Some are useful in certain situations, sometimes crash which on some systems (oddly not at all) the game. ‎
    ‎ The 'stable' workarrounds all work with a combination of rail and road snaps and this is not in all situations without further ADO. There a solution must be that snapping allows the lanes directly without having to use the edges (roads and railways). ‎

    I have requested it to UG before, it seems they will not likely to implement it.


    tracks have so many different values for the parameter could be used, the menu something to clean up. The same applies to roads.

    In general, tracks should be decomposed as tracks, tunnel, portail, catenary etc, I think this will not be done until TPF2

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

  • Ja, ich hab in meine Mods auch ein kompletten Modifer der mir alle Gleistypen und Strassentypen lädt mit den bekannten Problemen.
    Außerdem kann es ja sein, das ein späterer Modifer die Werte ändert und soll ich nochmals alle LUA Werte zwischenspeichern für jedes Mod, das ist doch dämlich? Außerdem UGs UI könnte das ja auch nutzen...


    UG hat schon intern ein Repository für die Typen. Ein Entity kann auch schon serialisiert werden nach Lua, zum Beispiel per game.interface.getEntity, warum also nicht auch nicht die Typen aus dem Repository?
    Und Auflistungen gibt es per game.interface.getEntities, ich verlange ja nicht das man es dynamisch ändern kann.



    Textanalyse von TPF:
    StreetTypeRep, TrackTypeRep, BridgeTypeRep, TunnelTypeRep, cargoTypeRep, m_railroadCrossingTypeRep


    Und es gibt auch bestimmte Funktionen für die Repos:


    TrackTypeRep->Find(standardTrackName) Das bedeutet das es eine Funktion zum Auffinden eines Types gibt
    trackTypeRep->GetNumTypes()
    oder auch cargoTypeRep->GetNumTypes()



    --
    Xanos ModManager kann die Listen nicht erstellen, ich hab eine Liste von Modgleisen für die UI, diese gilt aber Modgrenzen hinweg.
    Nun ist die Frage wo ich das Zentral speichere für alle Mods. Der richtige Platz wäre für jeden Steam User / User separat, also da wo die settings.lua ist.


    ---
    Wie kannst Du nach Dateien in LUA suchen (cross platform ohne exec)? Ich möchte alle Dateien in einen Verzeichnis aller Mods auflisten, also /mod_1/meindir/*.data, /mod_2/meindir/*.data

  • Würde es Sinn machen wenn gewisse Parameter in ein eigenes Lua ausgelagert werden? Ich denke dies wäre nur eine kurz- bis mitelfristige Lösung.


    Ich dachte da nur mal vor mich hin. Z.B die Tracktypes in den Depots und Bahnhöfen auslagern?


    Wie gesagt. Ist keine langfristige Lösung, das muss UG definitiv nochmals überdenken.


    Mein Ziel ist es nämlich mehrere mehrer Oberleitungen zur Auswahl zu haben. Da aber die Oberleitungen an den Gleisen fest integriert sind müssen neue Gleistypen erstellt werden. Sind da nun noch verschiedene Geschwindigkeiten gewünscht, scrollt man sich den Finger wund :S

  • in general, tracks should be decomposed as tracks, tunnel, portail, catenary etc, I think this will not be done until TPF2

    Yeah that would be great. Anyways, for now it would already be a huge advantage to move the wall over from the track to the tunnel.


    @eis_os
    Ich habe ehrlich gesagt keine Lust echsen oder elfen zu analysieren und glaube dir das einfach mal. Analysieren kann man halt machen, möchte man (also zumindest ich) aber nicht...
    Wenn es im code schon etsprechend vorhanden ist, sollte man die api tatsächich einfach an die lua Umgebung weiter geben, falls nicht wäre es aber auch nicht so wild dies auf einen späteren Zeitpunkt zu verschieben.


    Außerdem kann es ja sein, das ein späterer Modifer die Werte ändert

    ja das stimmt, ist allerdings nur dann ein Problem, wenn der modifier eine neue table erzeugt und zurückgibt anstatt einfach das übergebene Objekt zu modifizieren und wieder zurückzugeben.
    Die meisten Mods modifizieren einfach die übergebene table. Es gibt natürlich auch manche die dies nicht machen und damit den workarround aushebeln, weshalb ich die forderung nach zumindest einer Liste und der geänderten Ladereihenfolge vonn und ganz zustimme. Die gesamte API wäre natürlich schön und wenn das ganze intern eh schon vorhanden ist, sollte diese auch zur Verfügung gestellt werden, allerdings nicht unbedingt notwendig.


    "Wie kannst Du nach Dateien in LUA suchen" naja ich kann für so ziemlich alles bis auf meshes und scripts einen modifier registrieren und mir merken was alles geladen wurde. Für scripts kann ich per pcall versuchen ein Script zu laden und weiß dann auch, ob es existiert oder nicht.


    Die die erwähnten workarounds sind auch eher nicht an dicht gereichtet, da ich davon ausgehe, dass du du meisten oder alle davon schon kennst, sondern stehen hier eher für die die diese noch nicht kennen.



    So jetzt zu meinen Ergänzungen:
    Ich hatte ja bereits ergänzt, dass in den Zugriff auf die UI wünsche.
    Dadurch ergeben sich folgende weitere (teils dazu notwendige) API Wünsche:


    - neuer törö alignment und face modus "fromSpline".


    - callbacks, ähnlich der updateFn einer construction für Straßen, Gleise, Tunnel und Brücken


    - Straßen Schnittstelle bezüglich der lanes modbarer gestalten:


    - Straßen und Gleis API zu Verkehrswegen generalisieren.

    Dieser Beitrag wurde bereits ∞ mal editiert, zuletzt von Freahk (Vor π Minuten)

  • ‎‎

    Indication of the aligmnents and the ground faces by a spline, interprätiert a line with a certain (to be) width. ‎
    ‎ Feature for roads and tracks, the new alignment is useful. Sometimes you want to dig a pit along a spline is no road or just to dig a pit for a road not a separate define road types. ‎
    ‎ As the new feauture anyway, dig a hole, which is equivalent to the course of the road and the area that the road nothing else is as a line is exactly as wide as the road and follows the course of the road, which is a spline, the internal törö likely can alignment already this. ‎
    ‎ In the faces, it could become more difficult.‎

    Aha, spline, you should look into my code, I have already done this! (in flying junction of march already, but the current wip version integrates more practical functions)


    I did this for flying junction and also my ultimate curved station


    https://github.com/Enzojz/flyi…cripts/junction_assoc.lua


    Line 239 and 273 also 139


    I use arc(circle with ranged radius) not spline, since in this game they are using spline to simulate arc, so calculate directly from arc is better, you can't calculate the length of a spline.



    the spline where the track / the road to follow. Based on this spline, you can use E.g. assets along the road or for the terrain use this alignment or the ground faces. ‎‎

    I have request UG this already, but I think it's not realistic since when the construction is snapped to road/track, you don't actually call the updateFn. UpdateFn is called only when the user change the parameters.

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

    2 Mal editiert, zuletzt von Enzojz ()

  • @Enzojz thanks, but there should be a native version if we want to pass the spline to the updateFn and let the user himself handle the terrain alignment.
    Otherwise there will be many implementations of the same alignment and some users that don't know how to properly align the terrain.
    btw. I also implemented some spline to polygon approximation so I can use splines for terrain alignment.
    I should have looked at your code BEFORE implementing the whole spline stuff :D On the other hand it was just ported from some js code I had written some years ago to display some spline stuff in the browser, so it was not too much work.
    Btw. it is possible to calculate the exact length of a spline by (numerical) integration. However, in many cases an approximation is just fine and faster.

    Dieser Beitrag wurde bereits ∞ mal editiert, zuletzt von Freahk (Vor π Minuten)

  • Hmm, die Idee finde ich nicht schlecht.
    Ich kann aber sagen das Konstruktionen in TPF ein Spezialfall sind und für andere Sachen so nicht existieren, aber das kann man für TPF3 natürlich aufgreifen. Ich hoffe ich hab die UI Parameter Erweiterungen verständlich rüberbringen können.



    Enzojs: Your code is a bit hard to follow. My code is even worse to follow, so no problem :) If I am right you calculate the arc of a new track and the store this for later reusage.
    My station script is dump compared to your approach, I do have a virtual coordinate system and bend it to the curve.
    Reminds me I should release update to my mods.


    Ich frage mich ob ich meine API als shared mod veröffentlichen soll, ich mag es eher das ein Mod ohne externe Abhängigkeiten sind und nicht jeder wäre wohl mit meinen Ideen bzw. deren Ausführung glücklich. Anderseits die API und modifer nicht in jedem Mod mitzuliefern wäre auch ne schöne Sache.

  • Ich frage mich ob ich meine API als shared mod veröffentlichen soll

    Ich bitte doch drum!
    Ansonsten würde ich demnächst meine mini lib objdata freigeben die dies wirklich minimalistisch löst:
    API:


    Init teilt man einfach mit von welchen Typen man später die genauen Werte haben möchte,
    listObjects gibt die Liste der Namen aller Objekte des bestimmten Typens wieder,
    getObjectData gibt dann die Daten des bestimmten Objekts aus und
    ObjectTypes ist einfach nur eine Auflistung aller gültigen Typen, damit ich nicht immer nachschlagen muss und Tippfehler schneller auffallen.


    Ich müsste objdata dann nur noch schnell fit für neue Versionen machen und in die doku bringen, aber das ist ja bei den paar Funktionen schnell getan..

    Dieser Beitrag wurde bereits ∞ mal editiert, zuletzt von Freahk (Vor π Minuten)

  • @Enzojz thanks, but there should be a native version if we want to pass the spline to the updateFn and let the user himself handle the terrain alignment.
    Otherwise there will be many implementations of the same alignment and some users that don't know how to properly align the terrain.
    btw. I also implemented some spline to polygon approximation so I can use splines for terrain alignment.
    I should have looked at your code BEFORE implementing the whole spline stuff :D On the other hand it was just ported from some js code I had written some years ago to display some spline stuff in the browser, so it was not too much work.
    Btw. it is possible to calculate the exact length of a spline by (numerical) integration. However, in many cases an approximation is just fine and faster.

    No matter it is native or not, it's ok once it works. The native Lua lib given by UG is not so functionally and hard to use, so I did almost 100% of lib by myself. I started with port my lib written some years ago in C# too :D


    Enzojs: Your code is a bit hard to follow. My code is even worse to follow, so no problem If I am right you calculate the arc of a new track and the store this for later reusage.

    My lib fits 100% my style of coding : undocumented. Then I am deep influenced by OCaml (since at work I am using this language) so perhaps not easy to follow by who is not familiar with it.
    Yes I calculate the tracks by different arcs and duplicating them with different R then assembly them together, and this can be used for both edges and polys. For the vertical profile it's almost the same thing and linking the two aspects with distance from the start point of arc.


    My station script is dump compared to your approach, I do have a virtual coordinate system and bend it to the curve.

    It is also what I was thinking about in first place before UG release their curves station, since they release it before I did it, but I find this game supports only affinity transformation, I switched to analytic solution since I did wrote such a library some years ago in C#, copy paste is always quick.



    ‎‎I was wondering whether I should publish my API as shared mod, I like my it rather a mod without external dependencies are and not everyone would be probably with ideas and their execution happy. On the other hand to provide API and modifer not in any mod would be also a beautiful thing. ‎‎‎‎‎

    Have you tried it "complied" or "confiscate" it then release it so no other will not modify it, I remembered at least theirs one mod in TPF have code confiscated.

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

    Einmal editiert, zuletzt von Enzojz ()

  • @Enzojz as you said it's fine when it simply works, however when they should change the API that way so the modder has to care about proper alignment, they will have to provide a way to align terrain directly by splines or to transform a spline to an alignment polygon, since they can't expect everyone to implement this conversion on his own or use some community code for this.



    Einzelne Werte in values Listen sollten auch die Möglichkeiten habe per yearFrom yearTo Zeitabhängig ausgeblendet werden.

    ist ein wenig redundant zur updateUiFn. Hier könnte man auch einfach den Eintrag entfernen, müsste dann aber gut aufpassen, da sich dadurch ggf. die indizes verschieben.
    Ich sehe also den Grund der Idee aber warum sollte man das invisible feature künstlich auf einen Bereich der timeline einschränken?
    Ich würde da eher über eine eine visibility Liste vorschlagen, die für jeden Eintrag in den values einen Eintrag hat der angibt, ob dieser Button sichtbar ist oder, ob es sich um einen Geist handelt.



    Verstecktes Element:
    type = "HIDDEN"
    value = <uint>
    Dient dazu weitere Daten für eine Konstruktion zu speichern

    Notfalls auch so...
    Ich würde aber einfach eine data table bevorzugen die an das constructionInstance Objekt angehängt wird. (mit constructionInstance bezeichne ich das was die updateFn zurückgibt)
    Dieses Objekt wird dann entweder als eigener Parameter oder als Element dieses mysteriösen Objekt, welches immer in den params mitgegeben wird und das statndardgleis und alle möglichen Bäume enthält, an die updateFn übergeben.
    Das hätte den Vorteil, dass man nicht wieder alle Werte auf indizes mappen muss, um sie zu speichern. Das hätte den Vorteil, dass man z.B. Einstellungen die man pro Gleis vornehmen kann einfacher speichern kann. Ansonsten bräuchte jedes Gleis für jede Eigenschaft ein eigenes HIDDEN Element.
    Man muss halt nur aufpassen das Teil beim ersten Aufruf der updateFn zu initialisieren. Alernativ könnte man noch eine initFn an die construction kleben die dann beim beim auswählen einer construction im Menü dieses data Objekt initialisiert.


    Bei der Überschrift fehlt vermutlich das value Attribut.
    Bei der checkbox für jeden Eintrag eine eigene Zeile zu machen ist vermutlich nicht so eine tolle Idee.
    Eine visibility table wäre bestimmt auch für die checkbox und die bitsetting sinnvoll.
    beim spinner würde ich statt des formatString eine toString Funktion bevorzugen. Ist flexibler und formatstrings sind für Leute die damit noch nichts zu tun hatten ziemlich unhandlich.


    Ansonsten passt das so würde ich sagen.

    Dieser Beitrag wurde bereits ∞ mal editiert, zuletzt von Freahk (Vor π Minuten)

  • @Enzojz as you said it's fine when it simply works, however when they should change the API that way so the modder has to care about proper alignment, they will have to provide a way to align terrain directly by splines or to transform a spline to an alignment polygon, since they can't expect everyone to implement this conversion on his own or use some community code for this.

    Sorry, I don't quiet understand what you mean...you mean use a spline(or, edges) as a way to deform terrain?
    I think using edges as directives to deform terrain is the most probably way, for UG if they want to introduce this, they won't have much extra work to do since I think they have implement it in the core.

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

  • yeah that's what I said above it seems they use it to perform the track and road terrain alignment internally, but they should also provide this feature to the lua api so we can also align the terrain along splines without approximating the splines to polygons by ourselfs.

    Dieser Beitrag wurde bereits ∞ mal editiert, zuletzt von Freahk (Vor π Minuten)

  • Yeah, I do think it would be better to have a API from UG for this, technical it should sample the terrain the same (even wrong) way that UG uses. So the results are consistent.



    Freakh:



    Natürlich würde ich gerne auf die Hidden Elements verzichten und eine lua table speichern, dann sind auch floats und strings möglich.
    Hier ging es mir um die Kompatibilität zum vorhanden Code und Savegames.


    Technisch gesehen sind alle Element immer noch einfache Parameter und zu TPF und updateFn kompatibel.
    Einzelnen Einträgen in einer Value Liste hat den selben Grund, da man ja nur einen Integer Wert speichern kann.


    Die Bedeutung der ID<->Gleis/Brückenart Mappings soll sich während der Zeit nicht ändern, das fehlt auch noch in der API Beschreibung zu den Repositories.


    Eine alte Konstruktion kann ja auch vorhanden sein, die der Spieler upgraden möchte. Da soll ja nicht auf einmal ein ganz andere Straßentyp oder ein Gleistyp auftauchen.


    Darüber hinaus sind da auch noch ein paar andere Dinge die unsere Aufmerksamkeit benötigen: Zurzeit schreibt UG einfach die Parameter Liste um um ein Gleisupgrade zu machen.
    Auch hier müsste es ein Callback geben, der den neuen Gleistyp sowie Edge ID mitgeteilt bekommt und die "uisettings" dann ändert.



    So sollten die Repository IDs im ganzen Spiel das selbe Darstellen und daher ist eine reine Modifer Lua Lösung nur ein temporärer Ersatz.
    Trotzdem werde ich wohl das komplette API als LUA Version ausarbeiten damit man schon mal damit experimentieren kann.


    Wenn es UG dann nicht umsetzten will, kann zumindest keiner behaupten wir haben es nicht versucht.

  • Ja die Sache mit der Kompatibilität ist klar.
    Ich sehe nur im Moment nicht den Punkt an dem eine alte construction die kein solches data Objekt mit sich führt inkompatibel zu einer neueren construction die dieses Objekt erwartet ist.


    Alte nicht angepasste constructions würden eine leere data table übergeben bekommen, diese ignorieren und wie gewohnt die construction anhand der params zusammenkleben, an denen sich nichts geändert hat und keine zusätzlichen Informationen in der data table ablegen.


    Neue oder auf die data table angepasste constructions würden feststellen, dass die data table leer ist, diese initialisieren und anschließend anhand der params die data table füllen. Hier könnte es sein, dass beim upgrade einmalig gewisse Informationen verloren gehen, die man dann im worst case kurz neu einstellen müsste.


    Noch eine Sache zur updateFn:
    Ein weiteres Feld sollte ein updateEvent enthalten, welches folgendes enthält:
    Den Grund des updateFn Aufrufs:
    - öffnen des upgrade Fensters
    - öffnen des "neue Construction" Fensters
    - betätigen eines buttons (gerne auch welches buttons)
    - schließen des Fensters (durch Abbruch)
    - schließen des Fensters (mit ausführen des Umbaus)


    Beim betätigen eines buttons sollte zusätzlich der Button (key/index Paar) mit angegeben werden.

    Dieser Beitrag wurde bereits ∞ mal editiert, zuletzt von Freahk (Vor π Minuten)

  • Du möchtest also die UI Funktionen mit in die updateFn packen? Dies kann man natürlich auch so lösen. Ich will das für UG aber so einfach wie möglich gestalten :-)


    Darf ich fragen was Du mit "schließen des Fensters (durch Abbruch)" und "schließen des Fensters (mit ausführen des Umbaus)" vor hast?

  • Ich würde ganz gerne z.B. über eine Option einen Bahnsteig auswählen, damit man diesen bearbeiten kann.
    Damit man auch direkt sieht um welchen Bahnsteig es sich handelt, würde ich den markieren wollen, indem ich einfach ein mesh mit ner halbtransparenten Textur drüber lege oder sowas.
    Wenn das Fenster dann geschlossen wird (mit ausführen des Umbaus oder ohne ist hier egal) müsste ich die Markierungen wieder raus nehmen und das geht eben nur, wenn ich weiß "warum" die updateFn aufgerufen wurde.
    Den Aufruf beim schließen des Fensters durch Abbruch kann man auch weg lassen. In diesem Fall wird ohnehin nichts gebaut, aber TpF müsste sich dann auch darum kümmern, dass ggf. in der data table gemachte Änderungen wieder verworfen werden und das könnte schwierig werden.
    Deshalb meine Idee einfach mitzuteilen "hey! Das was eben verändert wurde muss wieder verworfen werden, kümmer dich drum."
    Das wäre dann natürlich der Vorteil der Variante ohne data table in der man alles als hidden uiValue verpacken muss. Da wäre es für TpF eine Leichtigkeit eine Kopie der params anzulegen und beim abbruch entsprechend zurückzusetzen.

    Dieser Beitrag wurde bereits ∞ mal editiert, zuletzt von Freahk (Vor π Minuten)

  • Vielleicht wäre es eine Möglichkeit wenn man bestimmte Teile als nur für die UI Phase markieren könnte. (also dem Modell nicht nur die id und matrix mitgeben sondern auch noch ein UI Flag)


    Zusammengefasst wäre es das Du eine UI haben möchtest die gar nichts mehr mit dem jeweiligen Daten der Konstruktion zu tun hat.
    Dann kann man auf ein Teil der Konstruktion klicken und dafür eine (gesonderte) UI Anzeigen.


    Wie sollen alte Konstruktionen/Mods funktionieren?
    Wenn kein Datenpaket im result set ist, weiterhin die params Einstellungen der UI speichern? Es wird von UG kein Update geben das alle Mods unbrauchbar macht, einfach die alten Informationen Verwerfen geht ja nicht, es muss ja auch noch mit "alten" Mods laufen.

BlueBrixx