Editor UX: keyboard paging for lists/dropdowns, Lift in the built-in palette, and text-field copy/paste and prefab staging copy/paste fix

[mefisme]

What this changes

Three editor-UX improvements from one session. Each is an independent commit, so they can be split if
you'd rather review them separately.

1. Keyboard paging for every list and dropdown (067bc94)

ArrowUp/ArrowDown now page the Entities, Timelines and Prefabs lists (moving the highlight selects the
row exactly as clicking it does), and -- while their dropdown is open -- the Inherit / Classname combos
and the Timelines "Runs on" picker. Filtering still works alongside it; the decl editor, prefab
description and folder-rename fields keep normal caret movement.

The Entities/Prefabs handlers are document-scoped rather than bound to their filter box: "Follow
selection" drives the Entities list purely from the live 3D-editor pick, so the user may never click
into the filter box or a row at all.

Same commit also excludes SnapMap's own built-in filter/droppable helper entities from the entity
list and every entity picker. These are engine-seeded (any player / any ai, per-team/player/race
prefilters, keycards, flags, power cores), dev-layer-only, never placed or edited by a mapper -- and
they buried the real entities whenever Show Hidden was on. Matched on the id starting with
snapmaps/filter/, not containing it, so a mapper's own filter (0_c_ind_cross/snapmaps/filter/ai_151)
is unaffected. The " (no module)" suffix is deliberately not used as the signal, since it also appears
on any real entity not yet assigned to a module.

*2. Lift added to the built-in "Custom" palette (65b9c7e)

A third baked override alongside Timeline and Unknown. Recipe A -- entityDef unchanged, just the
snapeditorentitydef palette tile promoted into the toybox category with its flags flipped
placeable/editable/moveable/deletable. No propertySheets yet.

3. Ctrl+C / Ctrl+V in the editor's text fields (6d29ece, eda795a, 7bd3412)

Vanilla has no text clipboard in the editor at all -- only the dev console accepts a paste. It is
genuinely absent rather than disabled: the engine's SWF text-edit key handler has no Ctrl branch
whatsoever, only a shift flag for selection.

Detours idSWFScriptFunction_onKey::Call, the single keyboard entry point for a focused Scaleform text
field. Copy takes the selection (or the whole field when nothing is selected); paste splices at the
selection or inserts at the caret, mirroring exactly what the stock BACKSPACE/DELETE case does, so it
inherits the engine's own semantics. Works in every text-backed inspector -- free text, int, float, vec3
and size. Respects the field's character cap. CR is stripped; in a single-line field a run of newlines
collapses to one space, while multi-line fields keep them.

No filtering on what may be pasted into numeric fields: the editor already accepts arbitrary typed text
there and resolves it at commit (non-numeric commits as 0, confirmed live), so matching that is more
faithful than inventing a restriction the editor lacks.

Two notes for reviewers:

• The engine's object type check is a pointer-identity compare against an interned type-name string,
  not a strcmp, so a caller must pass the engine's own pointer. It is decoded from the handler's own
  prologue (mov rdx,[rip+rel32] at +0x4B) rather than any hardcoded RVA, and a byte mismatch
  disarms the feature instead of guessing.
• This adds IdStrAssignFromStr, the real idStr::operator=(const idStr&). The existing IdStrAssign
  entry is misnamed -- it resolves to an intern-and-store-pointer for decl name fields, and using it
  on an idStr would write a pointer over the vtable field. Left alone here (it is presumably correct for
  its actual use), but flagging it.

Known follow-ups (not in this PR)

• src/backend/apply_engine.c:350-354 carries a len < 0x10 ? inline : heap idStr read. The engine's
  own idStr::Left dereferences +0x10 unconditionally, and rawmap.c reads it that way too, so the
  two files disagree. The same pattern shipped briefly in the clipboard code and garbled every string
  under 16 chars. Not touched here because it is in the decl-apply path and may be handling a different
  struct.
• Paste has no undo integration -- it is a single edit like any other, but the editor's own undo was not
  exercised against it.
• The Lift override still has no propertySheets.

Checklist

• Clean-room: this is my own reverse-engineering / implementation -- no decompiled or copyrighted DOOM or
  original-SnapHak content is pasted into the repo.
• No binaries added (.dll / .exe / .obj / .pdb / .zip ...) -- the source is the only deliverable.
• Source stays pure ASCII (.c / .h / .cpp / .ps1).
• Built + tested locally: build.ps1 -> package.ps1 -> snapmap-plus install --local dist, and I ran the Go
  (gofmt / go vet / go test) and C (tests\run-tests.ps1) suites, and confirmed it works in DOOM.
• Docs updated in this PR for any behavior change (see docs/contributing.md section 9).

Test detail: 14/14 native tests pass; gofmt clean, go vet clean, go test ./... ok. All three
features were exercised in the running editor. For the clipboard specifically: value persists through
commit and reopen; replace-selection and insert-at-caret; start/end/empty-field edges; round trip
between fields; multi-line into both field kinds; no-focus, empty-clipboard and non-text-clipboard all
no-op; entity-level Ctrl+C/Ctrl+V and Ctrl+X unaffected; no stray characters inserted.

[mefisme]

Added commit 3320152 — native 3D-viewport deselect fixed at the root.

This resolves the long-standing behavior the Deselect button existed to work around, and it turned out to also be the cause of two symptoms we hadn't connected to it.

Symptoms

A selection pushed from the Entities list ("Select in 3D") didn't behave like a native one:

• an empty-space click in the 3D view wouldn't deselect it
• Delete didn't remove all of the selected entities
• Move could soft-lock the game (process alive, controls unresponsive)

Only the explicit Deselect button worked.

Root cause

Reverse-engineered in the companion doom-re project (campaign native-click-deselect).

The editor keeps a per-mode object inline in the editor object, with a state field recording whether anything is selected. The native click handler sets that field on a successful hit and adds to the selection array. On an empty-space miss it deliberately does nothing at all.

So an empty click only deselects because the editor is in the "something is selected" state. add_to_selection wrote the array only, leaving the editor believing nothing was selected — so the miss path correctly did nothing.

That single inconsistency explains every symptom, including Delete and Move; they were never separate bugs. It also explains the old workaround: clicking an already-selected entity in the 3D view runs the native hit path, which sets the state regardless of how the selection was made.

Worth noting for anyone who followed the earlier attempt — the previously suspected field was a "currently held/picked-up" render indicator, which is why writing it only ever changed the hover outline color. The function it was copied from turned out to be the place-a-new-filter path, not the click-select handler.

Change

src/backend/iface_engine.c syncs the mode state alongside every selection-array write:

slot	mode state
add_to_selection	selected
clear_selection	idle
remove_from_selection	idle, only once the selection is empty

That third case is deliberate: without it a full Delete would leave the inverse inconsistency (empty array, mode still claiming a selection).

All writes are SEH-guarded and gated on the editor already being in EntityMode, matching this file's existing conventions. Offsets and a per-build re-derive recipe are documented at the constant block, including a note that the older AddToSelection/ClearSelection RVAs in that file were proven stale — which is exactly why they resolve by signature.

The Entities list also now clears its highlight on a native deselect in "Select in 3D" mode. No backend work was needed: the live selection count was already broadcast on every change (the Prefabs "Create from selection (N)" button uses it), the UI just wasn't acting on it reaching zero. Gated to that mode only, to a real >0 → 0 transition, and to the case where the list actually has a highlight.

Verification

Live-tested in the editor: empty-click deselect, Delete, Move, and all bottom-bar controls work for single and multi-entity selections and when switching between entities; the list highlight clears on a native deselect. Native C test suite passes (14/14).

Notes

• The Deselect button is kept — it saves a trip back to the 3D view and remains the escape hatch if the mode state is ever out of sync — but its tooltip and the stale "the root cause is unRE'd in this codebase" notes in the docs and source comments are removed.
• Known remaining gap, not addressed here: with one entity selected from the list, natively clicking a different one leaves the count unchanged, so no broadcast fires and the list keeps highlighting the original. Fixing that means broadcasting selection identity rather than just count.
• Docs updated: docs/capabilities.md and docs/webview-ui.md.

[mefisme]

Follow-up: commit 5b0a262 — guards the selection-state write. Reviewers should read this together with 3320152; the first commit alone had a real defect, found in live testing and fixed here.

What was wrong

3320152 wrote the EntityMode selection-state field unconditionally. That field is not a two-value flag. The engine drives it to other values while a manipulation is in flight — grabbing/moving an entity, or holding a staged prefab awaiting placement — as well as for sub-screens and the logic sub-mode. It even maintains its own "is the mode busy" predicate, which is literally return mode+0x1ac != 1.

So pushing a selection from the Entities list mid-gesture tore the editor out of the manipulation, and its completion bookkeeping never ran. The held entity or prefab was dropped and permanently lost its module association — every entity then reporting no module, not a display artifact, and not recoverable by refreshing the list.

Fix

mode_set_selection_state() now reads the current value first and only transitions between idle and selected, leaving any other value strictly alone. It also skips the write when already in the target state.

Worth noting the guard is safe under either diagnosis: in the manipulation scenario the new code performs no write at all, so if the symptom had persisted it would have proven the cause lay elsewhere. It didn't — the symptom is gone.

Accepted trade-off

In a mode outside the idle/selected pair with nothing selected, the sync sits out and that mode keeps the pre-fix behavior: the selection lands, but an empty-space click won't clear it (the Deselect button still does). That is strictly preferable to overwriting editor state we don't model. The whitelist can be widened once specific states are known safe.

Re-verified live

• Grab an entity, or hold a staged prefab, then push a selection and place the held object — module association intact, selection present.
• Empty-space deselect, Delete, and Move all still work.

A pleasant side effect: because the manipulation is no longer interrupted, you can hold a grabbed entity or staged prefab, select from the list, place the held object, and still have your selection. One cosmetic inconsistency remains and was judged a non-issue — after placing, a prefab leaves the pushed selection highlighted while a pre-existing-entity grab clears it. Documented in docs/webview-ui.md.

[mefisme]

Final commit on this thread: 8277e1e, docs only.

Worth calling out because it's a capability rather than a doc tidy — list-assembled group grab, which fell out of the guard rather than being designed.

With a selection pushed from the Entities list, grabbing any one of those entities in the 3D view now grabs all of them. That wasn't possible before, and it enables a real workflow: browse a logic chain in the 3D view, add the other entities you want to bring along from the Entities list, then grab the node you're on and move the whole group together. You can also hold a grabbed entity or staged prefab, push a selection, and place the held object without losing that selection.

It exists purely because the guarded version stops interrupting the manipulation — the engine was always willing to move a multi-entity selection as a group, there just wasn't a way to assemble one from outside the 3D view.

Also confirms logic chain mode works correctly under the idle/selected guard, so the trade-off noted on the previous comment is narrower than feared: the logic sub-mode is not one of the states the guard sits out.

Documented in docs/capabilities.md and docs/webview-ui.md.

[mefisme]

Commit 000a10d — refuses selection changes while the editor is holding something. This closes out the selection work in this PR; consolidated summary below so it doesn't have to be assembled from the earlier comments.

A pre-existing engine bug, found while testing the deselect fix

The engine captures a snapshot of the selection when a manipulation starts — grabbing an entity, or holding a staged prefab — and its cancel path (Escape) restores that snapshot indexed positionally against the live selection array, with no re-validation.

Change the selection in between and Escape writes each saved record onto the wrong entity, swapping entity pointers inside the live map. Observed live: entities duplicated, entities vanishing from the map entirely, (no module), and hard freezes. The capture also stashes each entity's real layer/module index, which is why module association is the visible casualty.

Confirmed pre-existing, not a regression — it reproduces on the v0.2.1-beta.2 release, which contains none of this PR's selection-state work. Only cancellation triggers it; mouse click, controller accept and space are all unaffected.

The mitigation

The backend refuses add_to_selection / clear_selection / remove_from_selection while a snapshot is outstanding, failing closed on any read error. The UI rolls back the list highlight and toasts, so the refusal is explained rather than silent.

Detection uses the capture's own side effect: it moves the manipulated entities onto the editor's scratch layer, so "any selected entity is on the scratch layer" is a precise test for "a snapshot is outstanding".

Notably it is not keyed off the engine's "currently held" indicator, which would have been the obvious choice and would have been wrong: placing a new palette entity sets that indicator but captures no snapshot, and is verified safe — Escape behaves correctly there. Keying off it would have blocked a state that never needed blocking.

Exposed to frontends as vtable ext 11 (manipulation_in_progress, +0x2C0), appended at the tail so every existing offset is unchanged. The iface ABI test caught the size change on the first run and was updated.

Reviewing the selection commits

They're best read in order, because the middle one is a regression I introduced and then fixed:

commit	what
3320152	the deselect fix — syncs the editor's mode selection-state
5b0a262	guard: that field isn't a two-value flag; the unconditional write stomped in-flight manipulations
8277e1e	docs — list-assembled group grab, which fell out of no longer interrupting manipulations
000a10d	this one — refuse selection changes while a snapshot is outstanding

The final tree is what matters and it's correct; the intermediate states are only of interest for the reasoning. A squash merge would be entirely reasonable here given the PR's scope.

Verification

Live-tested: grab or held prefab → selection refused with toast, Escape safe; new palette entity → unrestricted and safe; native click select/deselect, empty-space deselect, Delete, Move, and select-then-grab group grab all unaffected. Native C suite 14/14.

Not addressed

• The underlying engine bug. A real fix means hooking capture/restore to re-key the snapshot by entity id — it would fix the vanilla bug rather than avoid it, but it's invasive and belongs in its own change.
• Cosmetic: while an entity is grabbed, the other selected entities render in the move/grab colour instead of the normal selection colour.

[mefisme]

Just noting:
src/backend/apply_engine.c:350-354 carries a len < 0x10 ? inline : heap idStr read. The engine's
own idStr::Left dereferences +0x10 unconditionally, and rawmap.c reads it that way too, so the
two files disagree. The same pattern shipped briefly in the clipboard code and garbled every string
under 16 chars. Not touched here because it is in the decl-apply path and may be handling a different
struct.

This fix is included. That section of the main PR message can be ignored. Regardless whether its fixed or not, we could never test cause the file size for a json is unrealistically never going to be less than 16bytes unless some write failed.

[mefisme]

Previous commit failed. Forgot to run tests. Found the fix next commit will pass.

[adiazpar]

Reviewed against a real merge into main: no conflicts, build clean, 14/14 native tests, Go suite (gofmt/vet/test) clean, terminology gate FAIL=0. The engine work is careful and well evidenced -- the SEH-guarded reads, the fail-closed manipulation gate, and decoding the interned "TextField" pointer from the handler prologue instead of hardcoding it are all the right calls. Confirmed independently that the ae_read_idstr small-string branch you removed really was wrong (the inline base buffer is at +0x1c, not +0x10), and moving PrefabCtor/PrefabPopulate off raw RVAs onto signatures is a genuine portability improvement.

Merging as-is; I am landing a small follow-up commit for four things found in review. Full detail in the follow-up, but the headline is worth flagging because it affects your future work more than this PR:

The four new signature entries store new-build addresses in known_rva. Verified: each pattern occurs exactly once in the pinned build at a different address, and all four occur in the current-retail build at exactly the values committed here. So your Ghidra project is the post-April-2024 DOOM while your test install is the pinned build. Nothing malfunctions -- byte signatures are build-portable, so every runtime path resolves correctly on both, which is why your live testing passed. Only the known_rva fallback (used when another mod has detoured the function) is affected.

This is our documentation's fault, not yours: signatures.c calls the field "the extraction-build RVA" without naming which build, and the test that would catch it (run-tests.ps1 -Doom) is opt-in and never runs in CI. Both are fixed in the follow-up.

Same cause behind the iface_engine.c note that the AddToSelection/ClearSelection RVAs are stale -- 0x11fad50/0x11fb540 are correct on the new build (exactly +0xC5BB40, matching our own newbuild measurements), while 0x59f210/0x59fa00 remain correct on the pinned one. I am rewording rather than deleting, since the new-build values are useful.

Non-blocking, worth a look when convenient: the Ctrl tracking in swf_textedit.c latches from the SWF handler's own key pairs, so if focus is lost between Ctrl-down and Ctrl-up a later bare 'v' in a text field would paste as well as type -- a GetKeyState(VK_CONTROL) check at use closes it.