TPFMM - Transport Fever Mod Manager

**Xanos** · 23. Januar 2019

Hmmm, ein sogenanntes major update (die erste Versionsnummer wird erhöht) sorgt dafür, dass es einen anderen ordnernsmen gibt. Eng betrachtet ist es damit eine neue Mod. Im Spiel wird die Version 1.1 ausgeblendet, aber weiterhin als eigene mod behandelt.
Das Spiel muss sich aber auch nicht darum kümmern, ob evtl eine neue Version vorliegt.

Bei der Suche nach neuen Versionen wird der ordnername als Vergleichsmerkmal herangezogen. D.h. Wenn TPFMM aktuell nach Updates für irgendeine_mod_1 sucht, wird irgebdeine_mod_2 nicht entdeckt.
Evtl muss ich TPFMM so anpassen, dass eine neue Version auch für andere ordnernamen prüft, aber diese nur dann angezeigt wird, wenn online eine höhere Versionsnummer vorliegt, aber keine höhere major-Version installiert ist....
Alles bissl blöd, und ehrlichgesagt nervt mich dieses Mod-Namen system und ich hoffe inständig, dass UG das für einen Nachfolger anpasst.

P.S.: falls beide Versionen in einem Downloadeintrag in der webdisk liegen, müsste für v1.x dauerhaft ein Update (auf v2.x) angezeigt werden, aber immer wieder nur v1.x heruntergeladen werden....

Marcolino26 · 23. Januar 2019

Da kann man den Müll mit den Versionsnummern und major Update auch gleich streichen

elektronikfreak · 23. Januar 2019

Erhalte beim Laden eines Savestandes (egal welcher) folgende Fehlermeldung:
Bei mir gibt es kein Laufwerk E:

**Xanos** · 23. Januar 2019

Das ist der Pfad zur Quellcode Datei, damit ich weiß wo der Fehler auftritt, danke für die Meldung.
Bei Problemen mit Spielständen hilft es auch weiter mir den Spielstände (soweit möglich) zukommen zu lassen. Grose Dateien kann man zb über wetransfer.com senden.

Farnsworth · 24. Januar 2019

Zitat von Xanos

Wenn TPFMM aktuell nach Updates für irgendeine_mod_1 sucht, wird irgebdeine_mod_2 nicht entdeckt.

Das ist mir letztens leider auch aufgefallen... Gott weiss wie viele major Updates ich fuer einen Mod nicht mitbekommen habe deswegen Wollte grad mal fragen, wie der Rest von euch sowas handhabt? Wenn das irgendwie im TPFMM eingebaut werden koennte, waer das natuerlich ein sehr willkommenes Feature in einem eh schon unverzichtbarem Tool

EAT1963 · 24. Januar 2019

irgendeine_mod_2 ist ein anderer Mod als irgendeine_mod_1 und KEIN Update von irgendeine_mod_1.

Möchte ein Modder ein Update eines bestehenden Mods veröffentlichen, so MUSS er die Minorversion in der mod.lua erhöhen und nicht die Majorversion.
Erhöht er stattdessen die Majorversion, so handelt es sich um einen neuen Mod. Ist dies beabsichtigt so würde ich einen neuen Eintrag in der Webdisk empfehlen.

Der TPFMM sollte auf keinen Fall bei Erhöhung der Majorversion ein Update erkennen, da es sich eben um kein Update handelt!!!

Es sollte also jedem Modder bewusst sein, wie die Dinge gehandhabt werden (sollen) und ob sein Update ein Update oder ein neuer Mod ist.

LG Enno

**Yoshi** · 24. Januar 2019

Entsprechend verwendete ich bei der Konvertierung des Type G für Transport Fever auch die Endung _2, da sie nicht unmittelbar als Update des TF-Modells galt.

(Um das ganze mal mit nem realen Beispiel auszuführen)

**Xanos** · 24. Januar 2019

Zugegebenerweise habe ich nicht mehr großartig über major-Version Updates nachgedacht, nachdem ich mich monatelang mit den ************ Ordnernamen als Identifikationsmerkmal herumgeschlagen habe.

Zur Verwaltung in TPF:
Das Spiel erkennt Mods am Ordnernamen (irgendeine_mod_1), speichert in einem Spielstand dann aber zum Beispiel irgendeine_mod und Version = 1 einzeln. Ganz verrückt wird es dann natürlich, wenn es noch einen Ordner gibt, der tatsächlich irgendeine_mod heißt. Das löst das Spiel intern mit einer versionsnummer von -1
Was passiert wohl, man einen Ordner irgendeine_mod_-1 nennt? (Ich kann es grade nicht testen )

Zur Verwaltung in TPFMM:
Intern unterscheidet der TPFMM die mods nach einer "ID". Diese ist an sich gleich dem Ordnernamen, außer es handelt sich um Workshop oder Staging-Area Mods. Dann kommt noch ein Prefix dazu. Workshop Mods haben einen *, Staging Area Mods ein ? (auch von TPF übernommen).

Bei einem Update wird die Onlinedatenbank nach Ordnername durchsucht, falls keiner gefunden wird nach eventuell vorhandenen Informationen zur Quelle (zB aus der mod.lua oder TPFMM-intern). Damit sind (wie von UG ursprünglich mal definiert) irgendeine_mod_1 und irgendeine_mod_2 komplett separate Mods. Zwar sind es für TPF nicht ganz unterschiedliche Mods, sondern eine inkompatible neue Version, aber es ist sehr nah dran.

Zum Update:
Man könnte also sagen, ich habe bei der Wahl der ID mist gebaut.
Aber ich habe nun ein mal das Merkmal der Mod genommen, was rein technisch einzigartig ist, und welches in TPF auch als entsprechende Unterscheidung benutzt wird. 2 Mods mit gleichem Odnernamen können eben rein technisch nicht existieren
Das UG diese Information trennt und die Kombination aus Name und Version als Alleinstellungsmerkmal nutzt ist halt einfach blöd für mich in dem Fall...

Was nun?
Ich kann versuchen, es so umzubauen, dass ich intern die Zahl am Ende vom rest des Namens trenne, und auch die im Online-repo hinterlegte Information entsprechend aufteile und einzeln betrachte. Es gibt dann leider zwar auch den Fall, dass Mods, die rein zufällig auf eine Zahl enden aber nicht TPF-Konform sind fälschlicherweise erkannt werden, oder Mods im Online-Repo falschen anderen Mods zugeordnet werden...
Müsste ich einfach mal testen.
Wenn möglich, könnte TPFMM so immerhin zwischen einem "normalen" und einem "Major-" Update unterscheiden.
In jedem Fall sind es wieder sehr viele zusätzliche Zeilen Code und viele potentielle Fallen für neue Bugs. Zusätzlich ist leider das Format der Webdisk-Einträge hier auch nicht sonderlich hilfreich (mehrer Dateien pro Eintrag mit nur einer Versionsnummer, etc...).

Es lässt sich (korrekterweise) argumentieren, dass _2 kein Update von _1 ist, da die beiden Versionen per Definition inkompatibel sind.
Andererseits ist es natürlich trotzdem ein Update, wenn eben auch inkompatibel.
Daher gebe ich natürlich zu: Das TPFMM ein Major-Update nicht korrekt erkennt bzw aktualisiert ist unpraktisch!

Die Frage ist, wie wird/wurde es in der Realität gehandhabt?
Wenn eine Vielzahl an _2 mods in Wirklichkeit (kompatible) Updates der _1 Version sind, sollte TPFMM das auch erkennen.[/tt]
Entweder ich bin der Programmierer der Finsternis ( ) und sage hart: _1 und _2 sind unterschiedliche Mods und werden nicht als Update erkannt.
Oder ich beiße in den sauren Apfel und baue eine Erkennung ein
Hier könnte man ja wie oben erwähnt zwischen "normalen" und "major" Update unterscheiden.
Nur frage ich mich: warum zum teufel hat UG diese Unterscheidung überhaupt eingebaut?
Im dem Steam-Workshop System, welches sie selbst implementieren mussten, wird danach ja auch nicht unterschieden. Update ist update und wenn sich der Ordnername ändert ist es eben eine ganz neue Mod!
Aber ich muss mich mit dem Mist natürlich rumschlagen!!!

Ich bin aber mal so frei und sage: Wenn sich da beim Nachfolger nicht was grundlegendes ändert und wir (UG, Community, und Forum als Quelle für viele Mods) kein funktionierende, eindeutiges System zur Verwaltung auf die Beine stellen können, weiß ich nicht ob ich noch eine neue Version von TPFMM machen werde...

elektronikfreak · 24. Januar 2019

Nun, leider kommt noch hinzu, dass es keine einheitliche Konvention für die Festlegung der Versions- oder ID Nummern gibt, wenn doch, halten sich nur wenige Modder daran. Zumal sich bei Repaint's zu einem Mod auch die ID ändern müsste und nicht die gleiche sein sollte wie der Hauptmod wie bei wenigen Steam-Repaint's der Fall.
Ist schon eine weile her, da konnte der Tpfmm auf Grund der gleichen ID den Hauptmod nicht vom Repaint unterscheiden, dass klappt jetzt bisher ganz gut.

Bei 1540 geladenen Mod's können schon mal ein paar Unstimmigkeiten auftreten, da auch viele User noch mit TF-Mods hantieren.

Farnsworth · 24. Januar 2019

stimmt, @EAT1963 und @Yoshi, da habt ihr Recht. Und es ist tatsaechlich eigentlich keine Aufgabe des TPFMM, sondern die der Modder, sich an die Konvention zu halten. Als User ist es leider unmoeglich den Ueberblick ueber hunderte von Mods zu behalten, falls sich mal wer nicht dran haelt. Und einen neuen Eintrag in der Webdisk fuer eine neue major Version waere natuerlich eine gute Vereinbarung, wenn sich jeder dran haelt
Was der TPFMM auf der anderen Seite machen koennte (sofern technisch umsetzbar), waere den User zu benachrichtigen, wenn bei einer Mod ein Ordner hinzugekommen ist und den User dann fragt, ob dieser zusaetzlich installiert werden soll. Die korrekte Deinstallation der alten Version (sprich: im Spiel alte deaktivieren, neue aktivieren, Spielstand laden und speichern, dann alte loeschen oder was auch immer) kann man in den spezielfaellen dann ja auch von Hand durchfuehren. Sowas aehnliches in einer leicht anderen Variante hat @Xanos oben aber glaub ich auch bereits angesprochen.

**Xanos** · 24. Januar 2019

Zitat von Farnsworth

Was der TPFMM auf der anderen Seite machen koennte (sofern technisch umsetzbar), waere den User zu benachrichtigen, wenn bei einer Mod ein Ordner hinzugekommen ist und den User dann fragt, ob dieser zusaetzlich installiert werden soll.

Klingt auf jeden Fall interessant und zumindest theoretisch machbar. An welchen Details ich dann in der Umsetzung hängen bleibe sehe ich wenn es soweit ist

Im Zuge davon würde ich mich vielleicht auch dazu zwingen, die Kollision von Ordnernamen abzufangen und aufzulösen.
Es gibt leider einige Mods in den Online-Quellen, die den selben Ordnernamen haben und manchmal ist es etwas Glück, welche Mod dann wirklich heruntergeladen wird in diesen Fällen.

EAT1963 · 24. Januar 2019

Zitat von Xanos

Entweder ich bin der Programmierer der Finsternis ( ) und sage hart: _1 und _2 sind unterschiedliche Mods und werden nicht als Update erkannt

Da bin ich gaaaanz klar für die "Finsternis"-Version.

Zitat von elektronikfreak

Nun, leider kommt noch hinzu, dass es keine einheitliche Konvention für die Festlegung der Versions- oder ID Nummern gibt

Doch, die gibt es in Form einer Vorgabe durch UG. Ordnernamen von Mods (außer Steam) sollen!!! folgenden Aufbau haben: Username_Modname_Majorversion.

Zitat von Farnsworth

Und es ist tatsaechlich eigentlich keine Aufgabe des TPFMM, sondern die der Modder, sich an die Konvention zu halten.

So ist es.

[line][/line]
Wir hatten hier schon einmal eine recht unangenehme Diskusion zum Thema Ordnerbenennung.
Mein Standpunkt dazu: Es gibt keine Diskusionsgrundlage zur Benennung der Ordnernamen sondern glasklar die Vorgabe von UG!
Da brauchen wir auch keine end- und sinnlosen "Meetings" mit abschließendem "Klärungsbedarf" abhalten, sondern einfach die Regeln beachten.

Da ich schon einige, kleinere Mods veröffentlicht habe kann ich aus "Erfahrung" sagen: Sooo schwer ist das nicht.

elektronikfreak · 24. Januar 2019

Zitat von EAT1963

Da ich schon einige, kleinere Mods veröffentlicht habe kann ich aus "Erfahrung" sagen: Sooo schwer ist das nicht.

HoratioCaine · 24. Januar 2019

Ich möchte nur hinzufügen, dass die Steam-abonnierten Mods am Ende ebenfalls eine _1 erhalten, mithin die Systematik erhalten bleibt. Daher halte ich es mit @EAT1963, es liegt in der Verantwortung der Entwickler. Und der Vorschlag des Hinweises, bei einer Mod mit höherer Majorversion, ist auch ganz gut. Aber bitte nicht noch die leider sehr häufig fehlenden Informationen in den mod.lua noch durch eine Programmierung optimieren. In der Liste meiner Mods sehe ich so viele Mods mit roten Pfeilen und Ausrufezeichen, dass ich schon reflexartig den dicken ALL-Button drücke und erstmal alles prüfen lasse.

@Xanos
Wenn ich die betreffenden Mods, deren mod.lua nicht richtig ist, korrigiere, habe ich dann solange Ruhe, bis tatsächlich eine neuere Version rauskommt?

**Xanos** · 25. Januar 2019

@HoratioCaine So sollte es zumindest sein, ja.
Aber ich werde (bzw muss) wohl noch einbauen, dass man für eine installierte Modversion einmalig updates ignorieren kann o.ä. Auch da muss ich einfach mal schauen, wie sich das am sinnvollsten lösen lässt

Fyng · 26. Januar 2019

Zitat von elektronikfreak

Erhalte beim Laden eines Savestandes (egal welcher) folgende Fehlermeldung:
Bei mir gibt es kein Laufwerk E:

Hallo,
bekomme leider ebenfalls diese Meldung. Da ich eh meinen Rechner neu aufsetzen musste, habe ich gleich mal die Gelegenheit genutzt. Selbst wenn Steam Transport Fever gerade frisch installiert hat kommt diese Meldung bei mir. Ich kann den Mod Manager einmal starten, er zieht sich auch die Verzeichnisse richtig. Wenn ich ihn dann ein zweites Mal starte, kommt eben diese Meldung.

Von meiner Seite aus kann ich sagen, dass es wohl nichts mit heruntergeladenen Mods zu tun hat.
Edit: der "alte" mod Manager Ver. 1.0.39 funktioniert übrigens ohne Probleme
Edit: kleiner Nachtrag. Ich kann den Mod manager momentan nicht mal mehr starten. Die Zahnradanimation läuft kurz an und dann kommt der Fehler. Hier der Dump dazu:

Please provide the following information at
TPFMM - Transport Fever Mod Manager
Copy the whole file content in the text box, or attach the .txt file directly.

[code]
################################################################################
ERROR @ 2019-01-26_14-58-18
TPFMM v1.1.58 b5264 Win {f9bd1ffb3da1aa9b26b177d7b7d6ea65}
"Invalid memory access"
-1073741819@5369325050>97947648
E:\projects\PB\TPFMM\source\module_mods.pbi line 1147
OS: Windows 10 on Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz (x8)
Available Physical Memory: 5224 MiB / 16320 MiB
Available Virtual Memory: 134213371 MiB / 134217727 MiB
Available Swap: 2671 MiB / 24278 MiB
################################################################################

log:

animation:: load ani file "images/logo/logo.ani" #35394104
animation:: loaded ani file in 21 ms
windowMain:: navBtnMods()
animation:: load ani file "images/logo/logo.ani" #35394184
animation:: loaded ani file in 21 ms
main:: - game directory: D:\Spiele\Steam\steamapps\common\Transport Fever\
main:: reset main window location
main:: window location valid on desktop #0
main:: set window location: (1546, 36, 800, 859)
mods:: loaded 16 mods from mods.json
mods:: scan mods folder {D:\Spiele\Steam\steamapps\common\Transport Fever\mods\}
mods:: scan workshop folder {D:\Spiele\Steam\steamapps\common\Transport Fever\..\..\workshop\content\446800\}
mods:: scan staging area folder {D:\Spiele\Steam\steamapps\common\Transport Fever\userdata\staging_area\}
mods:: check for removed mods
mods:: found 643 mods in folders

**Xanos** · 26. Januar 2019

Danke @Fyng für die Fehlermeldung, es ist ein ganz anderer Fehler als bei @elektronikfreak. TPFMM stürzt beim öffnen eines Vorschaubildes einer Mod ab.
An dieser Stelle hat sich seit langem nichts mehr geändert, daher bin ich etwas verweundert, dass die "alte" TPFMM Version funktioniert, die neue aber nicht.
Leider kann ich an der Bild-Lade-Funktion sowieso nichts ändern, da diese Funktion von einer externen Bibliothek zur Verfügung gestellt wird.

Eventuell löst sich der Fehler aber auch bei der nächsten Version automatisch, da ich dort eine neuere Version der Bibliotheken beim kompilieren benutze.

**MaikC** · 26. Januar 2019

Wie sieht eigentlich dein Zeitplan aus bis zur Releaseversion? Größere Änderungen willst dann ja sicher nicht mehr machen.

Es ist so, ich hab mir lieber wieder die alte Version installiert das neue Interface gefällt mir gar nicht. Nur 5 Mods werden angezeigt (weil das Bild jetzt links mit angezeigt wird) dann muss man schon scrollen.
Das Vorschaubild, die Buttons für Update, Modeinstellungen usw. in einem extra Tab rechts fand ich viel besser und übersichtlicher wie diese integrierte Lösung. Sicher etwas was man über eine alternative UI lösen könnte aber ich kann verstehen wenn du das nicht möchtest.

StepStylexD · 28. Januar 2019

Hier nen Kleiner BUG: Wenn ich etwas Filtere(Suche) und dann im Hauptfenster etwas auswählen will, schließt er den Filter und Minimiert TPFMM.

Noch ein Bug: Ich muss mehrmals auf die Icons in der liste klicken bis sie reagieren.

Zum System:
TPFMM nutzt 0,4% der ressourcen meines PCS (Schwacher PC also ausgeschlossen)
Windows 10 auf Aktueller version

Marcolino26 · 28. Januar 2019

Das mit dem Filtern war in der alten Version auch. Gefühlt bei jeder zweiten Suche schmierts ab.

TPFMM - Transport Fever Mod Manager

Willkommen in der Transport Fever Community

Teilen