
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 already reserves dedicated files for armed-vehicle content:
weapons.ymlprojectiles.ymlturrets.ymlvehicle_loadouts.yml
In the current public resource set, those files are intentionally light:
weapons:
presets: {}projectiles:
types: {}turrets:
groups: {}vehicleLoadouts:
presets: {}That is still important information for server owners, because it tells you the plugin expects a separated combat-content structure rather than one giant unreadable vehicle file.
What each file should own
Even before you fill them in heavily, the separation already makes sense:
weapons.yml: reusable vehicle weapon definitionsprojectiles.yml: reusable projectile behaviorturrets.yml: turret grouping and mounting logicvehicle_loadouts.yml: which armed package a vehicle or variant should actually receive
Treating those as separate layers keeps armed content maintainable.
Do not force all combat logic into vehicles.yml
vehicles.yml should describe the vehicle itself:
- controller type
- movement and fuel behavior
- seats and hitboxes
- model and rig structure
It should not become the only home for:
- every cannon preset
- every projectile profile
- every turret rule
- every loadout variation
That is exactly why these dedicated combat-content files exist.
Current best practice while the preset files are still light
Right now, most live armed-vehicle behavior is easier to reason about through:
combat.ymlcomponents.ymlduckshot_bridge.yml- the vehicle's own seat and component structure
That means a safe rollout sequence is:
- make the vehicle drive correctly
- make the component damage model readable
- connect Duck Shot carefully if needed
- only then begin building preset libraries for weapons, turrets, and loadouts
Example staging approach
If you are planning a tank family, separate the problems:
- the tank base decides weight, seats, and hitboxes
components.ymldecides weak points like barrel, optics, tracks, and ammo rackduckshot_bridge.ymldecides what outside weapons can affect it- later,
turrets.ymlandvehicle_loadouts.ymlcan decide which turret package and shell family belong to which tank variant
That keeps the armed content understandable instead of locking everything inside one bloated vehicle definition.
Honest public takeaway
For the current public resource snapshot:
- the structure for a serious armed-vehicle library already exists
- the preset files are more of a framework than a final public arsenal
- most servers should not treat them as mandatory on day one
That is a good thing. It means you can stage armed vehicles deliberately instead of inheriting a giant, confusing combat stack all at once.

