Vehicle Families, Variants, Fuel, and World Service Systems

vehicles.yml is where Vehicle MC turns the global runtime into actual drivable content.

This file is large because it has to describe:

• the base vehicle family
• default behavior
• one or more variants
• seats
• fuel
• trunk
• horn
• hitboxes
• damage and impact rules
• lifecycle and despawn behavior

The structure that matters

The default file uses a layered layout:

defaults:
  stats:
    fuel:
      enabled: true
 
bases:
  dirtbike:
    controller: GROUND
    physics:
      ground:
        accel: 0.035
    variants:
      standard_gray:
        price: 3000.0

That pattern is useful because it keeps shared behavior in one place while still letting variants have their own identity.

Base families are where the real design happens

Each bases.<id> entry is where the plugin decides what kind of machine this thing actually is.

The dirtbike example already demonstrates that a base family can own:

• controller type
• model and rig hints
• physics
• stats
• lifecycle
• seat layout
• FX profile
• variant list

That is why you should treat the base entry as the design home of the vehicle, not as an afterthought.

What belongs in bases.<id>

Each base entry usually defines:

• display name
• controller type
• model and rig hints
• physics
• stats
• lifecycle
• seats
• FX profile
• variants

This is the level where you decide if the vehicle is:

• a dirt bike
• a truck
• a plane
• a helicopter
• a heavy platform

Seats are part of the content design, not only a mount point

The current file already exposes explicit seat ids, roles, and offsets.

seats:
  - id: driver
    role: DRIVER
    offset:
      - 0.0
      - -0.8
      - -0.6
  - id: passenger1
    role: PASSENGER
    offset:
      - 0.0
      - -0.65
      - -1.6

Interpretation:

• seat layout is part of how the vehicle feels
• a cramped scout vehicle and a troop carrier should not share the same passenger logic
• good seat offsets are just as important as good accel values

Variants are presentation-plus-policy

Variants are not only recolors. In Vehicle MC they are the clean place to vary:

• model item
• aliases
• price
• display name
• specific flavor overrides

That is why the file can support one base family with multiple public versions without duplicating the entire base entry every time.

If you want the publishing side of that workflow in more detail, continue into lifecycle, Persistence, Variants, and Alias Publishing.

Components and damage layering

The current source also includes a shared combat component defaults file:

components:
  defaults:
    hp:
      engine: 100.0
      transmission: 80.0
      wheels: 60.0
      rotor: 70.0
      wings: 70.0
      fuel_tank: 60.0

That means the vehicle family can be understood on two levels:

• the whole vehicle as a drivable object
• the internal combat components that can fail or become critical

This is an important split for armed or high-value vehicles.

Fuel inside the vehicle vs fuel in the world

There are two different fuel ideas in Vehicle MC:

• vehicle fuel and interaction inside vehicles.yml
• world stations inside fuel_tanks.yml

Keep them separate in your head:

• vehicles.yml says whether the vehicle uses fuel and how it behaves
• fuel_tanks.yml says where that fuel service exists in the world

Suggested order

1. build one strong base vehicle
2. add clean variants
3. validate seating and interaction
4. confirm trunk, horn, fuel, and lifecycle behavior
5. add a world tank or repair station
6. only then move into armed or heavily scripted systems

Recommended next pages

• core Config, Runtime, and Rig Backends
• vehicle Interactions, Entry, Exit, Trunks, Horns, and Pickup
• lifecycle, Persistence, Variants, and Alias Publishing
• fuel Tanks, Repair Stations, and World Service
• catalog, UI, Surfaces, and Driver Feedback
• duck Shot Bridge, UI, and Operator Workflows
• vehicle Bases, Controllers, Stats, Seats, and Hitboxes
• fuel Containers, Repair Tools, and Service Sessions