Just until this morning, the scriptable camera would lock your mouse in place in order for you to use the delta property for custom camera systems. Now, it doesn’t. It’s been happening in places that I haven’t updated since before the problem every time I’d try.
Every single place that uses a custom camera system I’ve made from scratch (all of them, what’s the fun in modifying the default one?) is now broken and is unplayable.
REPRO:
Step 1 - Set the CurrentCamera’s CameraType to Scriptable
Step 2 - Try right clicking to lock the mouse’s position as if you were trying to move the camera. It will not lock like previous updates.
Step 3 - If possible, use a camera system that doesn’t use any piece of the default camera system. You’ll notice it also has the same problem and you can no longer lock the mouse’s position by holding the right mouse button.
This doesn’t happen in the studio’s test mode, but it happens in every online game that this should occur in.
The most recent time I noticed it happening was when I played an old minigolf project I made, and I noticed that the editor camera no-longer worked at all. This happened yesterday.
NOTE: The camera system must be scriptable to have this problem.
This is intentional. Scriptable is supposed to do nothing, leaving all control up to you – it locking the mouse on RMB was a bug. If you want this behavior, you can manually set MouseBehavior to achieve the same effect.
The issue is that MouseBehavior.LockCenter must be true to register mouse input and when you right mouse click or middle mouse click, the camera switches to MouseBehavior.Default.
My current “fix” is to check if MouseBehavior ~= LockCenter in a renderstepped loop and then set it back to LockCenter. Pretty sure that’s unintentional behavior.
I think a lot of games are probably affected by this. I know that the featured game Robot64 (currently with 800 pc players) is broken for many users because of this issue.
Before last night I could still hold RMB to rotate the camera after it broke but a recent update or flag has made it so that even holding RMB doesn’t turn LockCenter on.
function this:UpdateMouseBehavior()
-- first time transition to first person mode or shiftlock
local camera = workspace.CurrentCamera
if camera.CameraType == Enum.CameraType.Scriptable then
UserInputService.MouseBehavior = Enum.MouseBehavior.Default
By the comment it seems that method was only intended to be called when major changes were made to the camera (camera type, first person/mouselock, etc), but it’s used in OnMousePanButtonPressed as well. Expected behavior is that MouseBehavior only changes when first changing from some other CameraType to Scriptable, and never other than that while the CameraType is Scriptable unless explicitly modified by the developer.
This bug was mentioned before in a prior thread a few weeks back. According to staff, it is matter of fact a issue with changes made for further improvements. They said it would be fixed within the Tuesday update but I can confirm that it seems to be still an issue.
It is definitely unusual behavior and only happens when utilizing the original camera scripts in conjunction with additional scripts for custom camera work.
In my case, I use the delta of the LockCenter for some funky camera stuff, but as of right now, right click disables LockCenter until told again via other scripts. It is certainly weird behavior based on the current default camera scripts.
I assume the issue here is similar and it is game-breaking for a couple games from what I’ve seen, requiring a DM to the staff for now to fix.