It is a clean, minimal, purple-themed graphic social media banner, serving as the official header for the "Metruvia Knowledge Base" (Metruvia and Metruvia Knowledge Base) Transport Fever mod brand on Mod.io. The banner is set against a solid, deep-violet-purple background with a rich saturation. In the upper-center, a white, simplified, and symmetrical game controller icon is positioned. Directly below this icon, in prominent, white, bold, sans-serif text, is the text "Metruvia Knowledge Base". Below that, in smaller, regular white text, is the tagline "Built by Players. Powered by Knowledge." Symmetrically framing the central text and icon, on the far left and far right sides, are two large, detailed, white game controllers, depicted from a top-down aerial perspective with colorful button inputs (yellow, blue, pink, and green) and analog sticks. Scattered across the remaining purple space are small, white line-art icons that reinforce the gaming and puzzle themes: several puzzle piece outlines, small pixel-art heart outlines, simple bullseye targets, and a single solid white circle (a "knowledge" point). The layout is balanced, professional, and easily recognizable as part of a gaming community and documentation resource. The art style is flat vector graphic. A small, stylized white compass needle icon, derived from the Metruvia brand mark, is visible over the left analog stick of the controller on the right, providing a cohesive brand identity. The text is sharp and legible.

Metruvia Content Creator Series: Vehicle, Scripts, and Skeletal

·

·

Metruvia Content Creator Series transport fever 2 and Vehicle, Scripts, and Skeletal.

Welcome to the Metruvia Content Creator Series Vehicle, Scripts, and Skeletal Guide. A beautifully textured, perfectly optimized 3D model is useless if it slides across the rails like a rigid plastic block. Animation—the rotation of wheels, the pivoting of bogeys, the opening of passenger doors, and the rhythmic pumping of steam pistons—is what anchors your vehicle to the physics engine of Transport Fever 2.

For a PC modder, a poorly constructed animation hierarchy might simply cause a slight dip in framerate. However, when deploying to the Mod.io ecosystem for PlayStation 5 and Xbox Series X|S, animation is scrutinized heavily by both the hardware and the QA team. Every single moving part on your vehicle generates an independent Draw Call and requires real-time matrix math from the CPU. If your animation script is bloated, a yard test with fifty trains will lock up the console processor instantly.

This masterclass will deconstruct the mathematics of mechanical motion. We will explore the rigid parent-child node architecture, the kinematic formulas for wheel rotation, the event-driven scripts for doors and pantographs, and the strict skeletal optimization required to pass console certification.

1. The Skeletal Hierarchy: Nodes and Draw Calls

Before writing an animation script, you must structure your 3D model correctly in your modeling software (like Blender) and map it accurately in your .mdl (Model) file.

Transport Fever 2 does not use traditional “bone” armatures for vehicles. Instead, it uses a Node Hierarchy (Parent-Child relationships).

1.1 The Draw Call Penalty

As established in earlier optimization articles, merging your meshes is critical to saving Draw Calls. You should combine the roof, the walls, and the chassis into one single .msh file.

However, you cannot merge moving parts.

If a wheel spins, it must be exported as a separate .msh. If a door opens, it must be a separate .msh.

The Console Danger: If you build a passenger train with 24 individual, separately animated doors, that single train generates 24 additional Draw Calls every frame. Multiply that by 50 trains in a station, and you have crashed the console’s rendering thread.

The Solution: Group mechanical actions. Instead of animating 12 left-side doors independently, merge the geometry of all 12 left-side doors into a single doors_left.msh file. You then animate that single mesh to slide outward simultaneously, reducing 12 Draw Calls down to 1.

1.2 The Parent-Child Matrix

In your .mdl file, nodes define the hierarchy. The main body is the parent. The bogeys are children of the body. The wheels are children of the bogeys. When a train rounds a corner, the engine calculates the turn, pivots the bogey, and the wheels automatically follow because of this hierarchy.

2. Axle Mathematics & Wheel Rotation

Transport Fever 2 handles wheel rotation automatically based on the speed of the vehicle, provided you give the engine the correct mathematical data. If your math is wrong, the wheels will appear to “ice skate” or spin wildly out of sync with the track speed.

2.1 The axles Array

Inside your vehicle’s metadata, you must define the axles table. You list the specific mesh node of the wheel, and you must declare its radius in meters.

metadata = {
railVehicle = {
axles = {
“vehicle/train/my_front_wheels.msh”,
“vehicle/train/my_rear_wheels.msh”
},
— …
}
}

2.2 Calculating the Radius

The game engine calculates the required rotation speed (angular velocity) by analyzing the circumference of the wheel. The underlying physics engine utilizes standard geometry:

$$Circumference = 2 \times \pi \times Radius$$

If you model a wheel with a 1.0-meter diameter, the radius you input into the .mdl bounding box must be exactly 0.5. If you guess this number, or if you scale the wheel in Blender without applying the scale transformation before exporting, the math breaks. The engine will rotate a 1.0-meter wheel as if it were a 0.5-meter wheel, destroying the illusion of physical mass.

3. Event-Driven Animations: Doors and Pantographs

Wheels rotate constantly based on physics, but doors and electrical pantographs move based on game events. These require explicit keyframe scripting.

3.1 The events Table

Animations are triggered by specific state changes. The standard events for a passenger vehicle are open_doors_left, open_doors_right, close_doors_left, and close_doors_right.

3.2 Keyframe Transformations

To script the movement, you define a timeline using time (in milliseconds) and a transformation matrix (rot for rotation, transl for sliding translation).

events = {
open_doors_left = {
[1] = { — Targeting the mesh node of the doors
forward = true,
name = “openddoors”,
}
}
},
animations = {
openddoors = {
type = “KEYFRAME”,
params = {
keyframes = {
{
time = 0,
rot = { 0, 0, 0 },
transl = { 0, 0, 0 }
},
{
time = 1000, — 1 second later
rot = { 0, 0, 0 },
transl = { 0, 0.8, 0 } — Slide outward 0.8 meters on the Y axis
}
}
}
}
}

3.3 The Clipping QA Failure

Console testers will aggressively check your door animations. If your door translates 0.8 meters but the physical wall of the train is 0.9 meters thick, the door will clip into the mesh. Visual clipping on mechanical parts is an immediate QA failure for “Console Compatible” certification. You must ensure your translation vectors precisely match the modeled door recesses.

4. Complex Kinematics: The Steam Piston Dilemma

Steam locomotives represent the absolute pinnacle of animation complexity. You have pistons driving connecting rods, which drive wheels, which drive valve gears.

4.1 The fake_bogies Solution

Historically, modders tried to script every single rod using massive mathematical arrays. This is devastating to CPU performance. Transport Fever 2 solves this elegantly with fake_bogies.

You group your connecting rods into a node and declare it as a “fake bogey” in the .mdl metadata. You assign it an offset from the center of the wheel. As the main wheel rotates via the standard axle mathematics, the engine automatically calculates the inverse kinematic pulling motion of the rods without requiring you to manually script thousands of keyframes.

4.2 Synchronization

For steam engines, visual and audio synchronization is critical. The chuff audio event is tied directly to the rotation of the driving wheels. If your fake bogey configuration is misaligned, the connecting rod will reach the end of the piston stroke, but the audio chuff will trigger half a second later. You must tune the axle radius and the fake bogey offset until the visual strike and the audio strike align to the millisecond.

5. Consolidating the Animation Budget

When targeting unified memory architecture, every keyframe costs memory.

5.1 Delete Interior Animations

If your train has animated interior compartment doors that open when passengers walk through them, delete them for the console build.

Console players primarily play zoomed out, managing macro-logistics. The VRAM and CPU cost of calculating interior kinematic data for 500 individual passengers opening tiny doors across the map is a total waste of the hardware budget.

5.2 The 30-Frame Limit

When using complex exported animations (where you baked the keyframes in Blender rather than scripting them in Lua), strictly limit your baked animations to 30 frames per second. Exporting a 60 FPS or 120 FPS animation curve doubles or quadruples the size of the .ani file for a visual smoothness that the game engine’s internal tick-rate will largely ignore anyway.

6. Summary: The Pre-Publish Animation Audit

Before compiling your vehicle payload for the Mod.io upload API, run your skeletal structure through this strict mechanical audit:

Draw Call Consolidation: Are identical moving parts (like all left-side doors) merged into a single mesh node to save Draw Calls?

Radius Precision: Do the axles radius variables perfectly match the actual geometric radius of the wheel meshes to prevent sliding?

Keyframe Clipping: Do your event translations move cleanly without clipping through adjacent geometry?

Kinematic Efficiency: Are you utilizing fake_bogies for steam rods rather than heavy, manual keyframe arrays?

Audio Sync: Does the visual culmination of the moving parts match the audio triggers in the soundset?

Mastering animation scripts transforms your 3D models from static statues into heavy, roaring machines. By optimizing your node hierarchies and respecting the CPU math limits, your vehicles will bring living, breathing infrastructure to console networks without ever dropping a frame.



Leave a Reply

Your email address will not be published. Required fields are marked *