Skip to main content
Vehicle MC wiki

Wiki

Vehicle MC Wiki

Vehicle configuration, rig backends, service systems, terrain handling, and combat-ready admin workflows.

Vehicle Authoring

Learn the top-down YAML flow so you know what belongs in config.yml, vehicles.yml, service files, and player-side UI files.

Service and World

Handle vehicle servicing, repair tools, fuel tanks, spawnpoints, and station behavior.

Vehicle Content

Fuel Tanks, Repair Stations, and World Service

Use fuel_tanks.yml to author refill points, repair stations, leak hazards, and staged world infrastructure safely.

fuel_tanks.yml is where Vehicle MC stops being only a drivable-content plugin and starts acting like a real world service system.

This file is responsible for:

  • world fuel tanks
  • repair stations
  • hose visuals
  • leaks
  • collision damage
  • staged explosions
  • respawn timing

Quick routes:

If the server needs physical infrastructure instead of only vehicles, this file matters.

The basic shape

The default fuel tank file is organized around tankTypes.

YAML
tankTypes:
  basic_tank:
    displayName: "&eFuel Tank"
    modelItem: minecraft:barrel
    hitbox:
      halfExtents: [0.8, 1.2, 0.8]
      offset: [0.0, 1.0, 0.0]
    health: 500
    fuelSupply:
      infinite: true
    service:
      mode: FUEL

That means each tank type is a reusable world-service definition, not a one-off hardcoded block.

What one tank type can already control

The default tank type already exposes all of these lanes:

  • render model
  • scale and display offset
  • hitbox
  • total health
  • infinite or finite fuel supply
  • interaction range
  • pour behavior
  • service mode
  • repair scheduler
  • repair FX and sounds
  • idle FX
  • hose visuals
  • collision damage
  • leak behavior
  • chain reaction behavior
  • respawn timing
  • multi-stage explosion choreography

This is why fuel_tanks.yml deserves its own page. It is not a tiny helper file.

Service mode is the first important decision

The file already supports:

  • FUEL
  • REPAIR
  • BOTH

That one choice changes how the whole station reads in-world.

Use:

  • FUEL for classic refill points
  • REPAIR for workshop or service-bay style props
  • BOTH when one station should act like a real combined support point

Fuel supply and interaction

The public feel of a station starts here:

YAML
fuelSupply:
  infinite: true
  supplyUnits: 0
interaction:
  maxUseRange: 4.0
  allowPour: true
  allowInstant: false
  pour:
    everyTicks: 2

Interpretation:

  • infinite decides whether the station is a permanent utility or a managed resource
  • allowPour vs allowInstant changes whether the station feels grounded and physical or more arcade-like
  • everyTicks shapes how fast the service action updates

Repair mode is already effect-rich

The default repair station block does not only toggle repair on or off. It already has a real effect stack:

YAML
repair:
  enabled: false
  everyTicks: 4
  stepPercent: 1.0
  fx:
    particle:
      enabled: true
      type: ELECTRIC_SPARK
      count: 2
  sounds:
    loop:
      enabled: false
      sound: "minecraft:block.anvil.use"

That means a repair station can already feel like:

  • a quiet utility pad
  • a mechanical workshop
  • a more stylized arcade service point

without rewriting code.

Hose visuals and station realism

The hose block is a major realism lane:

YAML
hose:
  enabled: false
  modelItem: minecraft:black_concrete
  scale: 0.2
  segments: 16
  maxLength: 8.0
  lingerTicks: 20
  extendTicks: 10
  curveHeight: 0.35

Interpretation:

  • segments and segmentSpacing shape visual density
  • maxLength controls how forgiving the station feels
  • curveHeight changes whether the hose feels rigid or naturally draped

This is the sort of detail that makes a fuel point feel real instead of fake.

Leak, impact, and chain-reaction behavior

The current file is already much deeper than "tank explodes when destroyed."

It supports:

  • health-threshold leaks
  • projectile-triggered leaks
  • impact fuel chance
  • impact flame chance
  • burst FX
  • sound hooks
  • optional chain reaction radius and damage

That means one tank can behave like:

  • a durable service prop
  • a risky explosive objective
  • a cinematic battlefield hazard

Explosion stages are already choreographed

The default fuel tank file exposes a multi-stage explosion structure:

YAML
explosion:
  enabled: true
  stages:
    - delayTicks: 0
      radius: 12.0
      maxEntityDamage: 0.0
      vehicleDamage: 0.0
    - delayTicks: 8
      radius: 35.0
      maxEntityDamage: 6.0
      vehicleDamage: 120.0

That is a very different tool from one flat boom.

Use staged explosions when you want:

  • warning flash first
  • a delayed main blast
  • better dramatic readability
  • stronger vehicle-specific damage later in the sequence

Copyable combined service station example

YAML
tankTypes:
  depot_service:
    displayName: "&eDepot Service Station"
    modelItem: minecraft:barrel
    scale: 1.0
    hitbox:
      halfExtents: [0.8, 1.2, 0.8]
      offset: [0.0, 1.0, 0.0]
    health: 650
    fuelSupply:
      infinite: true
    interaction:
      maxUseRange: 4.5
      allowPour: true
      allowInstant: false
      pour:
        everyTicks: 2
    service:
      mode: BOTH
    repair:
      enabled: true
      everyTicks: 4
      stepPercent: 1.0
    hose:
      enabled: true
      modelItem: minecraft:black_concrete
      scale: 0.2
      segments: 16
      maxLength: 8.0
      lingerTicks: 20
      extendTicks: 10
      curveHeight: 0.35
    respawn:
      enabled: true
      respawnSeconds: 300

This is a good baseline when you want one dependable world service point before you start authoring combat-hazard variants.

Suggested order

  1. build one safe fuel-only station first
  2. validate interaction range and hose feel
  3. add repair second
  4. add leak and explosion behavior only if the location is meant to be dangerous
  5. keep chain reactions disabled until the battlefield design actually needs them