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 file for Vehicle MC.
It decides how vehicle props, key displays, and direct spawn locations appear in the world.
This file matters when you want vehicles to exist as part of the server world instead of only being handed out by commands.
What the current file already contains
The current resource file is organized around:
schedulerpoolstablesspawnpoints
Example:
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]That split is important because it keeps:
- world timing
- spawn safety
- content weighting
- physical placement
as separate problems.
scheduler
This controls how often the spawn system processes its work.
Most servers should leave this conservative unless they have a clear reason to push it harder.
The spawn layer should feel reliable first. Speed comes second.
pools
Pools are the server-safety rules for the spawn system.
Important fields include:
enabledmaxActiverespawnSecondsactivationRadius
These decide:
- whether the pool is live
- how many active props or spawns it can maintain
- how quickly the world refills missing entries
- whether distant inactive areas should stay quiet
tables
Tables decide what actually appears.
The current structure supports:
- weighted base-family selection
- optional variant weighting under the base family
That means the server can say:
- dirtbikes are common
- trucks are rarer
- one color or one version inside a family should appear more often
This is one of the best places to make the world feel selected instead of random.
spawnpoints
Spawnpoints are the physical world placements.
The important thing is that the file keeps them as a managed list instead of hiding them inside other systems.
That is a good public workflow because it keeps one placement layer that can be edited and audited more easily.
The three supported spawn modes
The current file and docs already describe three important high-level behaviors:
DISPLAY_ENTERDISPLAY_REDEEM_KEYDIRECT_SPAWN
Use them deliberately:
DISPLAY_ENTERfor display props that should become a vehicle immediatelyDISPLAY_REDEEM_KEYfor props or hubs that should hand off a keyDIRECT_SPAWNfor strict spawn pads or service-style locations
The wrong mode can make a world setup feel confusing very quickly.
Why pools and tables should exist before lots of spawnpoints
Do not start by hand-placing a giant world full of entries.
Start with:
- one pool
- one table
- one spawn mode
- one real test location
Then scale up once the world behavior is understandable.
Suggested order
- Build one safe pool first.
- Make one readable weighted table.
- Test one spawn mode at one location.
- Confirm respawn timing and activation radius.
- Expand only after the first public loop feels clear.