fix(ui): OP8 rework — activation/scope preservation, camera-row de-alias, conflict-confirm dialog

Fixes the three MUST-FIX findings from the 2026-08-11 combined dual-lens
review of commit b4edee97 (docs/research/2026-08-11-op8-review.md).

M1 — SetForAction destroyed ActivationType/InputScope on every write,
collapsing walk-mode's Hold, the three combat-scoped bindings, and
CameraInstantMouseLook's mouse chord the instant a row (including
Defaults, which touches all ~140 mapped rows at once) wrote back.
Widened the Bindings seam to carry the full Binding (chord + activation
+ scope), not a bare chord: KeyboardConfigController captures each
row's live Activation/Scope ONCE at build time (every multi-chord
action in KeyBindings.RetailDefaults() shares one pair across all its
bindings) and reapplies it on every write — rebind, Cancel/Revert, and
Defaults (which restores DAT-sourced KEYS only, never touches the
pair). New tests pin this across both Defaults and Cancel for a
Hold+MeleeCombat-scoped action.

M2 — InputMap 0x5 (CameraControls) and 0x6 (CameraAlternateControls)
aliased one InputAction each: both rows read/wrote the same live target,
so they showed identical stale chords, a rebind of one silently wiped
the other, and a row could conflict with its own twin. Building real
per-scheme dual-binding storage (or new InputAction members plus the
camera-dispatch code to consume them) is a feature, not a one-line fix.
Chose the third option: only ctx 0x5 — the scheme RetailDefaults()
actually has live support for — maps to InputAction; ctx 0x6 falls
through to the existing unmapped/store-only path (AP-203), fully
rendered, bindable, and persisted, honestly carrying no live effect.
This also retired 10 stale allowlist entries in the DAT-vs-
RetailDefaults() round-trip test: with the alias gone, ctx 0x5 alone
matches RetailDefaults() exactly for all twelve Camera actions.

M3 — the auto-reassign-on-conflict path was wired silent in production
(NotifyReassigned: _ => "") though the contract asked for a prompt and
retail confirms before overwriting (OpenOverwriteBindingDialog). Wired
a real confirm dialog through RetailDialogFactory.MakeConfirmation —
the same seam GameplayConfirmationController already uses — read
lazily since DialogFactory mounts after MountKeyboardConfig in
Initialize()'s order. Only reassigns on accept; decline leaves every
row untouched. AP-204 (which recorded the narrowing) is RETIRED; the
still-true OK/Cancel left-click-vs-right-click-release note moves to a
code comment (zero observable difference, doesn't warrant a register
row). Reverted the gate script's step 9 from documenting the silent
shape back to the real confirm-prompt behavior.

SHOULD-FIX addressed as one-liners in files already touched:
- S1: non-user-bindable conflicts are now checked BEFORE any row
  conflict (retail's own order), and ALL conflicting rows are collected
  (N-way), not just the first match.
- S3: Save wraps the file-write pair in the same try/catch
  RuntimeKeyBindingTarget.Apply already uses for keybinds.json.
- S4: assigning "Mapping 3" on a row with no existing bindings now
  lands on display index 2, not index 0 — ReplaceSlotValue trims only
  TRAILING empty slots instead of stripping every default(KeyChord).
  Right-click on an already-empty slot is now a no-op instead of
  shifting later bindings.
- S6: UiButton.OnRightClick returns false (unhandled, bubbles to
  parent) when no handler is set, disabled or not — matching the
  pre-existing behavior the class doc already claimed.

Left for a future pass (not one-liners): S2 (ActionMap.ConflictingMaps
is still unread — the conflict scan treats all 306 rows as one flat
universe instead of respecting the DAT's own legitimately-shared-key
table) and S5 (the ~330 DAT layout imports still run eagerly at mount
instead of lazily on first open).

19 KeyboardConfigControllerTests (was 12): +2 activation/scope
preservation (Defaults, Cancel), +1 camera de-alias, +2 confirm-dialog
accept/decline, +1 non-bindable-takes-priority-over-row-conflict, +1
sparse-row third-slot placement. Full solution suite 13,154 passed / 4
skipped / 0 failed (this round's baseline 13,147/4/0, zero regressions).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-11 09:53:10 +02:00
parent b4edee970f
commit b1968ce980
8 changed files with 521 additions and 163 deletions

View file

@ -49,9 +49,11 @@ namespace AcDream.UI.Abstractions.Input;
/// <see cref="InputAction"/>'s <c>UseQuickSlot_*</c> family jumps from 9 straight to
/// 14, a pre-existing enum gap this slice did not introduce and does not fix); every
/// CharacterSettings row (ctx <c>0x10000008</c>, all 48); 82 of 87 Emote rows (ctx
/// <c>0x10000006</c>); and roughly half of the UI-class rows (ctx
/// <c>0x10000007</c>/<c>0x10000009</c> — panels acdream has no toggle for, e.g. Vitae,
/// Link Status, House, Map, Character Info, the positive/negative Magic panels).
/// <c>0x10000006</c>); all 10 CameraAlternateControls rows (ctx <c>0x6</c> — the M2
/// de-alias carve-out, see the mapping table's own comment); and roughly half of the
/// UI-class rows (ctx <c>0x10000007</c>/<c>0x10000009</c> — panels acdream has no
/// toggle for, e.g. Vitae, Link Status, House, Map, Character Info, the
/// positive/negative Magic panels).
/// </para>
/// </summary>
public static class RetailActionIdentityTable
@ -86,24 +88,35 @@ public static class RetailActionIdentityTable
M(0x4, 0x10000096, InputAction.Sitting);
M(0x4, 0x10000097, InputAction.Sleeping);
// ── CameraControls (ctx 0x5) + CameraAlternateControls (ctx 0x6) —
// 12 distinct actions, both contexts map to the SAME InputAction
// (alternate/numpad chords for the same camera verb). 22/22. ──
foreach (uint ctx in new uint[] { 0x5, 0x6 })
{
M(ctx, 0x33, InputAction.CameraMoveToward);
M(ctx, 0x34, InputAction.CameraMoveAway);
M(ctx, 0x35, InputAction.CameraRotateLeft);
M(ctx, 0x36, InputAction.CameraRotateRight);
M(ctx, 0x37, InputAction.CameraRotateUp);
M(ctx, 0x38, InputAction.CameraRotateDown);
M(ctx, 0x39, InputAction.CameraViewDefault);
M(ctx, 0x3A, InputAction.CameraViewFirstPerson);
M(ctx, 0x3B, InputAction.CameraViewLookDown);
M(ctx, 0x3C, InputAction.CameraViewMapMode);
}
// 0x3D/0x3E ("Toggle Mouselook"/"Toggle Alternate Camera Mode") only
// author defaults under ctx 0x5 (dev=1 mouse chord + F2/Numpad-Divide).
// ── CameraControls (ctx 0x5) — 12/12. ──────────────────────────
// M2 REWORK (2026-08-11 review): CameraControls (ctx 0x5, the
// Numpad-default scheme RetailDefaults() actually carries) and
// CameraAlternateControls (ctx 0x6, the arrow-key alternate scheme
// RetailDefaults() never had — see
// RetailActionIdentityRoundTripTests' now-retired camera allowlist
// entries) were both previously mapped to the SAME InputAction.
// KeyBindings/Binding has no "which scheme" tag, and SetForAction is
// whole-action replacement, so the two rows aliased one live target:
// both showed identical (stale) chords, rebinding one silently wiped
// the other, and a row could conflict with its own twin. Building
// real per-scheme dual-binding storage (or ten new InputAction
// members plus the camera-dispatch code to consume them) is a real
// feature, not a one-line fix, and out of scope for this rework. Only
// ctx 0x5 — the scheme that already has a live, verified
// RetailDefaults() presence — maps here; ctx 0x6 falls through to the
// generic unmapped/store-only path below (AP-203), fully renderable,
// bindable and persisted, honestly carrying no live effect, exactly
// like every other unmapped row.
M(0x5, 0x33, InputAction.CameraMoveToward);
M(0x5, 0x34, InputAction.CameraMoveAway);
M(0x5, 0x35, InputAction.CameraRotateLeft);
M(0x5, 0x36, InputAction.CameraRotateRight);
M(0x5, 0x37, InputAction.CameraRotateUp);
M(0x5, 0x38, InputAction.CameraRotateDown);
M(0x5, 0x39, InputAction.CameraViewDefault);
M(0x5, 0x3A, InputAction.CameraViewFirstPerson);
M(0x5, 0x3B, InputAction.CameraViewLookDown);
M(0x5, 0x3C, InputAction.CameraViewMapMode);
M(0x5, 0x3D, InputAction.CameraInstantMouseLook);
M(0x5, 0x3E, InputAction.CameraActivateAlternateMode);