RhB Capricorn - erster Schritt

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


  • Die Änderungen mit den Klammern haben keine Wirkung gezeigt. Die Meldung mit der Klammer "}" vor "end" popt kurz nach dem Start der Karte immer noch auf.


    Das Code Highlighting habe ich trotz Recherchen nicht einrichten können. Falls ihr Tipp's hierzu habt, gerne!


    Danke und Grüße


    Jürgen

    Einmal editiert, zuletzt von Kokoloko ()

  • Arbeitest du mit dem Windows Notepad anstatt mit Notepad++ ?


    Mit Notepad++ kann man wunderbar sehen wo die jeweils schließende Klammer zu jeder öffnenden zu finden ist, da liegt auch der Fehler wieso es abschmiert. Da fehlt mindestens eine.


    Aber da musste jetzt nicht extra suchen, der ganz Block mit den Bogies stimmt so gar nicht. Da müssten mindestens 2 Groups sein, für jedes Drehgestell eine. Du hast gar keine Gruppe dafür, die Drehgestelle sind zusammen in der Rootnode und würden sich als solche also um 0,0,0 (RootNode) bewegen.


    Das wäre ein kompletter Codeblock für einen Zug mit "Body" und 2 DG. (Die Variablen in den materials Zeilen einfach ignorieren, da steht bei dir ja der Pfad drinne das geht auch.)

    Wie man sieht gehören nicht die Mesh des DG auf 2.75/-2.75 (5 bei dir) sondern die Gruppe des jeweiligen Drehgestells, damit es sich um diesen drehen kann und die Mesh werden dann relativ zu dieser Gruppe angegeben. Das DG wird wohl bei x=0 sein und die Räder was bei -1 und +1 relativ zur Gruppe.


    Zum unteren Bild:


    Das obere ist das was du gemacht hast, die Drehgestelle und die Räder hängen an der "rootnode" des Models (roter Punkt) und bewegen sich auch um diesen.


    Der untere Teil des Bildes ist mein Codeblock. Die DG sind als Gruppe -5 und +5 vom Mittelpunkt der Rootnode jeweils als Gruppe ausgeführt und drehen sich um die grünen Punkte, während sich das ganze Modell um den roten Punkt bewegt, je nachdem wie die DG sich in den Schienen bewegen.

  • Danke MaikC, kurze Rückmeldung, ich nutze den Notepad ++ . Was genau dort eingestellt werden soll für das Code Highlighting weiß ich nicht. Im Youtube und Google sind die Darstellungen in den Untermenüs anders als wie es in meinem Notepad++ (v8.1.2) zu sehen ist.


    Grüße


    Jürgen

  • @ MaikC,


    danke für Deine Skizze, das Code- Beispiel und die anderen Informationen. Alles verstanden. Aber,


    - ich weiß nicht wie man eine Gruppe in der .mdl erstellt!

    - wird der Text entsprechend deinem Beispiel " name = "GRP_maikc_faurl45h_lod_0_dg_750_2", " in die mdl eingetippt? oder wird das irgendwo erzeugt?

    - ins eine Gruppe lediglich durch das Beginnen mit dem Kürzel "GRP" und einem Wunschnamen eingerichtet?

    - und woher kommen die "transf = { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 2.85, 0, 1, 1, }" Zahlen her?


    Dein Code-Beispiel und meine (für nur 1 DG) erstellte mdl, habe ich in dem Screenshot nebeneinander gestellt, an dem roten Kasten ist der Punkt an dem ich nicht weiter komme.





    Für die viele Unterstützung und vor allem die viele Geduld, kann ich nur Dankeschön sagen!


    Viel Grüße


    Jürgen





  • Code
    "transf = { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 2.85, 0, 1, 1, }" Zahlen her?

    Der Code der transf ist in der Standardversion leider nicht grade sehr logisch



    "transf = { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 2.85, 0, 1, 1, }"


    - Alles was rot ist gibt die Drehung und die Skalierung an, der umrechner dafür ist ja im Lexikon zu finden

    - Das grüne ist die Position in x, y , z


    Die Gruppe wird alleine durch die Setzung der Klammern definiert und jede Gruppe braucht dann eine transf , ganz minimalistisch würde das auch so gehen:




    So kann man die transf auch schreiben, was deutlich logischer ist und leichter editierbar.

    Code
    local vec3 = require "vec3"
    local transf = require "transf"
    
    transf = transf.scaleRotZYXTransl(vec3.new( 1.0, 1.0, 1.0), transf.degToRad ( -181.3, 0, 0), vec3.new(-4.42082, -1.43572, 0.6)),
    Code
    transf = transf.scaleRotZYXTransl(vec3.new( Skalierung ), transf.degToRad ( Drehung ), vec3.new( Position )),
  • und woher kommen die "transf = { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 2.85, 0, 1, 1, }" Zahlen her?

    Schau mal hier ins Lexikon: Transformationsmatrix

    Das hilft dir eventuell beim verstehen dieser Zahlenfolge :)


    Wegen der Gruppe:

    Eine Gruppe ist im Grunde eine abgespeckte mdl-Datei, die wiederum eine Liste von Meshes (oder weiteren Untergruppen) enthält. Diese Datei (anstelle der Meshdaten) gibst du dann hier an. Eventuell hilft dir das hier weiter:

    Animation: Gruppe


    Das ist von mir aber in Bezug auf Animationen mit Gruppen erstellt worden - zu TpF1 Zeiten. Hier solltest du besser mit originalen Dateien des Spiels vergleichen, ob das alles noch so hinhaut. Das Grundprinzip sollte aber passen.


    Und das hier hab ich auch noch gefunden (auch glaube TpF1):

    fakeBogies

    Behandelt zwar Fake-Bogies (ein Bogie ist ein Drehgestell, einfach das englische Wort dafür) und gefaket wird in dem Bezug gerne bei Faltenbälgen oder sowas. Also die Funktionalität des Drehgestells wird hierbei quasi zweckentfremdet. Aber eventuell hilft dir das, ein richtiges Bogie zu verstehen ^^

  • Das geht auch einfacher.


    Wenn man in der .mdl ganz oben die beiden Funktionen vec3 und transf definiert:

    Code
    local vec3 = require "vec3"
    local transf = require "transf"

    ...dann kann man so gut wie alle Transformationsmatrizen auch durch einen intuitiv verständlicheren Code ersetzen.


    transf = { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, -11.01617, 13.3311, 2.52436, 1, },


    entspricht ganz genau dem hier:


    transf = transf.rotZYXTransl(transf.degToRad(0, 0, 0), vec3.new(-11.01617, 13.3311, 2.52436)),


    Beim zweiteren kann man die Drehungen des Teils ganz einfach als Grad (Z-, Y- und X-Achse) eintragen, ohne sie in irgendwelche Winkelfunktionen übertragen zu müssen. Ohne Drehungen sieht das noch recht einfach aus, aber...


    transf = {0.696, 0.696, -0.174, 0, -0.603, 0.699, 0.385, 0, 0.389, -0.163, 0.907, -11.01617, 13.3311, 2.52436, 1, },


    ...ist intuitiv praktisch nicht zu verstehen, wogegen das vom Ergebnis her identische


    transf = transf.rotZYXTransl(transf.degToRad(45, 10, 23), vec3.new(-11.01617, 13.3311, 2.52436)),


    auf den ersten Blick sagt, daß das Teil um 23°, 10° und 45° um die Z-, Y-, und X- Achse gedreht und an den bewußten Koordinaten abgelegt ist.


    Der einzige Punkt, an dem diese Methode scheitert, ist, wenn man die Teile gleichzeitig skalieren möchte - das kann die Matrix, aber die zweite Methode nicht.

  • Achso, ich dacht schon du willst mich ärgern ^^

    Du tippst zu langsam ;-) aber ja das fiel mir nachträglich ein und hab das da später reinkopiert.


    Ja um einiges besser als das rumgeeier mit der "normalen" transf, wenn ich was nachträglich anpasse dann mache ich das nur noch so.

  • Nun, deinen Bildschirm sehe ich nicht, und offensichtlich haben wir hier gleichzeitig denselben Lösungsgedanken gehabt.


    Die matrixlose Methode hat übrigens noch einen weiteren Vorteil. Die Seite im Lexikon kann leider nur mit vollständigen Graden umgehen; wenn man sie mit Dezimalstellen füttert, dann werden sie einfach abgeschnitten. Dadurch fehlt einer so generierten Matrix oft eine gewisse Präzision, die man mit der anderen Methode viel besser erreichen kann.

  • Die Seite im Lexikon kann leider nur mit vollständigen Graden umgehen; wenn man sie mit Dezimalstellen füttert, dann werden sie einfach abgeschnitten. Dadurch fehlt einer so generierten Matrix oft eine gewisse Präzision, die man mit der anderen Methode viel besser erreichen kann.

    Dafür gibt es das hier - das Selbe wie im Lexikon, bloß besser :)

    http://ftp.train-fever.net/transformation/


    Ach ja, und MaikC Farbige Markierungen werden in Codeblöcken nicht angezeigt. Ich denke, dass du das in deiner Erklärung oben machen wolltest...?

  • Das Rumstochern hat nicht viel gebracht, immer wieder kommen Fehlermeldungen auf!


    Ich habe die MOD mal drangehängt, wenn jemand Lust hat sie mal durchzugehen und Fehler zu korrigieren (wenn möglich auf minimalistischem Niveau halten) wäre ich dankbar.


    Die transfs- Rechnungen habe ich beigefügt sowie screenshots der Position der Drehgestelle.


    kokoloko_2xdg+tank_1.zip




    Gerne möchte ich die Drehgestelle in den Griff bekommen um den Capricorn zu Korrigieren


    Viel Grüße und danke!


    Jürgen

  • Bei dir fehlen einige Kommas, das ist der Fehler


    Die Zeilen kannst du aber entfernen, die werden nicht benötigt.


    Auch hast du die Drehgestelle in der Achsen Definition erwähnt, die ist aber, wie der Name sagt, nur für die Achsen gedacht


    Noch ein generelles Problem, die Dateinamen sind ein absolutes Chaos. Ich würde da mal einen anderen Mod anschauen und Datei und Ordner Namen entsprechend anpassen

  • Hier mal eine angepasste Datei. Nach Ergänzung der angemerkten fehlenden Kommata sieht es so aus:


    Diese Rotation kommt wohl von den 20° Rotation die du in der Transformationsmatrix für die Gruppenknoten eingegeben hast. Wenn man diese beiseite lässt, also

    Code
    transf = {1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, -5, 0, 0.384, 1, },

    statt

    Code
    transf = {0.940, 0.342, 0, 0, -0.342, 0.940, 0, 0, 0, 0, 1, 0, -5, 0, 0.384, 1, },

    schreibt, sieht das ganze so aus:



    Nun bleibt noch der Versatz. Wie man sieht, ist der Drehgestellgruppenknoten schon an der richtigen Stelle (weiße Quadrate mit 0./1.). Die Kindelemente von Gruppenknoten beziehen sich mit ihren Transformationsmatrizen nicht auf den globalen Ursprung des Modells (also den Punkt an dem oben die drei Achsen blau/grün/rot zusammentreffen), sondern sie sind relativ zum direkten Elternknoten. Das wären ja dann die weißen Quadrate. Entsprechend sind die Kinder (2 Achsen + 1 Drehgestellmesh) jeweils um die 5 Meter versetzt, weil sowohl der Elternknoten um 5 Meter verschoben ist, als auch nochmal die Kinder, da bei denen ja aktuell in den Transformationsmatrizen auch ca -4.9, -5,8, -4.0 usw als Offset dransteht.


    Das kommt wohl daher, dass die Hierarchie beim Export aus Blender noch nicht so gegeben war. Wenn du dort schon die Hierarchie anlegst, sollte das beim Import richtig erkannt werden. Hier mal ein Beispiel von einem der Vanilla-Kesselwagen. Das kann auch als Benennungsbeispiel herangezogen werden:


    Wenn man die Transformationsmatrizen entsprechend richtig anpasst, sieht es dann auch ganz vernünftig aus:

  • Die Kommas haben schon etwas bewirkt! ein Probefahrt ergab folgende Bilder!



    Grüße


    Jürgen

  • Warum spuckt der Modeleditor beim abspeichern eigentlich so einen Unsinn aus -->7.8047996510122e-08 das ist ja 0.00000000078047996510122 also quasi Null. In Blender kann man so kleine Werte nicht mal angeben also wo kommt das her? Yoshi

BlueBrixx