Selbstmodifizierendes Auswahlfenster

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


    Bei meinen Quertragwerken würde ich gerne mehr Konfigurationsmöglichkeiten in der Construction anbieten. Das würde bei einer konventionellen Auswahlfenster zum Auswählen der Optionen den Rahmen hoffnungslos sprengen, denn ich hätte dann für jeden Aufhänger eine Reihe Auswahlmöglichkeiten. Als Beispiel nehme ich Position grob, Position fein, Richtung, Isolatorfarbe. Mal 14 Gleisen gäbe das 56 Elemente, das sind zu viele. Was ich mir als Komprimierung vorstelle, ist

    a) eine Gleisauswahl (1 bis 14) über eine Reihe Buttons oder einen Schieberegler

    b) nur vier Buttons darunter, nämlich, wie oben Position grob, Position fein, Richtung, Isolatorfarbe.

    Wenn man jetzt in der Gleisauswahl ein anderes Gleis auswählt, müßten sich die vier Elemente (wohl 2 Schieberegler, 2 Reihen Buttons) unten ändern, und zwar nach der Konfiguration für das gerade frisch ausgewählte Gleis. Wenn Gleis 3 auf Position 4 m 35 cm einen braunen Isolator hat und der Halter rechts an den Fahrdraht kommt, müssen genau diese Informationen in die Elemente geschrieben werden, wenn man Gleis 3 auswählt, egal was beim Gleis vorher war.


    Weiß jemand wie das geht und kann das erklären? Ich habe bisher etwas mit dem onValueChanged-Callback beim Schieberegler herumgespielt, aber mir ist z. B. völlig unklar, ob und wie man die tatsächlichen Werte ändern kann. defaultIndex wird ja wohl nur beim erstmaligen Erstellen der Construction ausgelesen. Oder geht das besser in der updateFn?

    Ablativus mors de genitivo

    Man kann das nur manuell mit der gui api zusammenbasteln, was eine ziemliche Skripterei wird.

    Theoretisch kann man eigene Gui Elemente im vorgegebenen Parameterfenster hinzufügen, so wie Enzojz das in manchen Mods gemacht hat.

    Aber es bleiben zwei getrennte Systeme. Das Konstruktionssystem mit den Parametern ist ein von UG vorgegebenes System, wo man nicht wirklich eingreifen kann.

    Daher muss man alle Events irgendwie selbst handlen, zB mit gamescripts.

    Danke Dir für die Antwort. Auch wenn sie bei dem Zustand der Dokumentation viel experimentelles Programmieren erfordert (experimentell habe ich vorhin herausgefunden, daß die .con bei jedem Klick im Konfigurationsfenster aufgerufen wird, was mir vom Aufbau der .con her völlig unverständlich ist - da hätte ich gedacht, daß sie pro Exemplar genau einmal aufgerufen wird). Ich fürchte, da habe ich interessantere Dinge zu tun, mit denen ich meine Zeit totschlagen kann.

    Ablativus mors de genitivo

    Beim ändern der UI Parameter wird eine neue Konstruktionsblaupause erstellt. Diese hat keine Möglichkeit auf Einflüsse wie Terrain oder Umgebung einzugehen.



    Du wählst eine Construction im Tab


    UI::ConstructionBuilder::setConstruction(conname, templateId) im Binärcode des Spiels wird gestartet. Dieser baut dir aus der ConstructionRep die ParamListComp (Siehst du Rechts als Auswahl)


    Parameter Änderung in der UI change Event -> UI::ConstructionBuilder -> baut aus der ParamListComp eine Lua Tabelle "Parameter".


    Es wird ein CreateProposal erstellt.


    Ruft dann ConstructionDesc.updateFn auf.

    -> Diese Funktion ruft dir deine LUA Update Funktion auf mit einer Parameter Tabelle

    -> Die updateFn der Con Datei gibt lua Tabelle als "result" heraus.

    -> Die Resultdaten haben eine Liste mit Modellen, Lanes, Labeltexte, das ist ein ConstructionResult und wird "eingelesen".

    ===> Blaupause.


    Ein ConstructionResult wird dann mit der ConstructionDesc, Transformation zu den Prosposal im Baucursor


    Hier greift dann auch die Einstellungen deferred Proposal.



    Ein Proposal ist das was Du ggf. im gamescript Abfangen kannst.

    Sobald du dann so ein Proposal hast,

    gibt es im Spiel am Ende eine große Funktion: construction_builder::Apply.


    Die nimmt denn so ein Proposal entgegen und meiselt dir dann echte Entity Objekte auf deiner Karte:

    ecs::component::Construction


    Dort liegt dann die Parameter con Dateinamen, lua::Tabelle der Parameter. Daraus kannst du dann ggf. eine Konstruktion per UI upgraden. (Hast du Module, wird dafür ggf. der ModulBuilder gestartet)


    Alternativ:

    Du sendest dir per eigener UI, via api.cmd ein Proposal an construction_builder::Apply


    Technisch hast du keine Schnittstellen die ParamListComp via LUA zu beeinflussen. Sprich wenn X passiert, zeige nur Y.


    Nicht alle UI Interaktionen führen zu UI Events im GameScript.

    Du kannst aus keiner con Funktion die UI Elemente beeinflussen.

    Technisch gesehen läuft die Con Datei in einem eigenen LUA State.



    Auch wenn die Debug Funktion aktiv ist, werden dir lua Funktionen wie updateFn und co. neu geladen. Die ConstructionDesc aber niemals.



    Auch ist es nicht möglich selber einen UI::ConstructionBuilder Baucursor zu starten. CommonAPI2 tut es aber sehr wohl, das ist im Endergebnis dann die Copy & Paste Funktion.




    Ich merke, ich muss mal ein Glossar mit Fachbegriffen schreiben...

    Siehe dazu die API Doku von UG.



    ConstructionDesc => Ist das Result des Einlesen einer Con Datei, wird in die ConstructionRep beim Spielstart gelanden.

    Hält die Funktionen wie updateFn, den Typ, eine Liste von ScriptParam, usw.

    ConstructionRep => Hält eine Liste der von ConstructionDesc.


    Proposal => Ein Objekt, das eine Liste von Änderungen an der Spielkarte enthält.

    UI::ConstructionBuilder => Ein UI Objekt, dieses stellt in TPF2 den Baucursor für eine Konstruktion bereit. Ist für den Mauscursor zuständig, die Tastaturbefehle zum Drehen usw.

    Auch auf der Karte für OK, Abbrechen bzw Tooltip.

    (Beachte die UI Elemente am Cursor haben einen eigenen Thread und dürfen nicht per api.gui geändert werden! Es geht, aber TPF2 wird crashen... )


    Erstellt intern ein Proposal um deinen Wunsch umzusetzen.

    ConstructionResult => Das Ergebnis (result) eines updateFn Aufrufs.
    ParamListComp => Eine Komponente die aus einer Liste von EditParam eine Liste von UI Elementen herstellt und Änderungsevents an die jeweils Elternelement weitergibt (ModList, UI::ModulBuilder usw )

    EditParam => Das Ergebnis nach der Konvertierung von ScriptParam (UI Parameter einer Konstruktion, Mod Parameter)

    LUA State = Ein eigener LUA Interpreter (hat eigene Variablen, Funktionen, API Schnittstellen) ggf. eigener Thread.