# Known Limitations | Limitation | Details | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Single-agent coordination** | There is no built-in shared blackboard or squad goal system for coordinating multiple agents. | | **Plan performance cost** | `AIBehavior.CurrentPlan` is a read-only snapshot of the remaining action queue, but it is rebuilt from the internal `Queue` on every access. Do not call it in hot-path code; use it for editor tooling and debug displays only. | | **All-or-nothing re-planning** | When re-planning, the entire action sequence is discarded and re-searched from scratch. There is no incremental re-planning that reuses unchanged tail segments. | *** ## Resolved Since v1.0 / v1.3 The following were limitations in earlier versions and are now resolved: * ~~**Static action costs**~~ — Dynamic costs via `ComputeCost()` / `SetDynamicCost()` are now supported. * ~~**No resource locking**~~ — Binders are locked automatically in `ResolveTarget()` and released automatically on completion, interrupt, or reset. Shared targets opt out of locking via `IsShared`. * ~~**All-or-nothing re-planning (relevance)**~~ — Relevance-based filtering via `_relevantKeys` prevents re-plans from triggering on unrelated state changes. * ~~**Synchronous-only planning**~~ — `StepPlanAsync()` dispatches the A\* loop to a background thread. The main thread is only blocked by `BeginPlan()` (state snapshot) and Phase 3 (result consumption), both O(n) in action/key count. * ~~**No sensor system**~~ — `RangeSensor` and `LineOfSightSensor` components poll the environment at configurable intervals and write directly into `State`, triggering reactive re-planning automatically. (v1.2) * ~~**One subclass per action variant**~~ — Parametric Actions (`List _parameters` + `GetParameter()`) let a single class serve multiple roles configured from the Inspector. (v1.3) * ~~**Unconditional effects only**~~ — Conditional Effects (`List _conditions` with `And`/`Or` logic) are now evaluated in both the A\* simulation and at runtime. (v1.3) * ~~**No ordering guarantees between actions**~~ — Plan Ordering DSL (`"A[After]B"` / `"A[Before]B"` in action name, with optional `(S)(T)` seed/trigger values) injects implicit state keys to enforce ordering without planner changes. (v1.3) * ~~**Fixed A\* scoring**~~ — `GoalEvaluator` allows a custom scoring function to bias the planner toward urgency, distance, or any game-specific metric. (v1.3) * ~~**No way to disable an action without removing it**~~ — `IsIncludeOnPlanning` flag excludes an action from planning while keeping it in the Inspector list. Shown grayed-out in the GOAP Graph Editor. (v1.3) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://beelabs-dev.gitbook.io/beelabs-docs/goap-engine/known-limitations.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.