Steam Controller float layout: spacing fix, defaults & Edit Layout editor (#75)

[petegordon]

Fixes #75.

Summary

Started as the #75 float-spacing fix and grew into a broader pass on the Steam Controller float/popout layout and its Edit Layout editor:

• Fix the overlapping bumpers/triggers and half-hidden paddles (Detached buttons are too close together #75).
• Bake the hand-tuned trigger/bumper positions in as the defaults.
• Make the per-part numeric editor actually usable (a floating popup) and default the camera to Top.
• Make Reset to all defaults actually reset everything (including window size).

1. Float spacing fix (#75)

These parts are positioned by per-part floatTuning (floatFactor/floatLateralBias only apply to untuned parts, so the tuning is the only lever). Adjusted the Steam Controller profile:

Part	Before	After	Why
Triggers	back 0.22, up 0.24	back 0.34, up 0.36	Reopen the gap so triggers sit clearly above the bumpers instead of on top of them
Paddles	up -0.14, back -0.45	up -0.06, back -0.58	Raise them and pull them toward the camera so they clear the body's bottom edge instead of hiding behind it

Bumpers (back 0.08, up 0.12) and the paddle side (-0.13) are unchanged.

2. Hand-tuned defaults

• New defaultLayout on the Steam Controller profile holds the exact trigger/bumper offsets captured from the Edit Layout editor, applied as a baseline on top of floatTuning (a user's own saved edits still win).
• Camera now defaults to Top for every controller (was Player); still persisted per Save last Camera position selected and reopen to it #70, so a user's pick is remembered.

3. Edit Layout — floating numeric editor

The per-axis Position/Rotation fields lived inside the settings panel, which is closed while you drag parts in the 3D view — so the fine-tune controls were effectively invisible. Moved them into a self-contained popup shown when a part is selected:

• Draggable popup with X / Y / Z axis labels and roomy, readable fields.
• Shift + ↑/↓ = fine nudge (Position 0.001, Rotation 0.1°); plain ↑/↓ keep the coarse step.
• Close (×) deselects; Reset this part restores the position editing started from — the baked defaultLayout if the part has one, else the computed floatTuning spot — instead of jumping to a different procedural value.

4. Full "Reset to all defaults"

Window size lives in the Electron main process (window-state.json), not localStorage, so it survived a reset. Added a reset-window-size IPC that drops the persisted size and snaps the window to the mode default (720×540 single / 1100×520 multi); the reset handler awaits it before reloading.

Files

• packages/visualizer/src/controller-profiles.js — float tuning + defaultLayout
• packages/visualizer/src/controller-overlay.js — apply defaultLayout, numeric get/set, reset-to-default, clearLayoutSelection
• apps/overlay/src/index.html + src/js/app.js — popup UI + wiring, Top camera default, reset-window-size call
• apps/overlay/electron/main.js + preload.js — reset-window-size IPC

Testing

• All 85 core tests + visualizer unit tests pass; node --check clean on every changed JS file.
• CI only covers packages/core + visualizer; the overlay UI (popup, window reset) is Electron-only, so verify on the desktop preview build:
  • Steam Controller + Float Controls: bumper/trigger gap and paddle visibility (Top & Player views).
  • Edit Layout → select a trigger → popup appears with X/Y/Z + Shift-fine; drag/edit works; Reset this part returns it to the default.
  • Top is the default camera on a fresh profile.
  • Resize the window, then Reset to all defaults → window returns to default size.

🤖 Generated with Claude Code

[github-actions]

🔎 PR #79 preview — torn down

This PR is closed; its web preview and desktop prerelease have been removed.

[Ivanim13]

The problem persists. I believe this is a problem best solved without AI, since the overlay already has a way of moving the position of floating buttons. Making manual adjustments and setting those as the new default would be ideal. As of now, changing the position of the floating buttons is difficult because the first time you click on the button you want to move, its orientation is reset, instead of maintaining the original, already intended, orientation. The method of moving the buttons is also not precise enough; it's impossible to change precise positional values that would allow for a more symmetrical layout.

[petegordon]

Let’s see if we can extend this PR to start the edit layout control selection from the Chevy position and not reorientation when clicked and add a floating panel when clicked to do numeric values adjusted precisely in addition to the Q/E and arrow keys.

[petegordon]

Pushed the editor-UX improvements to this PR:

1. Selecting a part no longer resets its orientation. The override used to seed euler {0,0,0}, throwing away the part's intended tilt (triggers/bumpers) or camera-facing pose (paddles) on first click. It's now seeded from the part's current popped orientation, so the first drag/edit is visually a no-op. Just selecting a part is non-destructive now (no override is committed until you actually move/rotate/type).

2. Precise numeric position + rotation. When a part is selected, the Edit Layout panel now shows X/Y/Z position and pitch/yaw/roll (°) fields alongside the existing drag + Q/E/arrow controls. They update live as you drag/nudge, and apply per-axis. For a symmetric layout, give the left/right parts matching values with X negated (e.g. −0.30 ↔ +0.30).

Best tested on the refreshed preview once this run finishes: https://lab.usersfirst.games/pr-preview/pr-79/overlay/ → Settings → Edit float layout, then click a part.

The float-default tweak from the first commit is still here too, but with the numeric editor you can now dial in exact defaults — happy to bake whatever values you settle on into the profile as the new defaults.

---

Generated by Claude Code

[petegordon]

I think I found a good default trigger/bumper positioning. What do you think?

The ability for the user to edit the layout is still a work in progress and a bit difficult with the fine control--I'm going to test it a bit more and see how it behaves (I used it to find the ideal default positioning--so it's pretty good just not great)

[petegordon]

Hope the defaults are good. The user defined positioning (relative or absolute) is still a bit tricky--can always restore to defaults--and now can do smaller incremental changes to rotation with the shift key down.