BS-JD-401 - Static extension API v0 #27

New Issue

Rbanh · 2026-06-06T01:48:35-04:00

Rbanh commented

2026-06-06 01:48:35 -04:00

Summary

Formalize a stable, statically linked extension API before attempting dynamic loading.

Why

Blacksite already has editor plugin hooks; a deliberate static API gives future-game extensions a stable path without dylib complexity.

Implementation notes

Define v0 extension traits/capabilities for panels, commands, component metadata, inspectors, and tools.
Document ownership boundaries and non-goals.
Convert existing game/editor extension hooks to dogfood the API.
Keep API semver or migration notes explicit.

Acceptance criteria

External game/editor crates can register panels, commands, and inspector sections through one API.
Existing hooks are migrated or clearly bridged.
API docs include examples and constraints.
Dynamic loading remains out of scope for v0.

Tests/docs

Compile-time example crate or fixture. Update ADR/docs/editor architecture.

## Summary Formalize a stable, statically linked extension API before attempting dynamic loading. ## Why Blacksite already has editor plugin hooks; a deliberate static API gives future-game extensions a stable path without dylib complexity. ## Implementation notes - Define v0 extension traits/capabilities for panels, commands, component metadata, inspectors, and tools. - Document ownership boundaries and non-goals. - Convert existing game/editor extension hooks to dogfood the API. - Keep API semver or migration notes explicit. ## Acceptance criteria - [ ] External game/editor crates can register panels, commands, and inspector sections through one API. - [ ] Existing hooks are migrated or clearly bridged. - [ ] API docs include examples and constraints. - [ ] Dynamic loading remains out of scope for v0. ## Tests/docs Compile-time example crate or fixture. Update ADR/docs/editor architecture.

Rbanh added this to the M4 - Extensibility and runtime integration milestone 2026-06-06 01:48:35 -04:00

Rbanh added the

labels 2026-06-06 01:48:35 -04:00

Rbanh referenced this issue

2026-06-06 01:49:27 -04:00

BS-JD-ROADMAP - Jackdaw-inspired editor production roadmap #1

~~Rbanh referenced this issue 2026-07-11 18:49:46 -04:00~~

BS-JD-207 — Renderer material slots, material instances, and exact custom shader surfaces #51

Rbanh referenced this issue

2026-07-11 18:50:23 -04:00

BS-JD-ROADMAP - Jackdaw-inspired editor production roadmap #1

Rbanh commented

2026-07-11 18:50:27 -04:00

Expanded component lifecycle foundation

The v0 static extension API must register real authoring-component lifecycle behavior, not metadata/inspector labels alone. The foundation should provide:

A stable component ID plus reflected Rust/wire type.
Persistence/save-filter policy, enable policy, validation, reference collection, and prefab policy.
Required/recommended/conflicting component relationships and atomic add/remove/replace transactions.
Default factory, inspector UI metadata, copy/paste/reset, multi-selection, and generic history deltas.
One shared enabled-state helper consumed by hydration/runtime systems.
Registry completeness checks for duplicate IDs/types, unknown dependencies, and missing editor registrations.
ActorKind as a derived compatibility/presentation hint; component requirements/conflicts define validity and permit useful composition such as renderer + light.
A game-side fixture proving an external statically linked component can round-trip without new editor-core match arms.

#51 is the first major consumer: static/skinned renderers and their material bindings must participate through this lifecycle. Dynamic-library loading remains out of scope for v0.

### Expanded component lifecycle foundation The v0 static extension API must register real authoring-component lifecycle behavior, not metadata/inspector labels alone. The foundation should provide: - A stable component ID plus reflected Rust/wire type. - Persistence/save-filter policy, enable policy, validation, reference collection, and prefab policy. - Required/recommended/conflicting component relationships and atomic add/remove/replace transactions. - Default factory, inspector UI metadata, copy/paste/reset, multi-selection, and generic history deltas. - One shared enabled-state helper consumed by hydration/runtime systems. - Registry completeness checks for duplicate IDs/types, unknown dependencies, and missing editor registrations. - `ActorKind` as a derived compatibility/presentation hint; component requirements/conflicts define validity and permit useful composition such as renderer + light. - A game-side fixture proving an external statically linked component can round-trip without new editor-core match arms. #51 is the first major consumer: static/skinned renderers and their material bindings must participate through this lifecycle. Dynamic-library loading remains out of scope for v0.

Rbanh commented

2026-07-12 00:12:35 -04:00

Registry-driven component lifecycle implemented locally

The component foundation requested in the expanded scope is now dogfooded by static/skinned renderers and material bindings:

stable IDs and reflected type registration;
persistence policy, validation, reference collection, requirements/conflicts, and independent active state;
atomic add/remove/reset/copy/paste/history transactions;
generic registered-extension round-trip and scene persistence coverage;
ActorKind reduced to a derived compatibility/presentation hint;
verified renderer + light composition on one actor.

The live composition screenshot path, ADR 0034, extensibility guide, and test matrix are recorded in #51 comment 865. This remains a local unpublished implementation; #27 stays open for its broader panel/command/tool API publication gate.

### Registry-driven component lifecycle implemented locally The component foundation requested in the expanded scope is now dogfooded by static/skinned renderers and material bindings: - stable IDs and reflected type registration; - persistence policy, validation, reference collection, requirements/conflicts, and independent active state; - atomic add/remove/reset/copy/paste/history transactions; - generic registered-extension round-trip and scene persistence coverage; - `ActorKind` reduced to a derived compatibility/presentation hint; - verified renderer + light composition on one actor. The live composition screenshot path, ADR 0034, extensibility guide, and test matrix are recorded in [#51 comment 865](https://git.spacetrainclubhouse.com/Falling-Metal-Interactive/Blacksite/issues/51#issuecomment-865). This remains a local unpublished implementation; #27 stays open for its broader panel/command/tool API publication gate.

Rbanh referenced this issue

2026-07-12 00:12:36 -04:00

BS-JD-ROADMAP - Jackdaw-inspired editor production roadmap #1

Sign in to join this conversation.