[ModManager] TFMM - Train Fever Mod Manager

Willkommen in der Transport Fever Community

Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.

 

Die Registrierung und Nutzung ist selbstverständlich kostenlos.

 

Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.

Das Team der Transport-Fever Community


    Es ist halt die Frage, wie weit man das aufsplitten will und wie viel die Modder bereit sind, an Metadaten einzutragen. Ich würde alle Angaben als freiwillig für den Modder sehen. Ihr Modder "arbeitet" ja auch freiwillig für uns.


    Wenn man lustig ist, kann natürlich auch ein Feld für die Bahngesellschaft machen, in dem man dann wieder Vorgaben macht (muss da "DB" stehen oder "Deutsche Bundesbahn"?). Ebenso gibt es ja auch Fantasie-Züge wie beispielsweise im Iron-Horse Mod.
    Weitere Felder könnten auch sein, ob es sich um einen Dampf-, Elektro- usw. -zug handelt. Die Kategorien aus dem Downloadportal hier auf train-fever.net wären ein guter Anhaltspunkt. Nicht jeder (incl. mir) hat alle Baureihen auswendig drauf...

    Zitat von DasMatze

    Gute Idee doch wenn ich da an Trainz und die Tags der Community denke ... "DE", "DEU", "Deutschland", "Germany", "GER" - und schon war der Inhalt über fünf Kategorien verteilt.


    Entweder man lebt hier mit dem Chaos, oder macht Vorgaben, die einzuhalten sind. Die offizielle Abkürzung der Eisenbahngesellschaft wäre vielleicht nicht schlecht.


    Bei der Idee mit dem Chaos glaube ich, dass, wenn Jey_Bee und andere Top-Modder hier für ihre Loks vernünftige Einträge generieren, andere einfach nach folgen werden. Das bedeutet natürlich weniger Bürokratie ans Vorgaben im Mod Manager.

    Zitat von Yid

    Es ist halt die Frage, wie viel die Modder bereit sind, an Metadaten einzutragen.


    Genau das ist der Knackpunkt.
    Es gibt ja auch Modder, die sogar noch komplett auf die tfmm.ini verzichten. :/

    Ich bin nur dafür verantwortlich was ich schreibe, nicht was andere verstehen "wollen"!


    System: Windows 7 Ultimate 64bit ; AMD Phenom II X4 965 @ 3,4 GHz ; 8 GB DDR3 Ram ; GeForce GTX 660 @ 3 GB GDDR5 Ram (Treiber: 431.36)

    Zitat von CC_Johnson

    Ich seh nicht, wozu man für alles ein eigenes Feld braucht. Wenn es Tags gäbe, kann man da doch reinschreiben, was man will, Egal ob DB, DR, Deutsch oder was auch immer... Vorausgesetzt natürlich einer entsprechenden Sortierfunktion.


    Insgesamt glaube ich auch, dass weniger Bürokratie besser ist. Ein großes Feld mit beliebigen Tags wäre technisch am einfachsten, und würde deshalb wahrscheinlich am besten angenommen.
    Eine Such/Filter-Funktion wäre natürlich irgendwann mal toll, und für den Anfang wäre eine weitere Spalte in der Tabelle wahrscheinlich nicht schwer einzubauen.

    Direkten Zugriff auf die Datenbank möchte ich aus dem Grund vermeiden, dass man die fertige exe ja auslesen kann und somit zu leicht an die Zugangsadaten für den Lesezugriff der Datenbank käme. Selbst wenn ich die Zugangsdaten nicht als Klartext im Quellcode lasse, ist immer noch ein Auslesen des Speichers möglich. Eine alternative, um ohne Zugangsdaten auf die Einträge zuzugreifen wäre ein normaler Zugriff über die Webseite (http).


    Das größte Problem in der automatischen Versionskontrolle für mods ist und bleibt aber die Zuordnung "installierte Mod <-> Eintrag auf der Webseite". Nicht immer entspricht der Name der Mod genau dem Namen in der Downloaddatenbank. Manchmal gibt es auch 2 Mods mit dem selben Namen (damit kommt TFMM im Moment sowieso nicht klar). Irgendwie muss es also eine eindeutige Identifizierung geben. Dies ist essentiell für einen Versionscheck und abgesehen davon auch praktisch um 2 Versionen der selben Mod auch offline zielgenauer zu erkennen.
    Die "beste" Möglichkeit die mir da imemr wieder in den Kopf stößt ist und bleibt eine "ID". Diese könnte dann auch mit der ID des Eintrages hier in der Downloaddatenbank übereinstimmen. Dadurch wäre sowohl offline als auch beim online-Versionscheck eine eindeutige Zuweisung möglich. Allerdings erhählt man diese ID erst nach dem erstellen des Downloads. Und in der tfmm.ini muss dieser leider schon vorher stehen. Ein nachträgliches anpassen der Datei ist leider etwas umständlich, daher bin ich weiterhin offen für Vorschläge.


    Zu weiteren Feldern / Tags: Weitere Felder in Hinsicht auf Kategorien (entsprechend der Kategorien auf dieser Downloadseite) folgen auf jeden Fall. Hiermit ist schon ein mal eine grobe Einordnung möglich. Bei Tags bin ich mir noch unsicher, es wäre aber ein Möglichkeit.

    Das mit der ID ist der richtige Weg.
    Am sinnvollsten wäre es, wenn es auf der Seite ein ID-Generator geben würde, der vor dem Bereitstellen aufgerufen wird.
    Diese generierte ID müsste dann der Modder in die ini Datei und im Downloadbereich eintragen.

    Xanos:


    Folgende Variante wäre durchaus denkbar einfach:


    Im TFMM wird ein Formular eingerichtet, in der alle wichtigen und optionalen Daten für die .ini eingetragen werden können. Beim erstellen der INI wird aus dem aktuellen Unix-Timecode ein Unique MD5-Hash generiert der als Mod-ID zusätzlich in der INI mit abgespeichert wird. Diese Mod-ID wird ausgegeben und/oder direkt in den Zwischenspeicher kopiert, so dass @Stepke im Download Bereich ein weiteres Feld mit TFMM-Mod-ID anlegen kann, in der diese TFMM-Mod-ID angegeben werden kann.


    Für die Update Funktion besteht somit eine Eindeutige ID in der Datenbank und mittels eines kleinen API Zugriffs kann über eine PHP Seite die TFMM-Mod-ID übermittelt werden und dort können dann im JSON Format div. Parameter zurückgegeben werden (LastEdit, Version etc).


    Sollte ziemlich Simpel sein umzusetzen ;)

    Das ganze ist sehr kompliziert. Zudem kann dann jemand mittels dieser ID ein bestehenden Repaint durch einen eigenen ersetzen. (Ja, das halte ich durchaus für möglich, da ja schon einige hier in der Webdisk gewütet haben. Zumal sich diese TFMM-Mod-ID dann ja bei jedem Update ändern würde.


    Mein Vorschlag: Download-ID in die Mod, die der Eintragsnummer im Downloadbereich entspricht. Da man diese wie schon erwähnt nicht vorher weiß, welche ID das ist, könnte die Software solange keine ID in der tfmm.ini steht, einen passenden Mod anhand einiger Einräge "erraten":
    1) Nutzername
    2) Mod-Titel
    3) Dateiname (ggf. um mögliche Versionsnummern gekürzt)
    (1) muss zwingen stimmen. (2) oder (3) zumindest teilweise. Hat der TFMM einen passenden Mod gefunden wird die ID automatisch übernommen. Gibt es einen weiteren Fund gibt es eine Liste zur Auswahl.

    Hmm, sorry ich verstehe eure Probleme nicht, Datenbank Auth in der Exe? Wie bitte? Auf dem Server gibt es eine Repository bzw. Meta Daten zum Abholen, wie es jeder Paket Manager auch macht, dafür braucht es einen http Request und auf dem Server eine Software um die Metadaten zu erstellen, wenn man es nicht händisch macht.


    Eine eindeutige ID (vom Ersteller festgelegt) + Versionsnummer reicht in fast allen Lebenslagen aus. Wer sich nicht dran hält und fremde IDs nutzt fliegt vom Server.


    Das hat seit TTDPatch Zeiten funktioniert. (GRFID)


    Mein CIM1 ModManager hat das alles in GS(CIM) Script gemacht (außer die Datei herunterzuladen und funktioniert auf Win32/OSX/Linux):
    http://cim.bytetransfer.de/mod…/specs/mmfileformats.html


    Hierbei war ein dezentrales System, mit mehrere Quellen im Vordergrund - sogar das Hosting auf einer DropBox Quelle war dadurch möglich.


    Für meine eigenen Mods, hat ein PHP Script die .modinfos zusammen geklebt und die Repo Datei erstellt.


    .edit-
    Zusammengefasst:
    Ein Mod/Addon Paket (Zip) bekommt vom Ersteller eine eindeutige ID, und eine Versionsnummer, dies liegt dem Paket bei.


    Es gibt ein Update für ein lokales Paket, wenn die Paketquelle eine neue Datei mit der selben ID aber einer größeren Versionsnummer bereitstellt.


    Ein Update deinstalliert Paket/ID mit alter Version, installiert die neue Version.


    Eine neue Version darf sich nicht so ändern das ein Spielstand unbrauchbar wird, sonst muss es eine neue ModID erhalten.


    PS: Die Board Download ID ist nicht unbedingt statisch, da Sie im Einfluss der Board Software liegt und mit einem Update, Server Umzug oder ähnliches theoretisch anders sein kann.

    Das Problem ist nicht das system (natürlich ist eine ID vollkommen ausreichend). Eher die Quelle der ID. Der Sinn des tfmm ist es vor allem es sowohl den moddern als auch den Nutzern so einfach wie möglich zu machen. Wie habt ihr die ID-Vergabe beim CIM modmanager geregelt?


    Der erste Punkt ist die ID Vergabe. Die bereits genutzten IDs müssen irgendwo gespeichert sein, also muss eine Infrastruktur eingerichtet werden, die die IDs verwaltet und modder müssten ihre ID immer "anmelden".
    Meine (alternative) Idee war es, keine nummer als ID zu vergeben sondern einen String, der aus mindestens 2 Teilen, getrennt durch einen Punkt bestehen muss. Als Konvention wäre das Format "modder.mod", zB bei mir " xanos.tfmm". Unter der Vermutung, dass 2 Modder nicht gleich heißen oder zumindest dann nicht den selben mod erstellen.


    2. Problem:
    Um Updates abzufragen muss ein Verzeichnis bestehen und dieses Verzeichnis muss auch die entsprechenden Mods enthalten. Eine Möglichkeit wäre es natürlich diese Infos direkt in die hier befindliche Datenbank einzupflegen. Aber natürlich kann ich das auch über meinen Server laufen lassen oder aber auch dezentral über mehrere Repositories.
    Auch mods von anderen seiten außer tf.net sollten TFMM nutzen dürfen, daher wäre eine dezentrale Lösung evtl die netteste. Ein "main" repository wäre auf meinem Server aber man könnte beliebige hinzufügen.


    Der Verwaltungsaufwand für Modder bliebe in soweit bestehen, dass bei neuen mods ein neuer eintag in einem beliebigen Repository erfolgen muss und bei updates dieser aktualisiert werden muss.


    Sobald so ein repository aber besteht, wird auch das suchen neuer mods über diese repositories eine Möglichkeit :)

    eis_os hat es genau aufgeschlüsselt wie ich mir das vorstelle. Ich habe niemals gesagt das ein Datenbank-Auth über die exe stattfinden soll, vielmehr hätte ein System auf dem Server das ganze als repository aus den entsprechenden Datenbankfelder generiert was dann durch die exe gelesen werden kann - übrigens ein Weg den ein anderer Entwickler in der Community auch geht ;)


    @eis_os was ich zu kritisieren hab: dein CIM Modmanager ist nicht kompatibel zur Filebase gewesen, darum hat diese Funktion nie Anwendung bei mir gefunden^^ Ich halte es für sehr wichtig das eine Kompatibilität des Train Fever ModManager zur Filebase besteht um es den Endanwender deutlich zu vereinfachen.

    Zitat von Yid

    Es ist halt die Frage, wie weit man das aufsplitten will und wie viel die Modder bereit sind, an Metadaten einzutragen. Ich würde alle Angaben als freiwillig für den Modder sehen. Ihr Modder "arbeitet" ja auch freiwillig für uns.


    Das sehe ich kein Problem, die Entwicklern würde gerne mitmachen, sonst wär sie traurig, wenn wir neue Version nicht nutzen ;)

    Die ID Vergabe hat keiner geregelt, du hast ja für deinen Programm Namen auch keinen gefragt oder? Die ID liegt in einer Datei/Dateinamen im Zip Paket.
    Mein CIM1 ModManager brauchte eine <id>.modinfo in der GS Datei, dein ModManager braucht eine ini. Also warum keine eindeutige ID und Version in die Ini und gut ist?


    Mediziner und das Wiki Repository auf DropBox waren als "vorauswahl" in meinem ModManger schon eingebaut und die wurden per Texteditor selbst erstellt.


    Auf dem Server:
    Öffne jeden neuen (öffentlichen!) Download die Zip/Rar Datei, schaue ob es eine INI gibt, wenn ja, lade die INI und finde die Metadaten,
    Schaue ob eine ID schon von einem anderen Nutzer benutzt wurde, wenn ja, ignoriere die Datei und melde es bei den Admins :P
    Trage den neuen Download in eine Datenbank inklusive Download Link und erstelle eine neue öffentliche repo Datei mit allen Downloads.


    In der INI:
    Die ID ist eine einmalige Angelegenheit, die Versionsnummer muss vor Release geändert werden, also sehr wenige Metadaten.


    id=beton_bridge_eis_os
    version=1.0


    Nun kann TFMM Zips auslesen und die INI Daten zur Versionsüberprüfung nutzen.


    Stepke:
    Das liegt im Betreiber der Filebase :P Die Repo Dateien sind ja kein Hexenwerk und wie gesagt sind für jeden offen...

    Um Deinen Post mal zu kondensieren:
    Es gab keine eindeutige ID Verwaltung.
    Der Server bekommt die infos direkt aus der .modinfo (tfmm.ini bei mir).
    Die repos per Hand.


    Meine aktuelle Abwicklung über den Namen war nie die endgültige Lösung - gerade beim Autoupdate wäre es einfach praktisch zu verhindern, dass eine Mod vom manager mot einer anderen beim aktualisieren überschrieben wird. Das wäre in meinen Augen fatal. Ich die von stepke angesprochene Kompatibilität wäre ein für mich nettes feature. Gleichzeitig sollen andere Seiten nicht ausgeschlossen werden. Daher würde ich zu einer eigenen Implementierung plus TF.net Anbindung tendieren. Sprich es könnte zb eigene repos geben aber TFMM sollte auch die downloaddatenbank mit einbeziehen.
    Schön wäre es vom Server eine Liste mit einer Zuordnung von TFMM ID zu Download ID zu bekommen (e.g. xanos.tfmm = 5).
    Diese Info sollte einfach zu bekommen sein wenn man einfach zu jedem Download tfmm-id mit in die Datenbank legen kann. Das wäre schon mal ein ausgangspunkt. Ideal wäre natürlich wenn man auch die aktuelle Version hier in die DB eintragen kann und man dann mit einem kleinen Script hier auf dem Server aus den downloadeinträgen ein TFMM repo generieren könnte.


    TL;DR
    Ich würde die Verwaltung gerne über Repos realisieren und im perfekten Fall das Repo für die hier verfügbare Download+DB direkt aus den Eintragen generieren.


    //edit für medi: ja die automatische ID Generation ist definitiv möglich und ich denke auch praktisch. Als weiteres Feld in der ID sollte man evtl noch die "domäne" angeben: "domäne.modder.mod" - zb "main.xanod.tfmm" mit der domäne "main" (oder irgendein anderer fester string) für alle mods von tf.net.

    Wenn Repo X und Repo Y, sagen wir train-fever.net/cimexchange.net den selben Mod hat, bekommt man doppelte Einträge bei den genannten Vorschlag. Die ID sollte im Paket sein, damit man die Infos auch nach dem Download noch hat... :)


    PS: So als Info das man sich das vorstellen kann was der Server liefern kann/sollte. (Das Format ist nebensächlich, JSON, XML, Text)
    http://cim.bytetransfer.de/repo/cim.repo

BlueBrixx