Hilfe für Scripter

Danke dir für das tolle Teil

Wie lade ich mir den runter glaube ich stelle mich zu blöd an

Ähm, steam öffnen, TPF2 auswählen, Mod suchen und abonnieren klicken?

Ich möchte nicht die Freude trüben, aber:

Zitat von Yung Lenin

Once an .mdl is loaded, the random meshlabel actually becomes static. This means all instances of the same .mdl will have the same random number. However, separate .mdls with the same implementation will have a different random number applied to all its instances.

Dementsprechend ist es leider nur ein anderer Weg um eine statische "Textur" zu erhalten.

Ja ich kann den Sinn dahinter auch nicht sehen, es ist ingame nicht editierbar und es macht meine Mods abhängig von einem anderen Mod(der) wo ich keinerlei Einfluss habe.

Von daher sehe ich keinen Vorteil das in meine Mods einzubauen.

Das Problem bei TPF(2) ist, dass die mdls nur einmal zu Beginn geladen werden und somit fix sind. Für das Beispiel mit dem Autobahnschild bedeutet das, selbst wenn du via Script 10 Varianten mit unterschiedlichen Beschriftungen erstellst, wird immer nur eine im Spiel angezeigt. Es sei denn du erstellst pro Variante eine eigene mdl...

Gleiches gilt für Fahrzeugnummern. Das Script kann dir zwar zu Spielbeginn eine zufällige erzeugen, jedoch werden Fahrzeuge gleichen Typs weiterhin auch die gleiche Nummer tragen. Daher kann man sie auch direkt auf die Textur schreiben.

Zitat von elektronikfreak

Ich hatte mir den Scriptfetzen aus der letzen Zeile unten vom WiKi Labellist typ "CUSTOM" angeschaut, leider gibt es keine weiterführenden Informationen zu dieser Funktion oder deren Anwendung.

Da geb ich dir vollkommen Recht.
an den meisten Stellen ist das WIKI eigentlich gar nicht hilfreich.
So nach dem Motto, Ihr wolltet ein WIKI aber wir verraten euch nicht alles.

Dann lest euch eben auch alles durch.

https://www.transportfever2.co…ourcetypes:mdl#label_list

Ansonsten gilt:

https://www.transportfever2.com/wiki/doku.php?id=contribute

Mir ist immer noch nicht ganz klar, was du erreichen willst.

Mehrere Labels für ein Modell sind ja möglich, einfach mehrere Blöcke in die labels-Liste in der mdl packen.

Diese verschiedenen Labels aus der Construction individuell zu bespielen ist auch möglich, indem in dem von dir zitierten Codeschnipsel eben in der labelText-Liste mehrere Strings nacheinander mitgeliefert werden. Wie du diese Liste fütterst ist dir in der updateFn selbst überlassen.

Damit sollte der Anwendungsfall der Autobahnschilder ausreichend abgedeckt sein.

Ein weiteres Beispiel aus der Praxis das in die selbe Richtung geht kannst du dir hier anschauen: Ortstafeln aus Österreich. Da werden die Texte allerdings direkt in der mdl aus dem Namen der Construction übernommen und entsprechend gefiltert.

Der Mehrwert von weiteren LabelList-Blöcken in der mdl erschließt sich mir nicht. Unter welchen Gesichtspunkten soll da welcher genutzt werden?

Der immer wieder gefallene Begriff statisch heißt in diesem Zusammenhang übrigens nicht, dass sich das Modell nicht bewegt, sondern dass die Informationen, die in der .mdl-Datei codiert sind, sich auf alle Instanzen dieser mdl-Datei beziehen.

Zitat von elektronikfreak

Und die Frage, warum es zu diesem Teil des WiKi kein/e Beispiel/e gibt wurde bis jetzt nicht beantwortet.

Das Wiki ist primär erstmal als eine technische Referenz der möglichen Werte/Parameter etc zu sehen und nicht als Sammlung funktionsfähiger Beispiele. Unter diesen Gesichtspunkten wurden im Rahmen der Erstellung die Inhalte priorisiert. Möglicherweise werden in Zukunft weitere Beispiele ergänzt.

Und was hindert dich daran, alles in eine LabelList zu packen? Die Labels einer Labellist können räumlich absolut unabhängig sein. So wird es ja z.b. bei den Bussen gehandhabt.

Ich würde es versuchen so zu lösen:

modulare construction -> basisslots für die Schilder (also man klebt da ein Schild auf die Schilderbrücke)

Jedes Schild erzeugt X Zeilen als Modulslots

Da kann man dann ein Zeilen Modul draufpappen: Namen, Ausfahrtsummern, Pfeile.

Das ist jeweils eine Instanz eines mdl mit Label.

Die Daten muss dann in die labelList der Konstruktion updateFn:

Um den Text zu erstellen, gäbe es dann eine UI mit Texteingabe und würde dann via commonapi native sync vom UI Thread zum Konstruktionsthread gemeldet.

Beim hinzufügen des Moduls an den Slot würde dann mit ein bisl mehr eis_os Kreativität, der eigentliche Text pro Modul als metadaten des Moduls gespeichert(preProcessFn) werden und bei späteren updateFns wieder genutzt...

eis_os

dein Ansatz ist zwar löblich aber auch mehr von hinten durch die Brust ins Auge, nur weil im WIKI etwas suggeriert wird, was im Spiel dann doch nicht geht.
Hier müsste normalerweise UG die richtige Funktion zur Verfügung stellen. Ich weiß es wird nicht so schnell oder nie geschehen.
Ich haben eine Möglichkeit gesucht, die skipCollosion als Funktion zu nutzen, dabei bin ich auf Artikel gestoßen, die weit ins Jahr 2017 zurückreichen, wo dies auch schon besprochen wurde.
Seit her ist in beiden TpF Versionen dies nicht berücksichtig oder je geändert worden.
Somit kann man sagen, dies sind Wunschfunktionen die jeden von uns gefallen würden aber für nicht wichtig genug bei UG betrachtet werden.

Zu Thema WIKI und Erklärungen. Den technischen Inhalt der con, mdl und sonstigen Dateien erklären ist das Eine, dies ist ja auch gemacht.
Ein Wiki sollte aber mehr sein als nur die rein technische Erklärung. Hier sind Code Beispiel zwar schön aber mit Beispielen wie sich etwas dann im Spiel auswirkt, wäre für alle, die neu mit dem Erstellen von Mods beginnen, viel hilfreicher.
Viele tun sich einfach leichter (ich zähle mich auch dazu), sich an einem einfachen Beispiel das Thema(Kapitel) zu erarbeiten.
Nur die reine technische Erklärung hilf am Anfang wenig.

Als Ende der 1980er Jahre die Programmierung (Basic,Fortran,Pascal) erlernt habe, hatten wir auch immer ein Beispiel wie es am Ende aussehen oder funktionieren sollte und dann wurde genau daran erklärt wie es geht.
So hat man relativ schnell Zugang gefunden. Nur rein die LUA Sprache zu beherrschen hilft nicht wirklich, wenn man icht weiß ob dies überhaupt vom Spiele Interpreter auch verstanden wird.

So das soll es mal gewesen sein zum Thema WIKI.

elektronikfreak z.b. der eCitaro aus dem Vanillaspiel. Der hat eine Liniennummer hinten, ein Feld an der Seite und ein Feld vorne dran (oder sinds sogar 2?). Alle verschieden positioniert, verschieden gefiltert usw.

guapo298 ich frage nochmal explizit: Was wird im Wiki suggeriert, das im Spiel nicht geht? Ohne das genau benannt zu haben kann man das nicht ändern.

Bezüglich der Dokumentation vs. Tutorial Thematik habe ich oben eigentlich schon das meiste gesagt. Tutorials sind nicht Teil des primären Konzepts für das Wiki. Gegebenenfalls wird es aber in Zukunft dafür auch andere Lösungen geben.

Zitat von Yoshi

guapo298 ich frage nochmal explizit: Was wird im Wiki suggeriert, das im Spiel nicht geht? Ohne das genau benannt zu haben kann man das nicht ändern.

ich bin der Meinung, dies könnte besser Dokumentiert sein

https://www.transportfever2.co…tructionbasics#label_list

man kann nicht genau erkennen wo es eingetragen werden soll, ich hab da ein zwei Kontakte, die haben dies auch x Mal gelesen und probiert aber nichts klappt.

Ich bin auch am Anfang davon ausgegangen, dass der Tooltip zum Beispiel sich auf den uiType auswirkt und man so beim uiType "ICON_BUTTON" je Bild einen Hovertext erzeugen kann

dem ist leider nicht so, der Tooltip wirk sich nur aif die Property "name" aus, wen man aber x-y Bilder hat, dann geht eh keiner auf die Überschrift sondern zeigt mit der Maus auf das Bild und dann kommt eben kein Tooltip.

Wenn ich weiter suche finde ich bestimmt auch noch andere Beispiele.

Ich ma aber gar nicht weiter suchen wollen.

Zitat von guapo298

man kann nicht genau erkennen wo es eingetragen werden soll

Die nächst größere Überschrift oben drüber ist die updateFn. In deren Beschreibungstext unter https://www.transportfever2.co…nstructionbasics#updatefn steht, in welchem Konstrukt die unten drunter stehenden Elemente eingefügt werden sollen:

Zitat

The updateFn returns a data struct with several mandatory and many optional properties. They are described below. Please note, that the return data struct is referred as result.

Das zweite Beispiel ist meines Erachtens bereits eindeutig im Wiki beschrieben.

Zitat von guapo298

der Tooltip wirk sich nur auf die Property "name" aus

steht so quasi wortwörtlich in der Beschreibung die du rot eingerahmt hast. Damit das aber in Zukunft noch klarer ist, wurde der beschreibende Text zu den Icon Buttons nun entsprechend ergänzt: