You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Scripted spell-effect kind dispatches to Tier-2 scripts (the new-ability hatch) #100
Spec: the packages-devx design, §Runtime scripts — the ability hatch (public proposal: #1; the full design doc lives in the private working origin). Builds on the spell system's kind-taxonomy handler registry and its Scripted escape hatch.
Bind the Scripted spell-effect kind to Tier-2 scripts: an effect row names a script; casting dispatches to it through the host API. This makes "a new ability the vanilla engine can't express" = data rows (datascripts, #98) + one script — a first-class contract, instead of scripters reverse-engineering notify hooks to fake an effect. It also sidesteps most of the mutating-hooks question for abilities: the script IS the effect, not a decorator on one.
Done when: a custom spell defined purely as package content — spell/effect rows via a datascript, behavior via a runtime script — is learnable, castable, and produces its scripted effect, verified server-side through the headless wire harness with no per-spell engine code added.
Migrated 2026-08-11 from the private tracker (spacetime-core#512).
Current behavior: E_SCRIPTED effects with script_id = 0 are intentional no-ops. The effect table already carries script_id, but cast resolution has no Runtime Script dispatch.
Desired behavior:
Keep script_id = 0 as the vanilla graceful no-op. Before spending a resource or starting cooldown, a cast containing a nonzero Scripted effect verifies that the named Runtime Script exists and is enabled. Missing or disabled scripts refuse the cast.
During effect resolution, invoke the Runtime Script as the effect itself with caster, target, spell, effect, and computed effect data. Successful staged host operations commit. A runtime or fuel failure discards that effect's staged operations and records the failure, while core processing and other effects continue.
Key interfaces:
E_SCRIPTED spell-effect handler
SpellEffect.script_id
Runtime Script lookup and invocation
Cast preflight Gate
Acceptance criteria:
script_id = 0 keeps the existing no-op behavior.
A missing or disabled nonzero script refuses before resource cost and cooldown.
An enabled script receives the correct caster, target, spell, and effect identity.
Successful host operations become the spell effect.
Runtime and fuel failures commit no staged operations and do not stop later core work.
A Package-defined spell and Runtime Script are learnable and castable through the headless wire test with no per-spell Rust handler.
Out of scope:
Decorating or vetoing other spell kinds
Raw script uploads
New host operations beyond the Runtime Script API tickets
Activity
Mathih13 commentedon Aug 24, 2026
Agent Brief
Category: enhancement
Summary: Dispatch nonzero Scripted spell effects to Package Runtime Scripts.
Current behavior:
E_SCRIPTEDeffects withscript_id = 0are intentional no-ops. The effect table already carriesscript_id, but cast resolution has no Runtime Script dispatch.Desired behavior:
Keep
script_id = 0as the vanilla graceful no-op. Before spending a resource or starting cooldown, a cast containing a nonzero Scripted effect verifies that the named Runtime Script exists and is enabled. Missing or disabled scripts refuse the cast.During effect resolution, invoke the Runtime Script as the effect itself with caster, target, spell, effect, and computed effect data. Successful staged host operations commit. A runtime or fuel failure discards that effect's staged operations and records the failure, while core processing and other effects continue.
Key interfaces:
E_SCRIPTEDspell-effect handlerSpellEffect.script_idAcceptance criteria:
script_id = 0keeps the existing no-op behavior.Out of scope: