Summary
In UE 5.8.0, Alt+drag on the end point of a USplineComponent spline operates on the wrong key: instead of duplicating the grabbed end point and dragging the copy, it inserts the new point at the start of the spline (index 0) and moves the original first point, leaving the point you actually grabbed untouched. This is a regression — the same action worked correctly in 5.7.0 — and it reproduces engine-wide (stock Spline actors and third-party tools like SplineArchitect alike). Diffing 5.7→5.8 shows the spline visualizer’s duplication, selection, and click-handling code is byte-identical, so the wrong LastKeyIndexSelected is being fed in from below the visualizer (the spline runtime or editor gizmo/hit-proxy). The new SplineComponentVisualizer.IgnoreSpuriousDeselect CVar does not fix it.
What Type of Bug are you experiencing?
Editor
Steps to Reproduce
- Any actor with a USplineComponent (repros on a stock Spline actor and third-party tools like SplineArchitect).
- Select the spline’s end point, Alt+drag to extend.
Expected Result
Expected: a duplicate of the end point is created and dragged. Actual: the duplicate is inserted at the start (index 0); the original first point moves while the new point stays put — i.e. the operation acts on point 0, not the grabbed end point.
Observed Result
Observed Results (captured via per-frame spline-point logging during the repro; grabbed the wall’s end point):
Spline had 13 points; after the Alt-press it had 14 — the new point was inserted at the start of the array (index 0/1), not at the grabbed end.
At drag start, points 0 and 1 were coincident at (-270, 141) — the spline’s start corner. (The end point Steve grabbed was (749, 19), index 13 — untouched.)
Through the drag, point 0 stayed frozen at (-270, 141) while point 1 swept (-270,141) → (-273,141) → (-281,141) → … → (-340,141). Every other point static.
On release: 0:(-270,141) 1:(-340,141) — a valid 14-point spline, but the new point landed at the start and the original first point was the one that moved.
Net: the gizmo operated on key index 0, regardless of the end point being selected. The grabbed end point never moved and got no duplicate.
Supporting facts from the same capture (rule out the host actor as a cause):
Throughout the drag the host’s editor transaction was open and its rebuild fired zero times — nothing but the stock gizmo touched the spline.
The resulting spline is geometrically clean (no stuck-coincident points) — so this is wrong-key selection, not data corruption.
Affects Versions
5.8
Platform(s)
Windows
Additional Notes
Diagnosis (already narrowed): Not in SplineComponentVisualizer.cpp. Diffing 5.7→5.8, the only changes there are OnDeselectedInEditor/GIgnoreSpuriousDeselect, a HandleInputDelta “stale selection drift” clear, and delegate RemoveAll-before-Add. All ruled out: CVar SplineComponentVisualizer.IgnoreSpuriousDeselect 0 does not fix it, the drift branch never fires, and DuplicateKeyForAltDrag / AddSegment / GetVerifiedLastKeyIndexSelected / GetWidgetLocation / the click→select path are byte-identical to 5.7. So LastKeyIndexSelected is being set/fed incorrectly from upstream of the visualizer — likely USplineComponent point insertion/IsClosedLoop or the editor gizmo/hit-proxy.