No-Commander / no-order fallback behaviour #7

New issue

Open

opened 2026-11-15 01:10:02 +00:00 by muse-lantern · 0 comments

muse-lantern commented

2026-11-15 01:10:02 +00:00

Member

The plan

An NPCEntity can exist without a Commander, and an order can go stale. Both cases need a defined behaviour, or NPCs freeze in ways that look broken. The fallback must be safe and must stay inside the brain's job: it is an execution-level default, not a decision. The brain still never decides WHAT to do — the fallback is what "nothing to do" executes as.

Current state

Nothing. addons/daisy/src/npc_entity.gd has no fallback: an NPC with no Commander simply never receives orders, and an NPC whose order goes stale keeps its last order_state — executing forever if it never completes, done with no next step. The design doc lists this as an open question ("hold position, patrol, keep the last order?") and the smoke test only ever drives NPCs that have a Commander.

What changes

Settle and implement the fallback, in order:

No-Commander behaviour. Decide what an unassigned NPC does. Candidates: hold position, patrol a default route, keep doing whatever it was doing, wander. The answer may differ by NPC type — a fox roams, a gunner holds — but if it differs, the difference is a per-type parameter, not a second brain.
Stale orders. Decide what makes an order stale — a timeout, the target ceasing to exist, the Commander going away — and what the brain does then: keep the last order, revert to hold, or revert to the no-Commander behaviour. An order the brain cannot complete must end in stuck (and a Commander re-plan) or in the fallback, never in silent executing forever.
Rejoining. If an NPC with no Commander is later assigned one, the assignment must cleanly replace the fallback — the Commander takes over from whatever the NPC is doing, with no leftover state fighting it.
Implement in npc_entity.gd. A fallback state and stale-order detection on the brain. Keep it small: the fallback is a behaviour, not a Commander in miniature.
Tests. An unassigned NPC does the settled fallback behaviour; an order made stale reverts per the settled rule; a Commander assigned mid-fallback takes over cleanly; no NPC ever sits in executing forever.

What done looks like

The fallback rules are written in the design doc, implemented on the brain, and proven by tests — including the negative test that an NPC never stalls in executing forever. The smoke test's world still passes unchanged.

Open questions

Hold, patrol, or keep the last order — and does the answer differ by NPC type?
What counts as stale — timeout, target gone, Commander gone, or all three?
Does a Commander-less NPC ever seek out a Commander, or does it wait to be assigned?
Should the fallback itself be interruptible by perception — an unassigned NPC that sees the player does what?

## The plan An NPCEntity can exist without a Commander, and an order can go stale. Both cases need a defined behaviour, or NPCs freeze in ways that look broken. The fallback must be safe and must stay inside the brain's job: it is an execution-level default, not a decision. The brain still never decides WHAT to do — the fallback is what "nothing to do" executes as. ## Current state Nothing. `addons/daisy/src/npc_entity.gd` has no fallback: an NPC with no Commander simply never receives orders, and an NPC whose order goes stale keeps its last `order_state` — `executing` forever if it never completes, `done` with no next step. The design doc lists this as an open question ("hold position, patrol, keep the last order?") and the smoke test only ever drives NPCs that have a Commander. ## What changes Settle and implement the fallback, in order: 1. **No-Commander behaviour.** Decide what an unassigned NPC does. Candidates: hold position, patrol a default route, keep doing whatever it was doing, wander. The answer may differ by NPC type — a fox roams, a gunner holds — but if it differs, the difference is a per-type parameter, not a second brain. 2. **Stale orders.** Decide what makes an order stale — a timeout, the target ceasing to exist, the Commander going away — and what the brain does then: keep the last order, revert to hold, or revert to the no-Commander behaviour. An order the brain cannot complete must end in `stuck` (and a Commander re-plan) or in the fallback, never in silent `executing` forever. 3. **Rejoining.** If an NPC with no Commander is later assigned one, the assignment must cleanly replace the fallback — the Commander takes over from whatever the NPC is doing, with no leftover state fighting it. 4. **Implement in `npc_entity.gd`.** A fallback state and stale-order detection on the brain. Keep it small: the fallback is a behaviour, not a Commander in miniature. 5. **Tests.** An unassigned NPC does the settled fallback behaviour; an order made stale reverts per the settled rule; a Commander assigned mid-fallback takes over cleanly; no NPC ever sits in `executing` forever. ## What done looks like The fallback rules are written in the design doc, implemented on the brain, and proven by tests — including the negative test that an NPC never stalls in `executing` forever. The smoke test's world still passes unchanged. ## Open questions - Hold, patrol, or keep the last order — and does the answer differ by NPC type? - What counts as stale — timeout, target gone, Commander gone, or all three? - Does a Commander-less NPC ever seek out a Commander, or does it wait to be assigned? - Should the fallback itself be interruptible by perception — an unassigned NPC that sees the player does what?

muse-lantern referenced this issue

2026-11-15 01:10:25 +00:00

Build sequence: code first, then model integration #11

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

dead-air/daisy#7

No description provided.

Rows
Columns