
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.
Some of Vehicle MC's most important public behavior lives outside the main vehicle physics files.
This layer covers:
- how players browse vehicles
- how they receive keys
- how spawn displays behave
- what they see in bossbars
- how the plugin talks back through messages
The most important files here are:
catalog.ymlkeys.ymlspawns.ymlui.ymlmessages.yml
Quick routes:
- open the
catalog.ymlguide - open the
keys.ymlguide - open the
spawns.ymlguide - open the
ui.ymlguide - open the
messages.ymlguide
catalog.yml
The catalog is the browse layer for the vehicle library.
Example:
catalog:
root:
title: '&0Vehicle Catalog'
rows: 3
entries:
dirtbike:
slot: 10
base: dirtbike
icon: minecraft:diamond_hoe{Damage:10}
name: '&6Dirt Bike'
lore:
- '&7Click to view variants'This file decides:
- where each family sits in the menu
- which icon and name it uses
- how variants are introduced
That means the catalog is selected, not random.
ui.yml
ui.yml controls the driver-facing bossbars.
ui:
updateEveryTicks: 2
bossbars:
hp:
enabled: true
style: SEGMENTED_10
title: '&c&lHP &7- &f{hp}/{hp_max} &7({percent}%)'
fuel:
enabled: true
style: SEGMENTED_10
title: '&e&lFuel &7- &f{fuel}/{fuel_max} &7({percent}%)'
speed:
enabled: falseThis is where you decide whether the plugin feels:
- minimal
- utility-focused
- more arcade-like
- heavily instrumented
keys.yml
Keys are not just simple give-items. They have their own public identity and effect hooks.
Example:
keys:
baseItem: minecraft:tripwire_hook{CustomModelData:12001}
nameTemplate: '&6%vehicle_type_name% &7Key'
redeemMode: on_use
requireNonCreative: falseThis file controls:
- the base item used for keys
- naming and lore
- redeem behavior
- creative-mode restrictions
It also supports default and per-type visual effects for actions like:
- prop spawn
- prop despawn
- claim success
- key redeem success
spawns.yml
spawns.yml is the public prop and spawnpoint system.
It is organized around:
- pools
- tables
- spawnpoints
The supported high-level modes already include:
DISPLAY_ENTERDISPLAY_REDEEM_KEYDIRECT_SPAWN
That means a spawnpoint can act like:
- a display prop you can enter
- a display prop that gives a key
- a direct drivable spawn point
messages.yml
messages.yml is the language and feedback file.
This is where you shape:
- prefix styling
- usage text
- error text
- success text
- pickup warnings
- info output
- spawn redemption feedback
If the plugin feels harsh, confusing, or unfinished to normal players, this file is one of the best places to improve it.
Suggested order
- Curate the catalog first so the library feels readable.
- Enable only the bossbars that actually help.
- Set key naming and redeem behavior before rolling keys into a live economy.
- Build one spawn pool and one clean table before adding lots of spawnpoints.
- Rewrite important player-side messages so the server sounds consistent.

