Assetsymbole bei der Assetsuche hervorheben.

Alles wäre so einfach, wenn sich die Modder auf einheitliche Symbole verständigen würden. Doch es ist leider so wie in der Politik: Jeder zieht sein eigenes Ding durch. 🤬

---

Edit: Obiges hatte ich vom Handy auf kommentiert.

Damit ich vom "Oberaufseher ( )" keinen Anschiß wegen Doppelpost bekomme, hier eine Ergänzung von mir:

* Wieso wurde "nicht modbar" eingestellt?

Manuell ändere ich alle Mods in der con-Datei unter "categories =" in mein eigenes Schema ab. Die dazugehörenden tga-Bildchen habe ich unter "res/textures/ui/construction/categories/..." in einer Mod hinterlegt. Dafür habe ich Bezeichnungen festgelegt, die nicht mit den "amtlichen" Bezeichnungen von Vanilla übereinstimmen. Für jede Bezeichnung gibt es somit ein eigenes Icon. Aktuell sind es 27. Manche Mods können auch 2 oder mehr Zuordnungen enthalten.

Warum sollte dies nicht in einer Mod umsetzbar sein?

Ich kann mir folgende Vorgehensweise für eine Mod vorstellen:

* Es wird hier im Forum eine Umfrage erstellt, welche Bezeichnungen und Symbole gewünscht werden.

* Diese Vorschläge sind dann als Standard in einer Definitions-Mod enthalten.

* Jede heruntergeladene Mod, ob alt oder neu, kann mit der Definitions-Mod überprüft werden.

* Sollten die "categories ="-Daten in der zu prüfenden Mod nicht in der Definitions-Mod enthalten sein, kann der Anwender diese Angaben durch die Auswahl der Inhalte in der Definitions-Mod ersetzen.

Es gibt hier im Forum Modder, die schon wesentlich kompliziertere Script-Mods erstellt haben. Vielleich erbarmt sich einer mal für dieses Thema.

Die Probleme sehe ich in den Steam-Mods. Die können jederzeit von Steam geändert werden. Genau so, wie plötzlich Mods auf Steam verschwinden. Da sollte man sich drüber im Klaren sein und die Steam-Mods in das eigene Mod-Verzeichnis übernehmen und dann diese Mod von der Definitions-Mod überprüfen lassen. Das wäre damit auch lösbar.

Trotzdem: Ein erster Schritt wäre, wenn sich die Mod-Ersteller hier im Forum auf eine einheitlich Vorgehensweise einigen könnten und nicht jeder sein eigenes Dingen durchzieht. Damit wäre schon viel geholfen. Dann bliebe nur noch das Problem mit Steam.

Das wäre keine ganz kleine Aufgabe.

Erstens: Welche Kategorisierung ist gewünscht? Bevorzugt man eine nach Typ der Assets? Dann ist es sinnvoll, den Haufen mindestens in Fahrzeug, Gebäude, schienenbezogene (schnappbare) Assets und Dekorationen aufzuteilen. Für manche Spieler reicht das, andere benutzen eine zu große Anzahl von einer einzelnen Kategorie, und würden deswegen zum Beispiel die Fahrzeuge noch gerne in LKW, PKW, Dienstfahrzeuge, Flugzeuge, Schienenfahrzeuge, Anhänger etc. aufgespalten haben. Oder ist es besser, die Assets nach Ära zu trennen? Wie wäre es mit einer Sortierung nach Modersteller, die ja auch alle eine mehr oder weniger enge Spezialisierung haben? Möglich und zu argumentieren wäre jede dieser Methoden, und bei jeder gibt es auch Gegenargumente.

Zweitens: Ein Asset besteht bekanntlich mindestens aus einer .con, die auf verschiedene .mdls zugreift. Nicht in jeder dieser Dateien sind nutzbare Markierungen enthalten, die man zur Kategorisierung auslesen kann: die Assetifizierung meiner Flugzeuge erfordert zum Beispiel die Entfernung des ganzen Blocks "transportVehicle={...", in dem ´CARRIER = "AIR"` drin steht, was wiederum die .mdl erst zu die eines Flugzeugs macht.

Man könnte natürlich statt dessen die Verzeichnisse der Meshes oder Materialien inspizieren: wenn "/plane/" drin vorkommt, dann dürfte es sich auch ohne "carrier = air" um ein Flugzeug handeln und man könnte die Kategorie entsprechend einer noch zu definierenden Norm festlegen. Aber das erreicht auch bald seine Grenzen: wenn jemand seine eigenen Verzeichnisnamen benutzt oder überhaupt die Materialien ins Stammverzeichnis stopft (was beides prinzipiell funktioniert), dann würde so ein Skript diese Assets alle nicht auseinanderhalten können und in einen großen, unkategorisierten "Diverser Pofel"-Topf schmeißen. Dann ist auch nicht viel gewonnen. Und ob ein Gebäude jetzt eine Fabrik, eine Pflanze, eine Mülltonne oder was auch immer ist, kann man auch schwer erkennen - in diesem Fall würde sehr viel unter "Gebäude" zusammengefaßt werden.

Wenn dieser Weg gewünscht ist, dann wäre eine Konvention nötig, daß jeder Modder seine Verzeichnisstrukturen aussagekräftig tauft.

Oder man versucht, alle Mods bei Spielstart durchzugehen und eindeutig anhand von Ersteller und Name zu identifizieren, um ihnen dann halbautomatisch (anhand einer vorher erstellten Tabelle mit vielen Zeilen wie "SM1s DAF-Sattelschlepper => Moderne Lastwagen") eine Kategorie zuzuweisen. Das würde allerdings viel Arbeit erfordern, es müßte immer einer am Ball bleiben und jeden neu entstandenen Mod in diese Liste einpflegen. Und die Nutzer müßten hier auch immer neue Updates ziehen, um auf dem Stand zu bleiben.

Eine Vereinheitlichung wäre sinnvoll, man müßte sich nur entscheiden, welche der Optionen am wenigsten Nachteile bietet...

Jaja das alte ungelöste Thema Modordnung. Das ist eher eine der schwierigsten Aufgaben, die wahrscheinlich kein einzelner Modder schnell mit einem Skript löst.

P8_2401_Coeln

Die Idee ist eigentlich ganz gut, scheitert aber schon am 1. Punkt. Versuche mal eine Umfrage zu machen und dann zu einer Entscheidung zu kommen, die allen gefällt.

Das andere Problem ist die fehlende "Updatefestigkeit", wenn manuelle Änderungen der categories Daten vorgenommen werden.

Wie DH-106 schon erklärt, ist eine Automatisierung hier schwierig.

Was OP eigentlich will, ist aber gar nicht mal soo schwer, wenn ich es richtig verstehe nur eine Markierung des Kategorie Symbols bei Nutzung der Suchfunktion. Pauschal würde ich die Modbarkeit auch nicht sofort ausschließen. Zumindest hat eis_os die Dateinamen zur Beschreibung hinzufügen können, die Kategorie könnte man bei Assets auch noch dazuschreiben lassen.

Wenn es darum geht, die Datei(namen) von bereits verbauten Assets / Konstruktionen zu ermitteln, hilft Advanced Statistics weiter.

Ehm, die Anzeige des Dateinamen bzw. der technischen Daten wird durch ein eigenes Popup durch CommonAPI2 gelöst,

Ja Kategorien könnte ich da auch noch Anzeigen, ein bisl viel Info vielleicht. Ohne CommonAPI2 Dll geht so etwas nicht.

Das Hinzufügen von Daten in ein UG Popup führt zum Spielcrash.

Auch müsste ich kurz ein Highlight machen können um die Filter Buttons zu markieren,

es können halt mehrerer Kategorien sein, in der so eine Asset oder Gleis oder was auch immer drin ist.

Als externes Mod wäre mir das aber zu viel Aufwand. Als CommonAPI2 Zusatz können wir darüber reden...

-edit-
Bevor hier wieder jemand meckert, warum dll und so gebraucht wird:

UG bindet keine Popup API, auch kommt man mit Bordmitteln nicht sicher an eine UI Liste der Konstruktionsliste ran.

Die neue Konstruktionsliste von CommonAPI2 nutzt ne Menge an eigenen UI LUA Bindings:

Aus commonapi._native.UIHacks

getUIListFrom, getImageViewImage, showPopupMenu, removeAllPopupMenus, setTextViewMaxSize

Also Kategorie Anzeige für mdls, cons, track und street configs ist schon mal drin. (Und ja, zeigt auch mehrere Kategorien schön mit Komma getrennt an)

Problem ist dafür eine Übersetzung zu bekommen, wenn die Kategorie aus einem Mod kommt...

eis_os bei Mod-Kategorien werden derzeit ja u. a. auch die Namen der Mod-Ersteller verwendet. Z. B. categories = {"Ingo 1111"},

Reicht das als Hilfe aus?

Für jede con-Datei gibt es auch noch ein Icon:

Läßt sich da noch etwas machen?

Was möchtest du mir sagen? Ich kann dir nicht ganz folgen. Natürlich zeigt CommonAPI2 alle Mods an oder was meinst du? Und es wird nicht der Namen des Mod Erstellers genutzt, sondern das was in categories = { "hierwasvommodersteller" } geschrieben wurde.

TPF2 hat keine getTooltip Funktion gebunden, wenn es die überhaupt gibt...

Sprich ich habe zwar die id(s) aus categories, brauche dafür halt eben die Übersetzung. Wobei ich mich gerade Frage, ob UG überhaupt Übersetzungen für Kategorien unterstützt, außer den Kategorien die UG schon eingebaut hat

-edit-

OK, geht sowieso nicht, typisch UG...

Zitat von eis_os

Was möchtest du mir sagen? Ich kann dir nicht ganz folgen. Natürlich zeigt CommonAPI2 alle Mods an oder was meinst du? Und es wird nicht der Namen des Mod Erstellers genutzt, sondern das was in categories = { "hierwasvommodersteller" } geschrieben wurde.

Sorry, ich habe mich wohl nicht klar genug ausgedrückt. Es geht schon darum, was in den categories = { "hierwasvommodersteller" } steht, denn da wird immer öfter der Name des Mod-Erstellers (evtl. in abgekürzter Form) verwendet (siehe oben Beispielbilder).

Zitat von eis_os

OK, geht sowieso nicht, typisch UG...

Schade. Trotzdem danke für deinen Einsatz und deine Bemühungen.

Die nächste CommonAPI2 wird:

• Categories als Info zeigen
• UG Übersetzungen anzeigen, keine Mod Übersetzungen, kann TPF2 nicht.

Vielleicht wird es noch so etwas geben:

Ist das aber leider zurzeit zu aggressiv weil es ständig blinkt...

Auch wenn es schon was länger her ist,

die Funktionen sind in der heutigen release der CommonAPI2 20221120 veröffentlicht.

Sprich Suche nutzen, auf ein Asset klicken und alle Kategorien in dem das Asset steckt werden angezeigt durch einen Kasten um das Icon:

Wie man selber Assets in eine Gruppe packen kann steht übrigens hier:
https://www.transportfever.net….2-Modelle-mdl-Gruppieren

Welches Asset den? Hat es ggf. gar keine Kategorie definiert?