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.
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
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.
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)
While it may appear to have the same end symptom as the OP’s case, it does help us to know which games are affected, for our QA to regression test them. Sometimes a bug that seems the same as someone else’s can have a different cause (e.g. two or more places in the code that have a similar bug, but in different branches hit by different games). Also, it helps us gauge severity of the issue to know which games are affected, so that we can take the time we need to find all the issues we have to fix, but not leave a flag on that is inconveniencing thousands of players.