Files
feuerwerk/tools
adminandClaude Opus 5.5 1aa824ecb4
game-maker / gate (push) Successful in 2m37s
game-maker / suite (push) Successful in 13m2s
Keep objects through a Load scene with a switch (#165)
A Load scene destroyed every object of the old scene. A player, a HUD
or a music object had to be built again in each scene, with its state
pushed through shared variables. A top-level object with the new switch
Keep on scene load now travels into the next scene as the same entity,
with everything below it.

- The switch is a common property right under Enabled, off by default,
  on the asset and on a placed object. The inspector shows the row on
  top-level objects of a scene only, as answered in the issue.
- runtime/keptObjects.ts holds the rules as pure functions.
  keptEntities picks what travels, objectsToBring copies the stored
  objects as the run parents them, and bringObjects puts them into the
  next scene.
- World.instantiate takes a handed entity as it is instead of making
  one. The next syncToModel then writes the run's values into the
  scene.
- BehaviorSystem.release takes the running instances out before the
  old world is destroyed, and the next system adopts them. They hear
  no On destroy and no second On start, and their sounds play on.
- PhysicsSystem.resume gives a dynamic body the velocity and spin it
  had.
- Duplicates: the object brought along wins. The next scene does not
  build its own object with the same id, which is the way back into
  the scene the object came from.
- Decided here: the next scene does not build a top-level object of
  the same asset that is kept itself either. The issue only names the
  id. With the id alone a level that places its own player would hold
  two after a swap.
- Decided here: kept objects land behind the scene's own, the switch
  is no animation row, and collisions are found anew.

A finding, fixed along with it: Load scene did not build a scene as it
is stored, but as the run had left it. A moved object stayed moved and
a destroyed one stayed gone. The way back into a scene needs a clean
build.

- GameRun copies a scene's objects and groups before it first builds
  it and puts them back before it builds it again.
- GameRun.end puts every such scene back. The player calls it on stop,
  so spawned objects no longer stay for "Click to play again".
- The consequence: an edit made in a scene during Play is gone the
  next time that scene is loaded.

Tests:
- Gate: 199 files, 2944 tests (2929 + 15), exit 0
- e2e, full run: 1625 checks passed (1619 + 6), exit 0
- Smokes: 24 / 19 / 21, exit 0
- 15 unit tests in tests/core/keep-on-scene-load.test.ts
- Six e2e checks in module 35: the switch is set with a real mouse,
  the child has no row, the object is in the new scene, its counter
  still reads 1, its sound plays on, and the stored scenes are
  unchanged after Stop
- Eleven tests with fixed row lists only count the new schema row
- 16 unit counter-probes all fail tests, run on stein2. One did not
  fail at first (same id not left out), it has its own test now.
- The browser counter-probe fails 4 of the 6 new checks
- Not looked at in the browser: the switch as a port of the Properties
  node, and a released game with a kept object

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-01 17:30:16 +02:00
..
Plugins belong to the project, and they load before it: the project file gained the field plugins: ["demo-plugin.js"] (default empty, no formatVersion bump), the Plugins tab's switch writes into it as an ordinary undo step (SetPluginActiveCommand) instead of into a server-wide plugins.json, and the start order is turned around - startPlugins only fetches the list of files, then editor.boot() runs and ProjectStore.load(id, prepare) hands the raw JSON through before it is deserialized, where pluginsOf(raw) reads the list and PluginManager.syncTo() activates exactly those; that is the point of the issue, because what a plugin registers has to stand there before normalizeGraph would throw it away as unknown (#126, #127), a project switch first stops what the new project does not name and then starts what it does, a file the server does not have is passed over silently, and after signing out the manager is dead so a late event cannot start anything in a torn-down session; on the server plugins.json, PluginStore::setActive, isActive, the route PUT ?r=plugins/{file} and the 403 for inactive modules are gone and GET ?r=plugins only answers {file,bytes,updatedAt}, which makes every plugin file fetchable - the consequence accepted in #117, written down in the wiki for #115 and #116; publishPlugins(root) only copies files now, the seeder switches the demo plugin on in the fixture project, and the Plugins tab carries a puzzle piece as its icon while only a plugin's own tab still goes without one (the knob and the socket are cubic curves, not arcs, which Pixi's parser draws as a spike after an L); 3 new e2e checks in module 38 and 5 new unit tests cover the project as the owner of the switch, its undo, the order, pluginsOf against crude input and an unknown file name (#119)
2026-09-20 14:24:27 +02:00