Rückkonvertierung TPF2 -> TPF1 I : Einleitung, abwärtskompatible Dateien, Meshes, Animationen, Gruppen

Willkommen in der Transport Fever Community

Welcome to the fan community of Transport Fever and Train Fever, the economic simulators of Urban Games. The community is free for you to share and inform yourself about the game. We cultivate a friendly and objective interaction with each other and our team will be happy to answer any questions you may have.

 

Registration and use is of course free for you.

 

We wish you a lot of fun and hope for active participation.

The Team of the Transport-Fever Community

  • Über die manuelle Konvertierung von TPF2-Modellen zu TPF1

    Um Modelle von TPF1 zu TPF2 zu konvertieren, gibt es mehrere automatisierte Methoden, die inzwischen hinreichend bekannt sein dürften.


    Wenn man nun aber ein Modell von TPF2 gerne in TPF1 hätte, dann muß man es manuell umbauen. Das ist bei einfacheren Modellen mit nur wenigen Animationen nicht über die Maßen kompliziert. Alle Sonderfälle und Möglichkeiten kann ich hier nicht beleuchten, aber einen groben Überblick werde ich zu geben versuchen. Dieser Überblick richtet sich an Leute, die grundsätzlich mit der Struktur eines Mods vertraut und für die Keyframes, Transformationsmatrizen, Meshes und Ähnliches nichts völlig Neues sind; wenn ich hier die Grundlagen auch noch erklären würde, würde die Länge des Texts explodieren. Des weiteren rate ich dringend dazu, für die ersten manuellen Konvertierungen kein komplexes Modell zu wählen: bei Flugzeugen zum Beispiel ist die Animation des Einziehfahrwerks oft äußerst verschachtelt und die Konvertierung erfordert ein gewisses Verständnis für die Materie.


    Ich werde es hier einmal am Beispiel des MAN-Haubendiesels beschreiben, der sowohl in 2 als auch in 1 vorhanden ist.


    1. Abwärtskompatible Dateien

    Nicht alle Dateien benötigen eine Nachbearbeitung und man kann sie sowohl in TPF1 als auch in TPF2 verwenden.


    Die Verzeichnisstruktur ist bis auf wenige Details identisch. Es ist also möglich, das Modverzeichnis aus TPF2 en bloc an den entsprechenden Ort in TPF1 zu kopieren, dann ist die grundlegende Struktur schon mal vorhanden.


    Die mod.lua, die Materialdateien (.mtl) und alle .msh.blob-Dateien brauchen keine Änderungen. Die Texturdateien, ob .tga oder .dds, sind ebenfalls für TPF1 und 2 gleich. Wenn das Modell als Asset hergerichtet ist, ist die .con ebenfalls grundsätzlich abwärtskompatibel. Hier gibt es eine Einschränkung: in TPF2 ist bisweilen eine eigene Assetversion ohne Lichter oder drehende Teile integriert. Dies ist in TPF1 nicht nötig, da es hier weder verwischte Propeller noch animierte Lichter gibt. Deswegen ist es möglich, daß man die .con hier minimal anpassen muß, um nicht die Asset-, sondern die normale Version des Modells anfordern zu lassen.


    2. Die Meshdateien (.msh)

    Hier sitzt der erste große Unterschied. In TPF1 werden Details eines Meshs in dieser Datei definiert, die in TPF2 in der großen .mdl zusammengefaßt sind. Relevant sind hier die Animationen und vor allem die Anforderung des Materials. Vergleichen wir einmal eine .msh aus 1 mit einer aus 2.


    Hier ist die Datei "MAN415_Kardanwelle.msh" aus 2:

    ...und hier dieselbe Datei aus 1:

    Das Material wird in 1 mit "materials = {"vehicle/truck/MAN415.mtl",}," angefordert. In TPF2 ist eine exakt gleich lautende Zeile in der .mdl enthalten:


    Die muß also einfach aus der TPF2- .mdl herauskopiert und an den passenden Ort in der 1-.msh hineinkopiert werden. Den kleinen Block oben "matConfigs = {{0, },}, " dürfen wir auch nicht vergessen - der wird vor "subMeshes=..." eingefügt.


    Nicht animierte Meshes sind damit schon fertig angepaßt und können in 1 verwendet weren.


    Manche Teile sind jedoch animiert. In der oben gezeigten 1-.msh seht ihr einen Block "animations = {...}", der prinzipiell auch im gezeigten Teil der TPF2-.mdl vorkommt. Wenn die 2-.mdl Keyframes benutzt (die sehen so aus: "{time = 0,rot = { 0,0,0},transl = {0,0,0}},"), dann kann der Block einfach 1:1 genommen und aus der 2-.mdl in die 1-.msh hineinkopiert werden (an den Ort, an dem er in der oben gezeigten 1-.msh sitzt!); dann ist nur noch der Verweis aus der 1-.mdl wichtig. Zu dem kommen wir später.


    Wenn die 2-.mdl aber wie hier auf eine .ani-Datei verweist, dann ist es etwas komplexer. In diesem Fall müssen wir die 2-.ani öffnen, und die sieht so aus:


    Das scheint zunächst etwas chaotisch, es ist aber nichts anderes als die in TPF1 und 2 bekannten Transformationsmatrizen in einer etwas anderen Sortierung. Hier geht jetzt ein wenig Tipparbeit los. Wir legen uns im zu animierenden 1-.msh diesen Block hier an:


    ...und den füllen wir dann mit den Matrizen aus der .ani. In den Block "keyframes = {...}" kommt dann für jede Transformationsmatrix aus der .ani folgender Block:


    Code
                        {
                        time = 0,
                        transf = { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, },
                    },

    Hinter "time" kommt der Reihe nach der Wert aus dem "times"- Block der .ani und hinter "transf = " ebenfalls der Reihe nach jede Transformationsmatrix. Die ersten drei Blöcke würden daher so aussehen:



    ...und so weiter. Das ist natürlich langwierig, da in 2 die .anis oft sehr lang sind - es ist aber in 1 auch möglich, bei kontinuierlichen Animationen wie rotierenden Wellen nur beispielsweise jeden vierten Block anzugeben. Möglich ist natürlich ebenfalls, wenn man die Animation genau kennt, sie in Keyframes schnell neu selbst zu schreiben, das kann bisweilen etwas schneller gehen.


    Wichtig ist, daß wir der Animation einen in diesem Modell eindeutigen Namen geben - unter diesem werden wir sie dann in der 1-.mdl aufrufen.


    Damit ist dann das Mesh fertig, in TPF1 verwendbar und für die Animation vorbereitet.


    Diese Konvertierung ist natürlich für alle zum Modell gehörenden Meshdateien einzeln durchzuführen.


    3. Die Gruppen

    Die sind in TPF1 völlig anders organisiert als in TPF2. Sie sitzen im Verzeichnis res\models\group\vehicle\truck (je nach Art des Modells angepaßt!) und enthalten Dinge, die in 2 ebenfalls in der .mdl sitzen.


    Vergleichen wir einmal die Gruppe, in der die Trommel des Betonmischers bei TPF2 sitzt, mit der Datei in 1.


    In 2 erkennt man die Struktur, die in 1 eine .grp-Datei benötigt, am Stichwort "children=". Das steht gleich hinter den Animationen und sieht in der .mdl so aus:


    Das kommt in TPF1 dann in eine Gruppendatei mit der Endung .grp. Der Name kann relativ frei gewählt werden, sollte aber im Spiel einmalig sein. Hier lautet er MAN415B_Trommel.grp.



    Den großen Block der Keyframeanimationen können wir auch hier wieder 1:1 aus der TPF2-.mdl in die .grp rübernehmen; wäre ein Verweis auf eine .ani da, würde es wieder so wie in der .msh gezeigt funktionieren.

    Und jeder Block, der in der 2-.mdl ein Mesh oder eine weitere Gruppe verlangt, wird auch in der TPF1-Gruppe benötigt. Die Anforderung eines Meshes heißt in 2 "mesh=...", in 1 jedoch "id = ...". Die Transformationsmatrizen dahinter können 1:1 kopiert werden.


    Aus dem Block in der 2-.mdl

    Code
                                {
                            _meshId = 26,
                            _origMeshId = 26,
                            materials = { "vehicle/truck/MAN415-Betonmischer.mtl", },
                            mesh = "vehicle/truck/MAN415/MAN415B_Lagerring.msh",
                            name = "MSH_MAN415B_Trommel_1",
                            transf = { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, },
                            },


    wird also in der 1-.grp

    Code
                                {
                             id = "vehicle/truck/MAN415/MAN415B_Lagerring.msh",
                             transf = { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, },
                             type = "MESH",
                            },

    Und selbiges gilt für jedes andere Mesh, das in der .grp angefordert wird.


    Jetzt müssen wir uns noch um die Animation kümmern. In der 1-.grp steht ein Block:

    Code
        events = {
        forever = {
            [0] = {
                forward = true,
                name = "MAN415_TrommelAction",
            },
        },
    },

    Das bedeutet folgendes: Aus der .mdl wird später eine Animation namens "forever" angefordert werden, die oben definierte Keyframeanimation, die auch oben den Namen "MAN415_TrommelAction" zugewiesen bekommen hat, auslösen soll. In diesem Fall dreht sich einfach nur die ganze Trommel um ihre Achse. Wenn es Untergruppen oder andere separat animierte Teile in der Gruppe gibt, kann die Animation wesentlich komplexer aussehen, das Prinzip ist aber dasselbe.


    Die Transformationsmatrix ganz unten in der 2-.mdl werden wir später auch brauchen, die wird in der 1-.mdl stehen und dort die Gruppe anfordern.


    Am einfachsten ist hier, wenn man sich eine einfache .grp wie die hier gezeigte hernimmt und die Elemente aus der 2-.mdl hineinkopiert.



    Die .mdl werde ich in einem separaten Artikel behandeln.

Share

Comments 8

  • Geht das bei den Mods: Baureihe 442 / Bombardier Talent 2 - bwegt (DB, Abellio, SWEG) - Transport Fever Community und Baureihe 442 / Bombardier Talent 2 - Basispaket - Transport Fever Community? Ja ich weis die gibt es auch für TPF aber nicht mit den funktionellen Zugzielanzeigern xD

    • Bewegte Zugzielanzeigen werden in TPF1 nicht möglich sein, aber das Prinzip ist bei allen Mods grundsätzlich dasselbe.


      Ich würde dazu raten, eher das existierende TPF1-Modell zu verwenden als ein TPF2-Modell zurückzukonvertieren.

    • Danke! Wenn das nicht geht nehm ich auch das TPF Modell weiterhin mir ging es ja nur um die Zugzielanzeige

  • There's something to do with matConfig, since not many modder in tpf1 know about its usage.


    In tpf2 you can use multiple materials on a same mdl, it's almost the same in tpf1, but configurated by matConfig. In simple word, matConfig is a combine of usage of materials in msh file, for example



    Here five different materials configurated by the matConfig, then in mdl you can refer to the correct index of matConfig in the matConfig array


    Like 1

  • Das auch noch ein matConfigs = {{ 0, },}, Eintrag in das msh gehört hast du nicht erwähnt, ohne den wird es nicht funktionieren.


    Und dadurch das die neue Forensoftware die ganzen Code Blocks nicht richtig darstellt ist das ganze dermaßen unübersichtlich das selbst ein erfahrener Modder nicht wirklich was damit anfangen kann, eventuell müsstest anstatt den "Code" Blocks Bilder verwenden.

    • Stimmt, die MatConfigs trage ich schnell nach. Bilder... vielleicht probiere ich einmal einen Screenshot aus, aber das hätte den Nachteil, daß man sie nicht als Dummy-Dateien (wie zum Beispiel die .grp) herauskopieren kann.

    • Ja das Problem sehe ich auch, ist halt echt doof das die Software lua nicht mehr ordentlich formatiert. Man könnte sie eventuell als Beispiel anhängen, in den meisten Mod's sind sie ja recht umfangreich, so das eine einfache "Minimum" - mdl, grp als Beispiel eventuell Sinn macht. Aber auf der anderen Seite erfordert das ganze halt auch Selbstinitiative bei den Leuten die das unbedingt machen wollen.

    • Völllig klar. Ohne ein gewisses Verständnis für die Struktur der Verzeichnisse und Dateien wird es nicht funktionieren. Und der kommende Teil 2 über die .mdl wird vermutlich nicht weniger kompliziert.


      Aber wenn es einem hilft, dann ist es schon gut.