Starting today, LockCenter/LockCurrentPosition MouseBehaviors no longer work correctly for Orbital/Watch CameraTypes. The mouse will be moved to the center of the screen for LockCenter, but then the mouse can be freely moved immediately afterwards. It seems the Orbital/Watch cameras are resetting MouseBehavior?
In the repro, the localscript waits 2 seconds and then sets the cameratype to orbital + sets mouse behavior to LockCenter. After the mouse is moved to the center, it becomes unlocked and I can move it around freely again.
Glad to see I am not the only one having issues with the camera. I’m not having the same exact issue as what you’re describing, but I am experiencing some very funky behavior with setting the Camera CFrame using the Scriptable CameraType. Some CFrame values make the camera start tweening forwards randomly.
Of course I figured it was an issue on my end first, but the issue started happening today after not touching any code associated with the functions described above. I’ll still do more testing to find out if it’s on my end, but seeing as you are having weird camera trouble too starting today I suspect it is a result of a change on Roblox’s end.
If it started happening today with no changes on your end, definitely sounds like a Roblox issue. If you can provide a repro file that demonstrates the issue, the engineers should be able to figure out what’s going on and fix it.
This was not the case before these changes. With the appropriate flag disabled, setting MouseBehavior locks the mouse without needing to reset it in a loop.
I can confirm something has changed with Orbital camera. Before this afternoon, I could set the OrbitalCamera to be zoomed in using CameraMaxZoomDistance and CameraMinZoomDistance as the same value.
I was locking the mouse with UserInputService.MouseBehavior
In order to allow the mouse 2 button to not have to be pressed to rotate the camera, I was using this combination of settings:
Although this was sort of a hack, I was trying to emulate MouseLockSwitch without forking the control scripts.
Sample code:
function LocalUserCameraManager:_lockDirection()
if self._torsoLockedToCamera then
if self._mouseLocked then
pcall(function()
GameSettings.RotationType = Enum.RotationType.CameraRelative
end)
end
else
pcall(function()
GameSettings.RotationType = Enum.RotationType.MovementRelative
end)
end
self.torsoLockedToCameraValue.Value = self._torsoLockedToCamera
end
function LocalUserCameraManager:_lockMouse()
UserInputService.MouseBehavior = self._mouseLocked and Enum.MouseBehavior.LockCenter or Enum.MouseBehavior.Default
end
function LocalUserCameraManager:_lockCamera()
if self._mouseLocked then
self._camera.CameraType = Enum.CameraType.Orbital
end
end
function LocalUserCameraManager:SetMouseLockMode(isEnabled)
self._mouseLocked = isEnabled
self:_lockCamera()
self:_lockMouse()
self:_lockDirection()
end
Yea, I’m having issues with using the Interpolate function of the Camera on type Scriptable, its like something else is stoping the tweening of the Position part of the camera but not the direction.
Example: https://gyazo.com/20df11909d30bb718d8e0a477162102c.mp4
The change has been reverted. The LockCenter and LockCurrentPosition issues are going to be fixed, but a few of the behaviors reported are relying on long-existing bugs or unsupported behavior (like having WASD and mouse control of a scriptable or fixed camera due to Studio build camera C++ code being invoked in a game setting).
Also, Camera:Interpolate() is slated for deprecation and will actually be going away as it’s the only remaining bit of C++ camera code that still executes. If you use Camera:Interpolate(), you should convert your code to use TweenService or do your own tweening (CFrame.lerp and Vector3:lerp can do linear interpolation of translations, and CFrame:lerp does proper slerp of rotation CFrames using quaterions under the hood, just FYI).
