Skip to content

Spawnable groups

What it is

Two families of "things to spawn in game", declared in different places.

File What it is How you call it
Aircraft src/spawnables.yaml template aircraft groups, prefixed veafSpawn- radio menu commands / markers
Ground and sea src/spawn-groups.yaml aliases pointing at unit compositions _spawn unit <alias> / _spawn group <alias>

The smallest example that works — ground and sea

src/spawn-groups.yaml ships fully commented: as-is it adds nothing. Uncomment and adapt:

units:                              # -> `_spawn unit <alias>`
  - aliases: [myaaa]
    unitType: ZSU-23-4 Shilka

groups:                             # -> `_spawn group <alias>`
  - aliases: [mysam]
    disposition: {h: 3, w: 3}       # layout grid, in 10 m cells
    units:
      - {type: ZSU-23-4 Shilka, cell: 1}
      - {type: Ural-375, random: true}
      - {type: Soldier M4, number: {min: 2, max: 4}, random: true}
    description: My custom SAM site
    groupName: MySAM

In game, an F10 map marker reading _spawn group, name mysam spawns the composition there. The marker syntax is in the aliases.

The smallest example that works — aircraft

This one is not written by hand: a DCS aircraft group runs to hundreds of lines. You build it in the DCS editor, name it with the veafSpawn- prefix, then extract it:

.\veaf-tools.exe extract-aircraft-groups my-mission.miz --kind spawnable

src/spawnables.yaml is rewritten with your groups. The next build injects them back.

Until you have extracted anything

A freshly prepared folder gets an empty src/spawnables.yaml, and the build then injects the spawnable-group catalogue shipped with veaf-tools. Empty therefore means "I add nothing to the shipped catalogue", not "I want nothing" — to inject nothing, it is spawnable_aircrafts: false under pipeline: in mission.yaml.

As soon as the file holds a group — from the first extraction onwards — it stands alone, and the shipped catalogue is no longer read. To pick up the entries a later release adds, without losing yours:

.\veaf-tools.exe content pull-aircraft-groups --kind spawnable
.\veaf-tools.exe content pull-aircraft-groups --kind spawnable --add-new

The full rule, with the table of all three cases, is on the Dynamic slots page: both catalogues behave exactly alike.

The gotcha

The name prefix decides the family, not the file. An aircraft group named veafSpawn-… belongs in spawnables.yaml; a group flagged dynSpawnTemplate: true belongs in dynamic-slot-templates.yaml — and the dynSpawnTemplate flag wins over the prefix if a group carries both.

The group's side matters too. A -cap or an -afac only draws from the veafSpawn- groups of the side that asks for it and from the neutral ones, which serve everybody: put your red adversaries in a red coalition. When none of those matches the requested name, the draw falls back to the other side's groups, and dcs.log says so.

Another gotcha: an entry in spawn-groups.yaml reusing an alias the framework already knows replaces it. Useful to redefine a standard group, surprising when it was not intended.

Going further