Hilfe für Scripter

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)

Hab den Thread erst heute gesehen.

Zum eigentlichen Problem:

Zitat von elektronikfreak

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.

Zitat von elektronikfreak

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 Ihr macht mich fertig mit euren Ideen, wie soll ich das alles in Code fassen... (und Modelle finden)