DAI 4.1 · STEP-BY-STEP · dai_state

State & Capabilities

Create typed state, persistence, synchronization and named capabilities without falling back to ad-hoc scoreboards for every system.

Build from scratchTest in Minecraft4.1 source-aligned

1. Decide what state you actually need

Use a state when a value must survive between actions: health-like resources, progression, job, rank, flags, counters or shared world/server facts.

Type	Use it for
`boolean`	on/off flags
`number`	resources, ranks, counters, numeric progression
`string`	job IDs, modes, labels and state names

2. Pick the scope

client_session · player · entity · dimension · world · server

Important: client_session is forced non-persistent and non-synchronized. All other scopes are server-owned; use client_writable only when you intentionally allow client mutation.

3. Create the definition

Put the JSON under data/<namespace>/dai_state/.

data/my_game/dai_state/stamina.json

{
  "type": "number",
  "scope": "player",
  "default_number": 100,
  "persistent": true,
  "sync": true,
  "client_writable": false
}

4. Mutate it through actions

state_set_boolean

state_set_number

state_set_string

state_add_number

state_toggle_boolean

state_clear

Capabilities

Capabilities are session-scoped named abilities with source ownership, so multiple systems may provide the same capability without removing one another accidentally.

capability_add

capability_remove

capability_clear

5. Read it in conditions

state

state_exists

capability

Use the condition inside an objective, sequence, menu, reaction or learning-agent observation.

Definition of done

The state uses the smallest correct scope.
Persistence is enabled only when the value should survive reload/rejoin.
Server-owned gameplay is not trusted to unsynchronized client-only state.
Actions can mutate the value and conditions can read it.