fix(dashboard): refine Galaxy layout and physics response - #205
fix(dashboard): refine Galaxy layout and physics response#205Coding-Dev-Tools wants to merge 3 commits into
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 544aaa6616
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| .forEach(key => { | ||
| const target = Number(item.carrier[key]); | ||
| if (Number.isFinite(target) && target > 0) { | ||
| item.carrier[key] = target * ratio; |
There was a problem hiding this comment.
Scale each carrier lane cache only once
When a gravity or central-field slider changes after carrier lanes have been established, item.nodes already contains item.carrier, so the loop above scales the carrier's __galaxy*Lane*Radius fields once and this second loop scales the same fields again. The carrier position moves by ratio, but its authoritative cached lane becomes ratio²; on the next physics slice, carrier support projects the whole system onto that incorrect radius, causing an extra jump and breaking the intended path-independent response. Remove the duplicate carrier scaling or exclude the carrier from the first cache update.
Useful? React with 👍 / 👎.
| { id: 'graph-repel', key: 'repel', fallback: 100 }, | ||
| { id: 'graph-link', key: 'link', fallback: 8 }, | ||
| { id: 'graph-gravity', key: 'gravity', fallback: 96 }, | ||
| { id: 'graph-gravity', key: 'gravity', fallback: 120 }, |
There was a problem hiding this comment.
Migrate the retired Galaxy gravity default
For an existing user whose saved graph preferences contain the former default tuning.gravity: 96 and physicsVersion: 4, restoration spreads that saved value over this new preset, so the new 120 default never takes effect. Preference snapshots persist every tuning value even if the user only changed an unrelated graph option, making this affect users who never customized gravity. Bump the physics version and narrowly migrate the exact retired Galaxy default, as the existing 48/60 orbital-speed migration does.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6c231747ea
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ['orbit_radius', '__galaxyOrbitBaseRadius'].forEach(key => { | ||
| const val = Number(node[key]); | ||
| if (Number.isFinite(val) && val > 0) { | ||
| node[key] = val * localRatio; | ||
| } |
There was a problem hiding this comment.
Update the active kinematic orbit cache
When Galaxy is collapsed or exceeds the live-solver limit, satellites already carry a __galaxyKinematicLocalOrbit.baseRadius; this loop scales only orbit_radius and __galaxyOrbitBaseRadius. On the next kinematic frame, advanceGalaxyKinematicLocalMembers() reads the unchanged active cache and restores the old radius, so the new local-gravity feedback immediately snaps back in precisely the large/collapsed views that use the fallback. Scale or invalidate the kinematic cache as part of this response.
Useful? React with 👍 / 👎.
| const localGChanged = (next.localGravitationalConstant !== undefined || next.G_star !== undefined) | ||
| && Number.isFinite(previousLocalG) && Number.isFinite(nextLocalG) | ||
| && previousLocalG > 0 && nextLocalG > 0 | ||
| && Math.abs(nextLocalG - previousLocalG) > 1e-12 |
There was a problem hiding this comment.
Handle zero in the local-gravity response
When the valid Local solar gravity slider reaches 0 or moves away from 0, these positivity checks suppress the immediate radius response entirely. This also makes the response path-dependent: 2 → 1 expands satellites, while 2 → 0 → 1 leaves them unchanged because both transitions are rejected. Use a bounded endpoint mapping so zero participates without producing an infinite ratio.
Useful? React with 👍 / 👎.
| cachedPhysicsSnapshot = snapshot; | ||
| cachedPhysicsSnapshotStep = galaxySteps; | ||
| return snapshot; |
There was a problem hiding this comment.
Populate the physics snapshot cache before returning
These cache assignments are unreachable because the object literal is returned at line 10691, and snapshot is never defined. Consequently the cache-hit branch can never run, so while the spacetime overlay is active every animation frame still rebuilds community groups and allocates a full node snapshot—an avoidable O(n) cost on large graph views. Build a snapshot value, cache it, and then return it.
Useful? React with 👍 / 👎.
Summary\n- distribute Galaxy systems across concentric tiers to reduce outer-ring crowding\n- refine orbital gravity/radius response and immediate local-gravity feedback\n- synchronize dashboard defaults and regression coverage\n\n## Validation\n- python -m pytest tests/test_graph_engine_asset.py tests/test_ledger_sliders_and_physics.py -q\n- ruff check engraphis/core/graph_scene.py tests/test_graph_engine_asset.py tests/test_ledger_sliders_and_physics.py\n- git diff --check