Beiträge von DH-106

Hallo Auge,
ja, richtig geraten, es ist die Nase einer Il-18. Scheint, daß es die DM-STA von der Interflug wird. Bisher geht es gut voran, ich hoffe, daß ich einige der Fehler, die ich bei der 104 gemacht habe, diesmal vermeiden kann...

Ich danke euch allen herzlich für eure Hilfe. Ihr habt mir einige Irrwege abgekürzt und graue Haare erspart

Die Animationen habe ich letztendlich ganz klassisch von Hand und bewaffnet mit Bleistift und Taschenrechner gebaut, nachdem ich hier im Forum einige Threads gelesen und einige Flugzeuge von Bandion seziert habe. Es dauert ein wenig, bis man dahinter kommt, aber dann ist es nicht ganz frei von Logik. Zum Animieren ist der ModelViewer nicht genug zu preisen; der erlaubt nämlich nicht nur das schnelle Erstellen von schicken Bildern, sondern zeigt auch sofort, ob eine Anpassung am Gerät das Spiel abschießt, funktioniert, oder sogar gut aussieht.

Das Flugzeug ist jetzt so weit, daß ich denke, es einmal vorstellen zu können. Hier sollte es zum Herunterladen bereitstehen, sobald ein Moderator seinen Sanktus dazu gegeben hat.

Das nächste Projekt sollte mit etwas weniger Haareraufen verbunden sein (hoffe ich zumindest). Wieder ein Flugzeug, man könnte es das logische, weniger glamouröse Gegenüber der Tupolew nennen. Ein Screenshot hängt mit dran

In der .mdl kommt die Anfrage nach den Animationen an, man muß nur die beiden Kopfzeilen "local vec3 = require "vec3"" und "local transf = require "transf"" manuell dazugeben.

Das Problem ist aber, daß die Keyframes in den Meshes irgendwie untergehen. Der Block ist zwar in der Datei, aber die Keyframes, die dann in dem Block...

{
time = 0,
rot = { 0,0,0},
transl = {0,0,0}
},

... stehen würden, werden nicht mit exportiert. Die müssen dann halt von Hand reingeschrieben werden, und die beiden oben erwähnten Kopfzeilen fehlen auch. Und das ist unabhängig davon, welcher Art die Keyframes sind (RotLoc geht ebensowenig wie RotLocScale).

Das Bugrad ist nicht so kompliziert: das fährt einfach nach hinten ein, und dann gehen die Klappen darüber zu. Das funktioniert auch schon ganz ordentlich, nachdem ich das von Hand geschrieben habe.

Die Bewegung des Hauptfahrwerks ist leider wesentlich komplexer: der Schlitten, an dem die 4 Räder hängen, wird erst senkrecht gedreht: das sind schon mal zwei Keyframes. Dann fährt das Fahrwerksbein mit allem, was daran hängt, nach hinten in die Gondel ein, so daß die Räder nachher wieder horizontal, aber um 180° um die Y-Achse gedreht, darin zum Liegen kommen. Daß davor die großen Türen aufgehen und danach alle Türen wieder geschlossen werden müssen, ist wohl eher trivial zu animieren und mit maximal 4 Keyframes zu erschlagen.

Deswegen wäre eine Möglichkeit, die Keyframes aus dem Blender direkt zu exportieren, eine echte Erleichterung gewesen. Aber auch von Hand ist das irgendwie zu schaffen, auch wenn es sicher eine Weile dauern wird. Türen zu öffnen und zu schließen ist kein echtes Problem, aber mühsam wird es, wenn Teile voneinander abhängig sind, so wie z. B. Räder, die irgendwie stimmig zusammen mit ihren Fahrwerksbeinen fahren müssen. Der Modelviewer ist hier echt nützlich; dann muß man nicht nach jedem einzelnen Anpassungsversuch den großen TPF anstarten.

Ich muß zugeben, daß ich die Komplexität dieses Flugzeuges ein wenig unterschätzt habe, als ich es mir als erstes Projekt vorgenommen habe... wahrscheinlich hätte ich mit etwas strukturell einfacherem ohne so viele bewegliche Teile anfangen sollen.

In diesem Thread ist eine gute Erklärung dafür, was da wo in die Meshdateien reingehört.

Dieses Forum ist eine echte Quelle der Erleuchtung...

Die Ruder und Klappen bewegen sich jetzt so, wie sie sollen. Für Spaltklappen funktioniert die Animation gar nicht so schlecht, wenn man die Drehachse/den Ursprungspunkt des Meshes irgendwo weiter nach unten setzt, dann fährt die Klappe auch ein Stück nach hinten, wenn sie ausgefahren wird. Wenn die Klappe eher nach hinten fahren soll, dann kommt der Drehpunkt weiter nach unten und der Winkel sollte kleiner sein; wenn die Klappe ausgeschlagen werden soll, dann kommt der Drehpunkt näher an das Teil und ein größerer Winkel ist sinnvoller.

Es sieht übrigens recht lustig im Spiel aus, wenn man versehentlich den Rumpf als Querruder deklariert. Das hat mich einige Zeit gekostet, bis ich darauf gekommen bin, warum sich das Gerät im Flug immer wieder in seine Einzelteile auflöst

Und jetzt fehlt nur noch... "nur noch"... das Fahrwerk. Im Blender sieht es schon gar nicht so schlecht aus; die Beine fahren ein und aus und die Klappen gehen auch passend dazu auf und zu. Aber: wenn ich das Teil mit seinen Keyframes exportiere, dann kommen diese Keyframes nicht in der .msh an; das Spiel bzw. der Modelviewer finden die Animationen nicht und stürzen kommentarlos ab, sobald es Zeit zum Einfahren des Fahrwerks wäre.

Deswegen eine (hoffentlich?) letzte Frage: ist das auch wieder eine Frage der korrekten Benennung, wenn der Exporter die Keyframes nicht von selbst mitschickt, oder muß man die von Hand in die .msh reinschreiben?

Vielen Dank für die Antwort. Es scheint, daß tatsächlich die Skalierung das Problem ist: die ist weit weg von 1.0. "Apply" hat noch nicht ganz so funktioniert, wie ich es gerne gehabt hätte; dann wird wohl eine größere Revision fällig sein.

Aber es scheint, daß es weniger Arbeit ist als ich befürchtete: wenn man über die Teile einfach mit drei Skalierungsfaktoren drüberfährt und sie dann wieder einbaut, dann funktioniert es gar nicht so schlecht... Höhenruder und Seitenruder sehen schon mal so aus wie sie gehören, der Rest kann auch nicht mehr lange dauern.

Der Anstrich ist fast fertig...

Ich habe nur gerade eine weitere Tücke gefunden, die ich mir nicht erklären kann. Die beiden Höhenruder waren (logischerweise) spiegelgleich und haben dementsprechend auch spiegelgleiche Zeilen in der .mdl bekommen:

{id = "vehicle/plane/Tu104A/Tu104A_lod_0_HR_links.msh",
transf = transf.rotZYXTransl(transf.degToRad(180, -90, 16), vec3.new(-14.89377, 1.11667, 4.02085, 1.0)),
type = "MESH",},
{id = "vehicle/plane/Tu104A/Tu104A_lod_0_HR_rechts.msh",
transf = transf.rotZYXTransl(transf.degToRad(0, 90, 16), vec3.new(-14.89377, -1.11667, 4.02085, 1.0)),
type = "MESH",},

Sie sind zwar in der richtigen Position am Flugzeug, aber entlang der Drehachse um etwas mehr als den Faktor 2 gestreckt... Im Anhang sind zwei Bilder: das linke Ruder habe ich im Blender so angepaßt, daß es komplett falsch aussieht, aber im Model Viewer und Spiel richtig sitzt; beim rechten ist es umgekehrt.

Wieso ist das so? Mit dem letzten Faktor (1.0) in der transf=...-Zeile habe ich schon ein wenig rumgespielt, der hat aber anscheinend nichts mit Streckungen zu tun.

Könnte mich jemand hier erleuchten? Wo habe ich hier den Fehler gemacht?

Noch eine Frage bitte.
Die Ruder drehen sich im Spiel anscheinend anfänglich um die vertikale Achse, was zu eher skurrilen Ergebnissen führt. Dagegen wirkt die in zahlreichen .mdls auftauchende Zeile

transf = transf.rotZYXTransl(transf.degToRad(x,y ,z), vec3.new(a, b,c, d)),

Verstehe ich das richtig, daß x, y, z die Position der Drehachse in Grad ist? Die vier anderen Variablen scheinen sich auf einen Vektor zu beziehen. Nach Inspektion von Bandions exzellenter Ju-52/3m komme ich zum Schluß, daß a, b, c die gewünschte Position des Ursprungs der individuellen Meshs sein muß, aber welcher Wert d ist, habe ich bisher noch nicht rausfinden können...

Der Anstrich kommt auch langsam voran: die Fenster sind schon da, wo ich sie haben will, und sobald die einmal positioniert sind, sollte der Rest des Anstrichs auch hinzubekommen sein.

Langsam geht es voran, nachdem ich gefühlt so ziemlich jeden Fehler, den es gibt, ausprobiert habe Das Gerät steht schon mal vor der Halle, skaliert scheint es auch. Im Moment ist die Textur nacktes Metall, also muß es jetzt angestrichen werden, und die Animationen fehlen auch noch.

Falls es jemandem hilft:

- Wenn ein Flugzeug in Blender gut aussieht und auch schön auf der z=0-Ebene steht, aber im Spiel irgendwie komisch im Boden versinkt, dann probiert einmal, die Kamera aus eurem Blenderprojekt zu löschen. Bei mir hat erst dieser Schritt das Flugzeug im Spiel anständig positioniert.

- Wenn ein Gerät irgendwie "umgekrempelt" aussieht: Edit mode - Mesh - Normals - Recalculate Outside hilft meistens, man kann die Normalen auch von Hand auswählen und nach Bedarf umdrehen.

Vielen Dank euch allen für die Erklärungen.

Der Grund für das Fahrwerksproblem war offensichtlich, daß die Räder und Achsen nicht gerne in eine Gruppe inkludiert sind. Ich habe sie jetzt da rausgenommen und als separates Mesh eingebaut - und mit einem Mal funktioniert es, das Flugzeug kommt zumindest einmal aus dem Hangar raus. Daß es jetzt noch skaliert gehört und die Nase 90° zur Seite zeigt, werde ich auch noch irgendwie lösen...

SD70M, danke für den Vorschlag. Ich habe ihm eine PN geschrieben.

Agentbob, danke dir für die Antwort.

Die Bilder scheinen automatisch beim Export aus Blender zu entstehen (dieser Addon ist echt gut): ich habe das ganze Exportverzeichnis gelöscht und dann neu exportiert, und danach waren sie wieder da. Aber es fehlen auf ihnen halt Nase, Leitwerk und - vielleicht am wichtigsten? - die Räder. Ich habe deswegen den leisen Verdacht, daß meine beiden Probleme zusammenhängen und daß aus irgendeinem Grund der Fehler, der diesen eigenartigen Bildausschnitt generiert, auch für die "Landing Gear Configuration" verantwortlich sein könnte. Aber bisher konnte ich weder eine Ursache für die einzelnen Fehler noch einen echten Zusammenhang festnageln.

Ja, es wäre wohl eine gute Idee, wenn dieser Thread an einen angemessenen Ort verschoben würde. Moderatoren, wenn Ihr so freundlich wärt, bitte?

Edit by Yoshi: Stets zu Diensten. Verschoben und Überschrift ergänzt.

An zwei Problemen arbeite ich im Moment noch:

1. Das Bild vom Flugzeug in der Auswahlmaske vom Depot paßt irgendwie noch nicht so recht. Ich habe probiert, mit der Bounding Box sowohl im Blender als auch direkt in der .mdl ein wenig herumzuspielen, um so den Bildausschnitt festzulegen, aber das hat genau gar keinen Einfluß auf dieses Bild gehabt. Wie wird dieser Bildausschnitt festgelegt?

2. Was genau meinen sie mit "initial pitch on ground"? Nach meinem Sprachverständnis ist "pitch" der Winkel zwischen Flugzeuglängsachse und der Horizontalen. Aber das Flugzeug steht im Blender genau parallel zum Boden und die Auflagefläche der Räder ist genau bei z=0. Wo genau wird von TPF dieser Winkel gemessen, und warum ist es wichtig, daß er kleiner als 0,349066° ist? Die DC-3 und zahlreiche andere Flugzeuge mit Spornrad stehen am Boden alles andere als horizontal, ohne daß sich das Spiel offensichtlich aufregt.

Wenn hier auch noch jemand eine Antwort weiß, würde ich mich freuen.

Vielen Dank euch allen für die Hilfe. Im Spiel sehe ich das Gerät zwar immer noch nicht, aber lange kann es nicht mehr dauern.

Der Fehler "Malformed number near '104A'." und auch einige Fehler, bei denen das Spiel nach ] oder } verlangt, liegen offensichtlich daran, daß das Spiel mit Bindestrichen in Meshnamen nicht zurechtkommt: wenn ein Mesh z. B. Tu-104A_ etc. heißt, dann kommt der Fehler; tauft man alle Teile in Tu104A_ etc. um, dann funktioniert es.

Wie man die invalide Fahrwerkskonfiguration bekämpft und dazu die "Initial Pitch on Ground" unter die offensichtlich kritischen 0,349066° bekommt, muß ich noch herausfinden. Aber da das Fahrwerk ziemlich weit unten in der .mdl definiert ist, muß das einer der letzten Fehler in den Dateien sein. Ich nehme an, daß der Schwerpunkt des Geräts am Ursprung des Objekts liegt, und daß daher die Haupträder hinter diesem Punkt sein müssen, damit das Gerät nicht auf den Schwanz kippt?

Das ist ein Projekt für morgen...

Je mehr ich versuche, das Ding in TPF sichtbar zu machen, desto mehr Respekt habe ich vor denen, die das schon geschafft haben... Aber aufgegeben wird nicht.

Die Objektstruktur in Blender habe ich jetzt komplett überarbeitet und den Empfehlungen, die ich finden konnte, angepaßt. Der Export funktioniert ohne Fehlermeldung, aber in der .mdl gibt es noch mindestens 2 Probleme:
1. Die "Wheels" und "Axles" sind zwar im Blender markiert (s. Screenshot.png), aber sie kommen nicht in die .mdl.

2. Wenn ich das Spiel starte und versuche, die Tupolew zu kaufen, ist die Seitenansicht nicht zu sehen, und wenn ich auf "Kaufen" klicke, kommt eine Fehlermeldung: File: vehicle/plane/Tu.mdl (die Datei ist angehängt) ...models/group/vehicle/plane/Tu-104A_lod_0_Bugfahrwerk.grp:4:Malformed number near '104A'. This error is usually caused by modding etc.

Ich habe Google bemüht, aber nicht mal diese Fehlermeldung irgendwo wiedergefunden. Kennt vielleicht hier jemand das Problem und weiß, wie man es angeht?

Nochmal vielen Dank für die zahlreichen hilfreichen Antworten.

Vielen Dank an alle für die Antworten und die Lösungswege.

Das Spiel findet jetzt das Flugzeug und bietet es auch zum Kauf an. Die xyz-Achsen werde ich wohl noch ein wenig ausrichten müssen, dann gehts an die Texturen...

Wenn man das Flugzeug dann jedoch kaufen möchte, dann stürzt TPF noch ab und beschwert sich, daß in der .mdl die Achsen nicht definiert seien. Unter "Train Fever Mesh" habe ich die nicht lenkbaren Räder als "Achse" und das steuerbare Bugrad sowohl als Achse als auch als Rad definiert. Aber in der .mdl kommt davon nichts an. Hat hier vielleicht auch noch jemand einen Ansatz, wie man das löst?

Der Thread ist ja schon etwas länger gediehen, deswegen kommt hier im ersten Beitrag eine Zusammenfassung der schon fertigen und noch offenen Projekte. Diejenigen, die schon fertig sind, sind anzuklicken und verlinken auf die Downloadseite; die anderen werden noch kommen. Die Reihenfolge ist noch offen.

Momentanes Projekt: offen

Neue Projekte werden hinzugefügt, sobald sie mir einfallen und im Spiel sinnvoll nutzbar scheinen

AEG: J.II

Airbus: 220, 330, 340

Antonow: 10, 12, 22, 24, 26

Beechcraft: 18, V35, F33A

Boeing: 314, 377 Stratocruiser, 707

Bristol: Britannia

Bücker: Jungmann

Canadair: CL-610 Regional Jet (CRJ)

Cessna: 172

Convair: 440, 880, 990

deHavilland: Albatross, Comet I, Comet 4/4B/4C, Skate

deHavilland Canada: Dash 8-300, Dash 8-400, Twin Otter

Dassault: Falcon 50

Diamond: Katana

Dornier: Wal, Do-X

Douglas: DC-8, MD-80

Fábrica Militar de Aviones: I. Ae. 36 Condor II

Fokker: 27, 70

FWD: 152, 153, 154, 154A, 155, 160

Hamburger Flugzeugbau: HFB-320 Hansa-Jet

Handley Page: H. P. 42

Hawker Siddeley: H. S. 121 Trident

Iljuschin: 14, 18, 62

Kalinin: K-7

Laville: PS-89/ZiG-1

Lockheed: Model 9 Orion, F104 Starfighter, C-130K Hercules, 1328 Jetstar, 1011 Tristar

Luftschiffbau Zeppelin: LZ-6, LZ-11, LZ-13, LZ-120, LZ-121, LZ-127, LZ-129, LZ-130

Rohrbach: Roland I

Savoia-Marchetti: S.66

Sud Aviation: SE210 Caravelle

Tupolew: 104, 114, 124, 134, 144

Vickers: R100, Viscount, VC-10

Yakovlev: 18

Zeppelin-Staaken: E.4/20

Passagierdampfer: MS Mönkeberg

Eisenbahnen:

Locomotion No. 1
Pfälzische Nr. 26

Württembergische Passagierwaggons von 1845

[line]

---
[/line]

Guten Tag in die Runde,

ich versuche gerade zu lernen, wie man für Transport Fever neue Fahrzeuge baut. Eine Tupolew 104 ist gerade in Arbeit und in Blender auch schon relativ weit gediehen (sie ist nicht perfekt, aber es ist einmal ein Anfang). Es wäre also an der Zeit, das Ergebnis einmal im Spiel zu testen und die Skalierung anzugehen. Aber beim Export zum Spiel bin ich bisher immer gescheitert. Der Export mit Merks Addon funktioniert, die Dateien und der Verzeichnisbaum sehen soweit gut aus. Aber wenn ich dann das Spiel starte und den Mod einmal testen möchte, dann kommt die Meldung, daß der Mod "veraltet sei" und ich bitte den Autor für eine aktuelle Version kontaktieren soll.

Zwei Fragen:

1. Wo liegt dieser Fehler? Habe ich beim Export eine Einstellung übersehen und exportiere versehentlich in einem Format für Train Fever?
2. Gibt es bei dem Export-Addon eine Option, die .mdl-Datei automatisch erstellen zu lassen, oder ist die "freihändig" zu bauen?

Ich danke im Voraus für die Erklärungen...