
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.
spawns.yml is the world-distribution layer for Vehicle MC.
It is not just a random spawner file. It decides how public vehicle props appear, how often they come back, and whether interacting with them should:
- spawn a live drivable vehicle
- hand out a redeemable key
- act like a decorative but interactive display
The three main building blocks
The file is organized around:
pools: global rules like caps, respawn timers, and activation radiustables: weighted selection lists for vehicle bases and variantsspawnpoints: physical world entries that use a pool and a table
The current example shape is:
scheduler:
tickIntervalTicks: 20
Â
pools:
default:
enabled: true
maxActive: 25
respawnSeconds: 900
activationRadius: 128
Â
tables:
default_table:
dirtbike:
weight: 40
variants:
default: 35
red: 5
Â
spawnpoints: [item]Choosing the right spawn mode
Vehicle MC already documents three important spawnpoint modes:
DISPLAY_ENTERDISPLAY_REDEEM_KEYDIRECT_SPAWN
Use them for very different jobs:
DISPLAY_ENTER: best for showroom props, garages, hubs, and event areas where clicking should become instant vehicle entryDISPLAY_REDEEM_KEY: best for rewards, displays, crates, island claim systems, and safe one-item redemption flowDIRECT_SPAWN: best for controlled world service points or dedicated spawn pads where a full vehicle should appear immediately
If you mix these up, the system feels confusing very quickly.
Pools: where server safety starts
The pool layer protects the world from runaway spawn behavior:
pools:
default:
enabled: true
maxActive: 25
respawnSeconds: 900
activationRadius: 128These fields mean:
enabled: lets you disable a pool without deleting its structuremaxActive: caps how many active props or spawns that pool can maintainrespawnSeconds: controls how quickly missing props come backactivationRadius: avoids running the full logic for nobody
If you are still tuning a public hub, keep these conservative first.
Tables: curating what players actually see
Tables are how you prevent vehicle props from feeling random or sloppy.
tables:
default_table:
dirtbike:
weight: 40
variants:
default: 35
red: 5
jeep:
weight: 20This lets you control:
- which base families are common
- which ones are rare
- which variants dominate that family
That means tables should reflect your server identity, not just every vehicle you own.
Spawnpoints should be authored last
The file notes that spawnpoints are a managed list and are usually created through admin commands or the editor.
That is the right workflow.
Do not start by hand-authoring a giant list of spawnpoints. Start by:
- creating one stable pool
- building one good table
- testing one spawnpoint mode
- checking respawn and interaction behavior
- only then scaling up across the world

