Skip to main content
Vehicle MC wiki

Wiki

Vehicle MC Wiki

Vehicle configuration, rig backends, service systems, terrain handling, and combat-ready admin workflows.

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.

Service and World

Handle vehicle servicing, repair tools, fuel tanks, spawnpoints, and station behavior.

Vehicle Content

Spawn Pools, Tables, and Display Props

Separate world props, weighted tables, and physical spawnpoints so distribution stays readable and safe.

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 radius
  • tables: weighted selection lists for vehicle bases and variants
  • spawnpoints: physical world entries that use a pool and a table

The current example shape is:

YAML
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_ENTER
  • DISPLAY_REDEEM_KEY
  • DIRECT_SPAWN

Use them for very different jobs:

  • DISPLAY_ENTER: best for showroom props, garages, hubs, and event areas where clicking should become instant vehicle entry
  • DISPLAY_REDEEM_KEY: best for rewards, displays, crates, island claim systems, and safe one-item redemption flow
  • DIRECT_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:

YAML
pools:
  default:
    enabled: true
    maxActive: 25
    respawnSeconds: 900
    activationRadius: 128

These fields mean:

  • enabled: lets you disable a pool without deleting its structure
  • maxActive: caps how many active props or spawns that pool can maintain
  • respawnSeconds: controls how quickly missing props come back
  • activationRadius: 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.

YAML
tables:
  default_table:
    dirtbike:
      weight: 40
      variants:
        default: 35
        red: 5
    jeep:
      weight: 20

This 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:

  1. creating one stable pool
  2. building one good table
  3. testing one spawnpoint mode
  4. checking respawn and interaction behavior
  5. only then scaling up across the world