Hilfe für Scripter

Willkommen in der Transport Fever Community

Welcome to the fan community of Transport Fever and Train Fever, the economic simulators of Urban Games. The community is free for you to share and inform yourself about the game. We cultivate a friendly and objective interaction with each other and our team will be happy to answer any questions you may have.

 

Registration and use is of course free for you.

 

We wish you a lot of fun and hope for active participation.

The Team of the Transport-Fever Community

  • mittlerweile ist es ja klar, aber wer komplett neu anfängt, für den ist dies nicht immer ganz einleuchtent.
    und trotzdem wäre es schöner, wenn man als Tooltip nicht "Wähle ein Posthorn" angezeigt bekommt sonder wenn man auf das Posthorn DE mit der Maus geht, dass dann der Hovertext kommt, "deutsches Porthorn"
    also der Aufbau des Tooltip genauso wäre wie Values oder vieleicht sogar
    tooltip_n = _("Wähle ein Posthorn"),
    tooltip_v = _("Posthorn DE", "Posthorn CH", "Posthorn AT", ),


    so bekäme man bei der Überschrift die Anweisung was zu tun ist und auf dem Bild die Info, worum es sich handelt.


    hier ein Beispiel aus der Praxis, Maus auf Überschrift


    schöner wäre es eben, wenn bei der Maus auf dem Garagenkomplex die Meldung kommen würde Garagenkomplex, usw.
    geht aber eben nicht und wenn es noch mehr werden sollten (Bilder) , dann passt auch in den Tooltip nicht mehr alles rein oder er wird ewig breit.

  • Der Tooltip wird per Element gesetzt und eben nicht per Values. Intern ist das auch nicht so vorgesehen, da so eine Liste aus mehreren Buttons besteht, wäre es aber umsetzbar.


    Man kann auch keine einzelne Einträge deaktivieren/verstecken.


    Wenn man via LUA die UI bauen könnte, wäre das viel einfache umsetzbar. UG hat sich aber definitiv dagegen entschieden. Der technisch Gegenentwurf ist meine CommonAPI2, dort werden die C++ Elemente von imgui via lua zusammengebaut.


    Technisch wäre es viel einfacher, man könnte per Callbacks ne UI bauen und darf dann alles (strings / integer usw.) als property bag an die updateFn zu übergeben. Das habe ich mehrmals an UG als Wunsch geäußert.


    Das man Daten auch zwischen den Threads austauschen muss, habe ich auch als Wunsch geäußert. Mir wurde da auch abgeschrieben (Damit wäre CommonAPI2 auch ohne dll komplett zu ersten Version möglich) aber man könnte damit dann auch dynamische Daten von der UI ohne weiteres in eine Konstruktion bekommen.


    Und ich meine per UI ne Textinput Box anbieten, da schreibt man dann seinen Text rein und kann dieses dann in der Konstruktion verwenden. ecs::Name für so etwas zu misbrauchen ist der falsche Weg um das dann als Label anzuzeigen.


    Ohne CommnonAPI2 thread sync, könnte man eine UI bauen und einen entity rebuild anstoßen. Wenn man dann das Schild umbauen würde per modularer Konstruktions UI würden man aber die Einstellungen wieder verlieren.... (params würden wieder überschrieben)

  • z.b. der eCitaro aus dem Vanillaspiel.

    Danke Yoshi, im Prinzip sind es genau die Anordnungen der Blöcke die ich gesucht habe, ich werde das jetzt mal probieren ob die auch Ingame für jederman änderbar sind.

    Bezüglich der Dokumentation vs. Tutorial Thematik habe ich oben eigentlich schon das meiste gesagt.

    Das ist korrekt, zumindest finde ich, dass (ausser der Standardangabe der LabelList) auch die Beschreibung des Einsatzes möglicher "Blöcke" , zumindest 1-2 Stück hilfreich gewesen wären. Dann hätte ich mir diesen Thread sicher gespart.

    Die Daten muss dann in die labelList der Konstruktion updateFn:

    Dieser Ansatz wäre auch OK, aber für meine zwecke wahrscheinlich nicht Konstruktiv. Ich glaube bei dieser Variante ist eine direkte änderung der Text und Zahlenangaben Ingame nicht Möglich, oder?

    MfG elektronikfreak


    MB MSI MPG Z590 Gaming Carbon WIFI - i7-11700K - ASUS ROG STRIX OC Nvidia GTX 1080Ti 11GB - 128Gb Ram - Win10/64 - WsK - 60TB

    (Meine Screenshots dürfen weiter verwendet werden)

  • Hab den Thread erst heute gesehen.


    Zum eigentlichen Problem:

    Und genau das ist laut UG eben nicht Möglich, dass habe ich schon etliche male Probiert bevor ich UG angeschrieben habe. Die Daten sollen ja Ingame veränderbar bleiben. Ich habe das Modell zur veranschaulichung mal beigefügt.


    So wie auf dem Bild gezeigt ist es zur Zeit nicht Möglich.

    Doch :)


    Ok :/ mit ein Paar einschränkungen.
    Du kannst nur eine limitierte Menge an Zeichen beim Namen eines TPF2-Objekts eigeben. Dort müssen alle Informationen (also Orte, Nummern usw.) und noch "Trenn- oder Steuerzeichen".

    Ich würde keine Modulare Konstruktion machen, sondern für jede Situation ein eigenes Asset machen.
    Der Grund ist dass du sonst sehr viele Bedingungen hast, was
    1. Die Regex komplizierter macht
    2. Mehr "Steuerzeichen" brauch (und Zeichen ist ein rares Gut)

    Du solltest dich auf darauf einstallen müssen eine Anleitung für deine Mod schreiben zu müssen und viele doofe fragen beantworten zu müssen (von denen die die Anleitung nicht gelesen haben).


    Die "Zauberformel" (für expr) findest du hier:
    https://regex101.com/r/yJEyjy/1

    Logik: Autobahnnummer;Ausfahrnummer;Ausfahrtort;1. Ort;2. Ort (optional); 3. Ort(optional))
    replace ist dann \\ + die Gruppennummer, die du bei 'Match Information' siehts.

  • ich werde das jetzt mal probieren ob die auch Ingame für jederman änderbar sind.

    Da leider abgesehen vom Constructionname bislang mit Bordmitteln keine Texteingabe möglich ist, würde ich vorschlagen:

    • Die Autobahnnummer wird über einen Slider-Parameter in der construction gesteuert, der Wert dann über die result.labelText der construction an das entsprechende label in der mdl weitergegeben.
    • Die Ausfahrtnummer wird nach dem gleichen Prinzip angesteuert.
    • Für die Texte der Ausfahrten bietet sich an, die Eingabe ähnlich wie die Ortsschilder von Eisfeuer zu realisieren (hab ich in einem vorigen Post mal verlinkt). Dann hätte man freie Texteingabe über den Namen der Construction. Alternativ kann man auch über mehrere Dropdowns Listen mit Städten für die verschiedenen Positionen anbieten.
  • Zumindest für Stationen wäre eine Ingame Text-Änderungen ohne Regex möglich:


    config GameScript mit UI für die Bearbeitung.

    guiHandleEvent -> id == "mainView" name == "select", param ist dann die EntityID


    Enzojz benutzt das zum Beispiel hier:

    https://github.com/Enzojz/unde…fig/game_script/entry.lua



    api.engine.system.streetConnectorSystem.getConstructionEntityForStation (oder eine andere Funktion daraus um die Parameter zu erhalten)


    Damit bekommt man den Inhalt der params.modules.
    Diese dann per UI ändern lassen und dann per game.interface.upgradeConstruction in die Konstruktion einschleusen


    In der updateFn die modules auslesen, daraus dann die labelList erstellen für das jeweilige Modell. (Das UG eigentlich zum Beispiel für Bahnsteignummern nutzt)


    Und schon hab ich wieder eine neue Funktion für meine Flexstations :D Ihr macht mich fertig mit euren Ideen, wie soll ich das alles in Code fassen... (und Modelle finden)

  • Die "Zauberformel" (für expr) findest du hier:

    Danke, dass ist mal eine hilfreiche Seite. Yoshi, EISFEUER, eis_os, ich werde Eure sehr hilfreichen Informationen beherzigen und mich mal dransetzen diese (Möglichen Varianten) zu realisieren.

    MfG elektronikfreak


    MB MSI MPG Z590 Gaming Carbon WIFI - i7-11700K - ASUS ROG STRIX OC Nvidia GTX 1080Ti 11GB - 128Gb Ram - Win10/64 - WsK - 60TB

    (Meine Screenshots dürfen weiter verwendet werden)