-
Bug
-
Resolution: Fixed
-
1.21.0.24 Preview, 1.20.81 Hotfix
-
None
-
Confirmed
-
Multiple
-
1233401
The bug
When running /camera set with a position and without any easing, the expected behavior is for the camera to go there immediately, canceling any ongoing camera moves. Instead, it merely sets the destination of an existing camera move, causing a discontinuous jump between the a point on the path to the old destination, to a point on the path to the new destination.
How to reproduce
Run these commands from chat:
/camera @a set minecraft:free ease 10 linear pos ~ ~10 ~
Wait a few seconds, then
/camera @a set minecraft:free pos ^ ^ ^10
Expected behavior
After running the second command, the camera instantly snaps to the destination and stops
Observed behavior
After running the second command, the camera instantly snaps to an arbitrary location and continues to move to the destination over some seconds
Notes
This is a problem because it makes jump-cuts very awkward. The only way to interrupt an ongoing interpolation and start a new one is to run a 0.0001-second ease, wait a tick, then issue the proper ease. Delaying commands is very difficult in Bedrock functions, so this workaround is unpleasant. Delay issues with the camera are why MCPE-173524 was reported and fixed.
It's difficult to see any use case for the current behavior of /camera set replacing only the destination of an existing interpolation, since there will always be a discontinuous jump as the points change but T remains the same. By contrast, when ease is used, both the start and end points are updated, so even in the middle of an existing interpolation, the remaining transition will be smooth. Since no-ease set jumps anyway, I expect it to also clear any ongoing interpolation and jump to the target point.
- relates to
-
MCPE-183986 /camera set still behaves incorrectly when run during an existing camera interpolation
- Resolved