Damage Routing, Collision Damage, and Destruction Safety

Vehicle MC splits combat safety into a few different files on purpose:

• combat.yml decides high-level damage routing and performance budgets
• components.yml decides subsystem HP targets
• collisions.yml decides whether impact damage is real or mostly cosmetic
• destruction.yml decides whether world damage is allowed and how restoration behaves

If these files are tuned without a plan, armed vehicles become confusing very quickly.

Start with combat.yml

The main combat policy file already exposes the most important runtime switches:

combat:
  enabled: false
  damage:
    globalDamageScalar: 1.0
    cosmeticOnly: false
    dualWriteToVehicleHp: true
    destroyVehicleOnZeroHp: true
  inbound:
    genericProjectileIngressEnabled: true
    genericExplosionIngressEnabled: true

These settings answer big questions:

• Is combat actually enabled?
• Is inbound combat only cosmetic, or does it matter?
• Does subsystem damage also affect the shared vehicle HP bar?
• Should a zero-HP vehicle be destroyed automatically?

Budgets are just as important as damage

The same file also contains the safety budgets:

cooldowns:
  collisionImmunityTicks: 10
  explosionDoubleHitGuardTicks: 4
  repairDelayTicks: 40
persistence:
  enabled: true
  autosaveSeconds: 30
budgets:
  maxProjectilesPerTick: 300
  maxExplosionsPerTick: 32
  maxBlockBreaksPerTick: 128
  maxRegenOpsPerTick: 128

These are not filler numbers. They decide how much combat activity the plugin is allowed to process before the server starts feeling heavy.

components.yml decides what can break

Subsystem HP is where vehicles stop being one flat health bar:

components:
  defaults:
    hp:
      engine: 100.0
      transmission: 80.0
      wheels: 60.0
      rotor: 70.0
      ammo_rack: 60.0
      fuel_tank: 60.0

This lets you make choices like:

• wheeled vehicles that are easy to immobilize
• helicopters that become vulnerable through rotor damage
• tanks that are safer frontally but risky around ammo rack and optics

If combat is enabled, component design is one of the biggest feel-makers in the whole stack.

collisions.yml decides whether impact is gameplay

Collision damage has its own lane:

collisions:
  enabled: true
  tickInterval: 2
  pairCooldownTicks: 10
  minRelativeSpeed: 0.05
  baseDamage: 1.0
  speedScalar: 14.0
  maxDamage: 60.0
  massClasses:
    light: 1.0
    medium: 1.5
    heavy: 2.2

This file decides whether ramming should feel like:

• a mostly visual effect
• a mild punishment
• a real tactical tool

Mass classes are especially important because they stop a tiny vehicle and a superheavy platform from feeling physically identical in a crash.

destruction.yml decides whether the world pays for combat

World damage is gated even more tightly:

destruction:
  enabled: false
  maxBlocksBrokenPerTick: 128
  maxRegenPerTick: 128
  queuePersistence: true
  restoreOnStartup: true

This is the difference between:

• vehicles that fight each other without harming the map
• vehicles that can tear up the world but restore it safely

For most public servers, it is smart to leave destruction off until the rest of the combat stack already feels stable.

Recommended rollout

1. Enable combat only after the base vehicle handling feels correct.
2. Set readable component HP first.
3. Keep collision damage conservative.
4. Leave world destruction off during early testing.
5. Watch budgets and cooldowns before adding bigger combat scenes.

Related pages

• combat Components, Duck Shot Bridge, Projectiles, and Loadouts
• weapon Presets, Turret Groups, and Loadout Staging
• fuel Containers, Repair Tools, and Service Sessions