3 Commits

Include renames

Author	SHA1	Message	Date
admin	7e5003b590	A test that waits for a deadline somebody guessed is waiting for the wrong thing, so it waits for the editor (#93) ... The suite spent 88% of its step time asleep: 564 s of steps, 496 s of them in sleep(n) - fixed spans estimated by hand and then copied from step to step. That is why it was slow, and why it flickered. The signal is afterFrames(count, timeout) in ui/render.ts, exposed as __gm.afterFrames(). It wakes the loop itself, because an editor that draws nothing would never redeem a promise of a frame, and it gives up after a timeout instead of hanging the run. settle() in the harness waits two drawn frames (~32 ms) instead of 150-300 ms and falls back to sleep(150) when the hook is missing (an old build): silently not waiting would make every later check a coin toss. Every action goes through it now - click, doubleClick, wheel, drag, dragAsset, press, typeText, select, mutate, undo, redo - and with that about 550 sleep() calls behind those actions became redundant, helpers that are nothing but a mutate in a coat included. What a frame cannot answer got its own condition instead: waitUntil(expr), play()/stop() waiting on __gm.state.mode rather than on 300 ms, saved() for the autosave (the two hand-written polling loops sampled at 300 ms for something that arrives after a second), and showTab() as a real tool - 47 places called evaluate("__gm.showTab(...)") raw, and 24 of them waited for nothing at all and read the old panel. 564 s -> 243 s of step time, the waiting share 88% -> 76%. Three kinds of wait were kept, and each one bit when it was taken away: loading bytes (textures, fonts), game time that a repaint cannot stand in for (time scale, shader and particle clocks, the live values a running graph carries), and the inertia the scroll step measures on purpose. Two things the new speed uncovered, both real: 25-animation read the frame menu unfiltered and had frozen an incomplete list (the CI failure on c990dbc), and 33-render-on-change measured idleness while the autosave of the step before was still painting - it waits for saveStatus to leave dirty/saving now, so it measures that nothing happens any more instead of that it waited long enough.	2026-09-16 08:08:10 +02:00
rootandClaude Opus 5	8143130ed2	A shared value belongs to no behavior, so it becomes an asset of its own (#91) ... This reverses the design of the previous commit. `PropertyDef.scope` is gone without replacement: a behavior variable is an object property again, without exception, and sharing is something you point at rather than something you declare twice. A **Variables asset** is declarations and nothing else -- no graph, no position, never placed, no tab of its own (`TAB_OF_ASSET` is already `Partial<>`, so that costs no line). A `Variables` node names one through its new `variablesAsset` setting, empty meaning the behavior's own variables as before, and then reads and writes one value per key for the whole run. Its property list follows the chosen source, which was the actual request: a value another graph declared is now offerable, where before every participant had to declare the name itself. That deletes more than it adds (-72 lines net): `globalConflicts` and its run-stopping kind clash, `SetVariableScopeCommand`, the scope picker, both object-inspector filters and the "shared by the whole run" note on the placed object. A typo is no longer a silent second variable -- naming an asset is picking from a list. And two Variables assets may carry the same key without meeting, because the asset is the key, not the name. The one shape it copies is the one that already existed: `Set state` picks its machine the same way. Lifetime is unchanged. The bag is built at `BehaviorSystem.start()` from the declarations and never written back, so playing in the editor cannot change the project -- which is the whole reason a counter must not be an object property (`World.syncToModel` would `commit()` it, and the coin counter would stand at 7 for good). Full symmetry across that gap, without mirroring anything. Two named wires: `Inspector.liveVariables` shows the values as they stand while a run is on and falls back to the declarations when it ends, and `adoptDeclarations()` takes a key into the run *only where the document changed it since the last sync*. Without that condition any unrelated project edit would snap a running counter back to its starting value; a counter-test bends exactly that and falls over. Nothing was ever cached, incidentally: `GraphInterpreter` only pulse-caches nodes without a `read`, and the variable node has one. The wire was missing. The state machine `Scope` row is now an ordinary `enum` row through `createFieldRow`. It was hand-built from an `HStack` with a ghost dropdown and began ~34px left of every value above it; the explanations beside `Local` and `Global` are gone from the menu, the sentence below the row keeps saying it. Machine scope is otherwise untouched -- `StateMachineAsset.scope`, `SetMachineScopeCommand`, `stateBag()` and its persistence all stand, so #59 stays closed as built and `Scope` as a type now carries machines alone. Six counter-proofs, each biting at its own guard. One of them did not bite at first: the suggestion list was computed twice, in `nodeSection` and `portSection`, so only the browser test covered the request itself. It is one named function now, `variableChoices`, with a unit test of its own. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-14 18:05:36 +02:00
rootandClaude Opus 5	d1fcfe8b81	A shared value belongs to the run, so a declaration carries its scope (#91) ... A variable or a state machine declared `global` keeps one value for the whole run instead of one per behavior instance. The scope sits on the declaration -- `PropertyDef.scope` and `StateMachineAsset.scope`, both optional, absence meaning `local` -- and `local` is never written, so every project made before this saves back unchanged. **The name is the key.** Two behaviors declaring a global `score` mean one variable; a behavior declaring `score` locally keeps its own. Kinds that disagree about one global name stop the run before it starts, with the two behaviors named; starting values that disagree are a warning on the behavior that declares it, and the first declaration wins (`globalConflicts`). The runtime needs no redirection layer. A global variable falls out of `schemaForObject`, so it never reaches `entity.props` -- and then the whole rule is "whoever declares the name takes their own value" (`graph/sharedState.ts`). The `Variables` node is untouched and stays transparent: switching a variable to global breaks no existing graph, because `GraphInterpreter.readAll` builds a fresh object per read anyway and only asks `port.key in all`. That same cut answers the inspector. A shared value has no owner, so the placed object shows no row for it and can hold no override -- `SetVariableScopeCommand` takes the deviations that were there and undo gives them back. Both places say it in words rather than leaving a glyph to be guessed: the declaration explains the mark below the list, and the placed object names the variable it no longer holds instead of claiming the behavior declares none -- which is what it said before, untruthfully. Screenshots of the e2e run turned that up; no check had been looking at it. `SharedState` hangs off `NodeContext`, is built in `BehaviorSystem.start()` from the *declarations* rather than from any instance (a global variable exists before its behavior is placed), and is thrown away with the run: nothing is written back, not even in the editor run. `GraphInterpreter.call` passes it on through `...ctx` while nested calls keep getting fresh local variables, which is why `program.defaults` is stripped of global keys. Two traps this hit. `defSignature`/`assetSignature` have to carry the scope or the inspector does not rebuild after the switch -- and a state machine has no rows at all, so its scope is appended to the signature by hand. And the object inspector does not go through `schemaForObject` for behaviors, it reads `asset.variables` directly; filtering in one place was not enough, and no unit test covered that path. The e2e caught it (`global: true` where false belonged), and the rule now lives in one named function, `objectRows`. Scopes `object` and `scene` are deliberately not built. The object case already has a route (`Object by name` -> `Properties`), and a run knows exactly one scene, so `scene` would be indistinguishable from `global` until #39 exists. Closes #59: a machine's scope is a word on the machine asset, not a setting per `Set state` node, so the same machine cannot live in two places at once. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-14 16:22:53 +02:00