
Wiki
Vehicle MC Wiki
Vehicle configuration, rig backends, service systems, terrain handling, and combat-ready admin workflows.
Getting Started
Start here for the real first-boot checks, module setup, and the runtime surfaces that affect every server.
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.
YML File Guides
Jump straight into the exact YAML file guide you need when you already know the filename and want the public explanation fast.
Vehicle Content
Build readable vehicle families, terrain behavior, browse layers, and driver feedback.
Service and World
Handle vehicle servicing, repair tools, fuel tanks, spawnpoints, and station behavior.
Combat and Ecosystem
Connect Vehicle MC to Duck Shot and the combat stack without losing control of performance or readability.
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:
- open the dedicated
fuel_tanks.ymlguide - open the service-tool guide
- open the spawnpoint and hose guide
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.
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: FUELThat 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:
FUELREPAIRBOTH
That one choice changes how the whole station reads in-world.
Use:
FUELfor classic refill pointsREPAIRfor workshop or service-bay style propsBOTHwhen one station should act like a real combined support point
Fuel supply and interaction
The public feel of a station starts here:
fuelSupply:
infinite: true
supplyUnits: 0
interaction:
maxUseRange: 4.0
allowPour: true
allowInstant: false
pour:
everyTicks: 2Interpretation:
infinitedecides whether the station is a permanent utility or a managed resourceallowPourvsallowInstantchanges whether the station feels grounded and physical or more arcade-likeeveryTicksshapes 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:
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:
hose:
enabled: false
modelItem: minecraft:black_concrete
scale: 0.2
segments: 16
maxLength: 8.0
lingerTicks: 20
extendTicks: 10
curveHeight: 0.35Interpretation:
segmentsandsegmentSpacingshape visual densitymaxLengthcontrols how forgiving the station feelscurveHeightchanges 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:
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.0That 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
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: 300This is a good baseline when you want one dependable world service point before you start authoring combat-hazard variants.
Suggested order
- build one safe fuel-only station first
- validate interaction range and hose feel
- add repair second
- add leak and explosion behavior only if the location is meant to be dangerous
- keep chain reactions disabled until the battlefield design actually needs them

