Page 3 · Objectives, Sequences & Flow

Turn Actions Into Behavior

Objectives give behavior a name. Sequences define order. The action queue, barriers, results, and flow actions determine what executes next and how a behavior recovers.

Objectives = BehaviorsReusable named action definitions.

Sequences = OrderMultiple child actions resolved in sequence.

Flow = ContinuationBranch, retry, stop, delay, or call another objective.

What Is an Objective?

An objective is a named DAI action definition stored in your datapack.

Typical path

data/my_dai_pack/objectives/definitions/harvest_wood.json

data/my_dai_pack/objectives/definitions/harvest_wood.json
                         ↓
                my_dai_pack:harvest_wood

Keep objectives focused. Small behaviors are easier to test, reuse, replace, and recover.

Sequences

sequence recursively expands child actions in order before the atomic actions execute.

Sequence

{
  "type": "sequence",
  "sequence": [
    {
      "type": "move",
      "direction": "forward",
      "ticks": 20
    },
    {
      "type": "input_stop_all"
    },
    {
      "type": "delay",
      "ticks": 10
    }
  ]
}

JSON Sequence
   ↓
DAI Action Resolver
   ↓
Atomic Action 1
Atomic Action 2
Atomic Action 3
   ↓
Action Queue

The Runtime Queue

The current queue is bounded and starts at most one new semantic action per client tick. Active controllers such as navigation or mining can continue updating independently while the queue governs new semantic starts.

Objective
   ↓
Resolver
   ↓
Action Queue
   ├── Action 1
   ├── Action 2
   ├── Action 3
   └── Action 4
          ↓
       Runtime

`queue_clear`

Clear queued work

{
  "type": "queue_clear"
}

Calling Other Objectives

enqueue_action queues another namespaced action/objective as a deferred reference. It expands when it reaches the front of the queue.

Call another objective

{
  "type": "enqueue_action",
  "action": "my_dai_pack:harvest_wood"
}

This is a primary modularity tool. High-level behavior can hand control to small reusable objectives instead of pre-expanding enormous queues.

Delays & Barriers

Delay 20 ticks

{
  "type": "delay",
  "ticks": 20
}

Asynchronous systems often have matching wait actions such as wait_for_approach, wait_for_exploration, wait_for_container, and wait_for_creative_flight.

start asynchronous operation
   ↓
wait_for_...
   ↓
hard queue barrier
   ↓
controller finishes
   ↓
barrier releases
   ↓
next queued action

Action Results

SUCCESS

The operation completed successfully.

FAILURE

The operation failed normally.

TIMED_OUT

The operation exceeded its runtime budget.

CANCELLED

The operation was cancelled/interrupted.

RUNNING

The current operation is still active.

The preceding semantic action's result is committed immediately before the next queued semantic action evaluates its runtime conditions.

Flow Actions

Action	Meaning
`run_if_success`	Prepends the referenced objective when the previous result is SUCCESS.
`run_if_failure`	Prepends the referenced objective for FAILURE, TIMED_OUT, or CANCELLED.
`stop_if_success`	Clears remaining queued work after SUCCESS.
`stop_if_failure`	Clears remaining queued work after FAILURE, TIMED_OUT, or CANCELLED.
`random_action`	Chooses one child from `sequence` and prepends the resolved branch.

Failure recovery

{
  "type": "run_if_failure",
  "action": "my_dai_pack:recover"
}

Runtime Conditions and Skipped Actions

If an atomic queued action's runtime conditions fail, its body is skipped and the current action result becomes FAILURE. A following failure branch can intentionally react to that result.

queued action
   ↓
conditions fail
   ↓
action body skipped
   ↓
result = FAILURE
   ↓
following flow may recover

Rotors & Repeating Behavior

Objectives can hand control back and forth through deferred references so each iteration observes fresh world state.

detect_wood
   ↓
harvest_wood
   ↓
detect_wood_adjacent
   ↓
harvest_wood
   ↓
...

Prefer controlled rotors over huge pre-expanded loops. Each iteration gets a new opportunity to react to player, target, inventory, and world state.

Fallback Chains

Try preferred behavior
   ↓ failure
Try nearby alternative
   ↓ failure
Explore for a new target
   ↓ failure
Recover / reposition
   ↓
Retry

Reliable gameplay is usually a network of small attempts and fallbacks rather than one brittle perfect sequence.