ReadonlyunitsReadonlyweaponsReadonlyweaponReadonlyfactionsReadonlyabilitiesReadonlydetachmentsReadonlyenhancementsReadonlystratagemsReadonlywargearReadonlywargearReadonlymissionsReadonlymissionReadonlymissionReadonlydeploymentReadonlyforceReadonlyterrainReadonlyterrainReadonlyresourceReadonlyleaderReadonlyunitReadonlygameReadonlytimingReadonlyinteractionReadonlyphaseStaticembeddedThe dataset built from the package's embedded data.
Phases a source acts in, unioned across its phase-mappings.
Resolve a terrain layout to absolute board-space vertices using this
dataset's embedded terrain-template catalog — the layout-id →
renderable-geometry hop. Mirror of Rust Dataset::resolve_terrain; the
geometry is pinned by the terrain-resolver conformance corpus.
The terrain layouts a deployment pattern recommends, in declared order, skipping any ids absent from the dataset.
Weapons whose profiles reference the given weapon-keyword id.
Wargear options authored for the given unit, in declared order. Mirror of
Rust Dataset::wargear_options_of. Empty for a unit with no options.
Leaders whose leader-attachment data lists bodyguardUnitId among its
eligible body units, sorted by name. The attachment is stored on the
leader pointing down to its bodyguards, so answering "which leaders can
attach to this unit?" means scanning the attachment list. Returns an empty
array for a unit that no leader can attach to (including leader units).
The inverse of leadersAttachableTo: the body units the given
leader can attach to, sorted by name. Scans the same leader-attachment
data from the leader's side (leader_id matches; resolve each
eligible_bodyguard_ids entry), deduped by id. Empty for a non-leader
unit. Together the two queries give the bidirectional attachment graph the
SPA needs to offer a partner dropdown from either end.
Enumerate every ability that could apply to the given unit in phase,
grouped by source. The SPA uses this to render the abilities pane.
Attacker-perspective Buff stack for a (unit, phase) combination: intrinsic weapon-profile keywords plus every eligible ability whose DSL effect translates to an attacker-side buff (army, detachment, unit, attached members, support, plus any stratagems the caller has opted into).
The result includes only buffs the buff layer can express today — the
unsupported half of the DSL→Buff translation is dropped here so callers
who just want the stack don't need to thread diagnostics through. Use
AbilityView.describeBuffs when you need the diagnostics for an
individual ability. Symmetric to defensiveBuffsFor, which walks
the same eligibility set under target perspective.
OptionalweaponProfiles?: { weaponId: string; profileIndex: number }[]OptionaloptedInStratagemIds?: string[]Stratagem ids the caller has opted into spending CP on.
Defender-perspective buff stack for the chosen unit: walks the same
eligible-abilities set as buffsFor but translates each ability's
DSL effect as defensive (FNP, save mods from stat-modifier Sv,
toughness mods from stat-modifier T, save rerolls, incoming hit
penalties from bs-modifier). Use this when the chosen unit is being
crunched as the target — the engine reads feelNoPain/saveMod/
toughnessMod out of resolveBuffs so wiring the result into crunch
just means concatenating onto the existing buffs array.
weaponProfiles are ignored under target perspective — weapon-keyword
effects ride with the firing weapon, not the receiving unit.
Enumerate every attacker-side buff a unit could stack in context as a
list of toggleable levers, plus the activation groups that limit them.
Unlike buffsFor — which returns only the buffs that auto-apply —
this surfaces the player decisions too: stratagems, and the activatable
gates the DSL models as dice-pool options, choice branches, or
timing-gated activations (e.g. Blessings of Khorne's three keyword grants).
Each lever carries enabled (its default state) and, where it's part of a
limited pool, a group id whose StackableBuffGroup caps how many
can fire at once. The intended loop:
const { buffs } = ds.stackableBuffsFor(input, ctx);
const chosen = buffs.filter(b => b.enabled).flatMap(b => b.buffs);
crunch({ ...profiles, buffs: chosen, context: ctx }, ds);
Target/phase conditions a lever still carries (e.g. "vs Infantry") ride on
each buff's applicableWhen, so toggling it on is always safe — the
resolver gates it per-target.
The whole dataset, with linked accessors over every entity collection.