Avoid moving already placed objects temporally when "limit distance snap to current time" is active #31743
Conversation
…nap to current time" is active
|
|
||
| // Retrieve a snapped position. | ||
| var result = Composer.TrySnapToNearbyObjects(movePosition); | ||
| result ??= Composer.TrySnapToDistanceGrid(movePosition); | ||
| result ??= Composer.TrySnapToDistanceGrid(movePosition, limitedDistanceSnap.Value ? referenceBlueprint.Item.StartTime : null); |
There was a problem hiding this comment.
The specification of referenceBlueprint.Item.StartTime rather than editorClock.CurrentTime is the fix here.
| @@ -437,7 +446,7 @@ public void DragInProgress(DragEvent e) | |||
| Vector2 newHeadPosition = Parent!.ToScreenSpace(e.MousePosition + (dragStartPositions[0] - dragStartPositions[draggedControlPointIndex])); | |||
|
|
|||
| var result = positionSnapProvider?.TrySnapToNearbyObjects(newHeadPosition, oldStartTime); | |||
| result ??= positionSnapProvider?.TrySnapToDistanceGrid(newHeadPosition); | |||
| result ??= positionSnapProvider?.TrySnapToDistanceGrid(newHeadPosition, limitedDistanceSnap.Value ? oldStartTime : null); | |||
There was a problem hiding this comment.
I kind of wonder if this case even makes sense. To elaborate, this is the case where you're dragging a set of slider path control points that includes the slider head control point. I debated whether applying limited distance snap even made sense in this instance, and if it did, to which time snapping should be performed.
This is partially why I tore down all the abstractions earlier in #31655 - they really cover a lot of these head-scratchers up.
There was a problem hiding this comment.
I'm not sure either, let's wait for someone to complain I guess.
|
This seems to roughly match expectations. Ignoring the part where distance snap almost never matches my expectations (but this is a separate issue). |
Before:
2025-01-31.09-46-55.mp4
After:
2025-01-31.09-48-53.mp4