Skip to content

Scripted spell-effect kind dispatches to Tier-2 scripts (the new-ability hatch) #100

Closed

Description

@Mathih13

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.

Blocked by #99

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).

Activity

  1. Mathih13 commented on Aug 24, 2026

    @Mathih13
    ContributorAuthor

    This was generated by AI during triage.

    Agent Brief

    Category: enhancement
    Summary: Dispatch nonzero Scripted spell effects to Package Runtime Scripts.

    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
  2. added
    ready-for-agentComplete enough to build from the issue alone, by a person or their agent
    on Aug 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3someday / nice-to-haveenhancementNew feature or requestready-for-agentComplete enough to build from the issue alone, by a person or their agent

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions