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.

Combat and Ecosystem

Weapon Presets, Turret Groups, and Loadout Staging

Understand the dedicated armed-vehicle preset files and stage them safely instead of bloating vehicles.yml.

Vehicle MC already reserves dedicated files for armed-vehicle content:

  • weapons.yml
  • projectiles.yml
  • turrets.yml
  • vehicle_loadouts.yml

In the current public resource set, those files are intentionally light:

YAML
weapons:
  presets: {}
YAML
projectiles:
  types: {}
YAML
turrets:
  groups: {}
YAML
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 definitions
  • projectiles.yml: reusable projectile behavior
  • turrets.yml: turret grouping and mounting logic
  • vehicle_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.yml
  • components.yml
  • duckshot_bridge.yml
  • the vehicle's own seat and component structure

That means a safe rollout sequence is:

  1. make the vehicle drive correctly
  2. make the component damage model readable
  3. connect Duck Shot carefully if needed
  4. 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.yml decides weak points like barrel, optics, tracks, and ammo rack
  • duckshot_bridge.yml decides what outside weapons can affect it
  • later, turrets.yml and vehicle_loadouts.yml can 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.