Uh, that’s normal Scriptable behavior. Unlike the other CameraTypes it allows no user input for movement. Unless you are using a custom camera system, you may be mistaking it for another CameraType (Custom is the default behavior with mouse drag panning enabled).
EDIT 2: My bad, I think I misunderstood the bug. Not your fault, but it would be more clear as “Mouse locks when right-clicking while CameraType is Scriptable”.
It’s definitely not. I’ve been using a Scriptable camera for the Build-Mode in Welcome to Bloxburg for a few years and the mouse has always been able to move while right clicking, which stopped working today.
Perhaps you’re thinking of MouseBehavior instead?
Yeah, I misunderstood it at first glance too. Thought he meant moving the actual camera.
I’m experiencing this behavior as well.
Also, possibly related, I haven’t been able to check it out in detail, but today’s changes really broke my camera system. I had it set to Scriptable and was setting the CFrame manually. Whatever changed today has caused my cameras to be pointing several studs below where they should be, and they’re really shaky now. Hoping that Roblox will roll this back so I don’t have to debug.
Camera is definitely scriptable – you can repro this in an empty baseplate. This is definitely a bug related to today’s camera changes.
Ah, so an update DID break some camera stuff. I was sitting here pulling my hair out because the camera wouldn’t cooperate with CFrame changes.
Whatever they changed today is actually causing my game to be unplayable. My game pans the camera towards a specific part, and once the part is visible, shows a menu stemming from the part. However, with today’s changes, the camera is several studs below where it should be, meaning that the part is never visible on the screen, and the menu is never drawn. Thus, new players are stuck and can’t progress past this creation screen, their only option being to leave the game.
I hope this gets rolled back before the end of the day!
Edit: Dysplexus’ repro two posts below this covers the same issue I’m running into here.
I can also confirm, except that it appears when using non-humanoid camera subjects on most camera types the camera fails to work, as it affects several of my games that relied on custom characters.
I’ve too did some experimenting and found that while using a character the camera would do some funky things. However without a character, the camera works just fine (for me). I have a Repro file in case someone wants to check it out. Just hit play and in the output it will tell you what is happening. Repo.rbxl (15.6 KB) I
EDIT: I misspelled Repro, rip
A lot of my camera manipulation scripts broke today as well, that use the Scriptable type. CFrames are getting seriously messed up.
All of my camera code broke as well, people aren’t able to play my game right now…
Thank you for reporting this issue!
Our engineering team are actively looking into this issue and will follow up with more updates soon.
Thank you!
We flipped the flag back to turn off Lua implementations of some of the cameras while I look into some of these issues. Most stem from exposing a bug in RootCamera where it is managing the LockCenter, LockCurrentPosition for CameraTypes it should not be (like Scriptable).
Just a heads up though, if you have a case where you are relying on the Studio build camera code in a game (i.e. being able to move the camera direction with right mouse button when in a mode like scriptable or Watch), this will not be fixed (it will work again now, but break the same way next time we enable Lua cameras), that was never intended behavior and that studio camera code will not be active in games for much longer. If the CameraType is Scriptable, the camera should only be doing what your custom LocalScripts tell it to do–no mouse or WASD control unless you explicitly code it.
If you posted here yesterday about your game having issues with the Lua cameras, please do provide a link here to the affected game(s).
The rollback of this change is only temporary, so that I can fix the few issues we saw with the mouse cursor locking and with Poppercam running when it shouldn’t (e.g. when cameraType is Scriptable). If your game broke, and you have not made a copy of CameraScript in your place, problems you saw might not recur. If you have forked CameraScript, you will very likely need to merge in some changes.
If your game broke due to relying on WASD or RMB camera control in a Scriptable, Fixed, Watch, etc. That will break again and will stay broken and you have a bit more work to do. Cameras of these types are not supposed to respond to any user input that is not explicitly set up by the developer. MouseButton2 still working to rotate the camera in these modes was a long-standing bug in C++ code, code that is disabled by the Lua camera flag and is going to be removed.
Did you guys re add the update again?
Noticed that a number of games are having issues again.
I will try to reproduce the issue
I think the bug is back, my camera is not working anymore with right-click on ‘scriptable’, serious issue.
Place link?
You can reproduce the bug with the same repro the OP posted
So this is also the issue of right mouse button causing the mouse to use LockCurrentPosition behavior in Scriptable? If so, that will be the first fix we make to the Lua camera scripts.
I believe so, the camera is completely locked no matter what you do. This completely breaks my game (and games that rely on custom camera scripts I would say)