Runtime Dispatch & Entity AI Scopes
DAI 3.0 makes several native runtime systems directly callable from normal action JSON and makes the entity behavior vocabulary explicit so Creator tooling can stop mixing two different execution scopes.
First-class native dispatch
| Capability | Direct action | Explicit server alias |
|---|---|---|
| Projectile | projectile_spawn | server_projectile_spawn |
| Particle | particle_emit | server_particle_emit |
| Apply effect | effect_apply | server_effect_apply |
| Remove effect | effect_remove | server_effect_remove |
| Apply potion | potion_apply | server_potion_apply |
The paired names route to the same server-owned runtimes. Use the shorter direct names for normal authored content; the server_* names are useful when you want the authority boundary to be obvious in JSON.
Why entity AI is separate
Entity behavior JSON is executed by the native server entity runtime, not the general client action resolver. It has its own verbs such as move_to, follow_player, chase_target, melee_attack, wander and flee_player.
Condition scope
General conditions use one captured DAI_ConditionContext per group, registry providers return typed values, operators compare centrally, then negation is applied. Entity behavior predicates instead read server entity state such as health, target distance, line of sight, water/on-ground state and random chance.
capture context once → read provider value → compare boolean / number / string → apply negate
Use the right surface
Objective / menu / reaction / ability
Use the general ActionRegistry + ConditionRegistry.
Native entity AI sequence
Use the entity behavior action/predicate vocabulary inside the entity runtime definition.
Projectile / particle / effect / potion trigger
Use the new 3.0 dispatch actions; no behavior-only alias is required.
Unknown future JSON
The Creator continues preserving unknown fields/files so forward-compatible content is not deleted.