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.
Vehicle MC feels polished or unfinished long before players understand the physics. A lot of that first impression comes from messages.yml and ui.yml.
These files control:
- how the plugin speaks to players
- what appears in the action flow around keys and pickups
- what a driver sees while seated
- how much information the vehicle HUD exposes
Quick routes:
messages.yml is your public voice
The message file already covers more than generic errors:
messages:
prefix: "&6VehicleMC &8ยป &7"
ย
noPermission: "%prefix%&cNo permission."
playerOnly: "%prefix%&cThis command can only be used in-game."
ย
usage:
spawn: "%prefix%&cUsage: /vehicle spawn <type> [variant]"
ย
errors:
vehicleNotFound: "%prefix%&cVehicle not found."It also handles:
- pickup failures
- trunk warnings
- stored-key errors
- key redemption messaging
- info output lines
- actionbar responses for spawn redemption
That means messages.yml is not optional polish. It is a large part of the plugin's usability.
Rewrite messages around your actual audience
If players are not expected to know internal terms like "stored key" or "persisted record", your messages should not sound like internal logs.
A better player-side tone usually:
- says what happened
- says what to do next
- avoids technical blame language
For example:
messages:
errors:
vehicleNotFound: "%prefix%&cNo vehicle was found nearby."
keysDisabled: "%prefix%&cVehicle keys are disabled on this server."
success:
pickup: "%prefix%&aVehicle stored. Your key was added to your inventory."The info block is a support tool too
messages.yml also shapes the output of the info view:
info:
lineType: "&7Type: &f%type% &8(%display%)"
lineHpFuel: "&7HP: &f%hp%&7/&f%hpMax% &8| &7Fuel: &f%fuel%&7/&f%fuelMax%"
lineController: "&7Controller: &f%controller%"This is one of the best places to make staff support easier. If your support team or moderators use vehicle info often, keep these lines compact, readable, and consistent.
ui.yml controls the live driving HUD
The bossbar file decides how loud the driving HUD is:
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: falseYou are making three decisions here:
- how often the HUD updates
- which metrics matter while driving
- how arcade-like or simulation-like the driving experience should feel
Thresholds change mood, not just color
Bossbar thresholds are not cosmetic trivia:
thresholds:
yellowBelow: 0.6
redBelow: 0.3Higher warning thresholds make driving feel cautious and high-pressure. Lower thresholds make it feel calmer and more forgiving.
That means the color system is part of gameplay tone, not just art direction.
Suggested order
- Rewrite the main errors and success lines first.
- Make pickup and key-redemption wording crystal clear.
- Decide whether speed belongs on the driver HUD at all.
- Keep HP and fuel bossbars readable before adding extra noise.
- Test with a normal player, not just staff who already know the system.