Unable to move mouse while right-clicking when CameraType is Scriptable

Bug Reports Engine Bugs
#41

Ohh so that’s why, after I removed the old one and replaced it with the latest script it worked like it should.

Thank you soooo much @Coeptus :+1:t2:

#42

Still having problems with the scriptable camera type, has the fix gone live tuesday at all?

#43

This is still a huge issue…

Right click will stop all mouse movement…

@AllYourBlox

#44

The fix for the RMB Scriptable mouse lock issue went live last week, and I’m not able to reproduce the issue anymore in a new place, or either of the games linked above. Are there specific repro steps required?

Just a reminder, the fix was never expected to automatically unbreak all affected games–that’s not possible since the C++ code the older camera scripts needed is now gone. The only games that will automatically get fixed by last week’s patch are those that have no copies of older Roblox camera scripts in StarterPlayerScripts and no conflicting camera LocalScripts anywhere else (StarterGui for example). Games that have forked copies of older versions of the Roblox player scripts will need to be updated by the developer to merge in the fixes from the current deployment, so that they can access the Lua versions of the camera types that used to be in C++ (Scriptable, Watch, Track, Attach).

1 Like
#45

I’ve been getting messages of this happening in my game today as well. Once I read this I checked if removing any of the StarterPlayerScripts would work, but it is still occuring. My game is featured and is relying on Scriptable behaving the way it did, because in some situations, changing the camera mode to Custom works, but in others the original behaviour is necessary.


In this game, once you right-click while riding, people have experiences the camera getting stuck until you get off the board and the camera is set back to custom.

Edit: It is not a 100% reproducable in this game, personally I’ve had it happen once earlier today, and have also had a clean playthrough without encountering it.

#46

The issue described in this quote is still happening at my game found here: Version B: Pulse - Roblox
There is nothing inside either folder under StarterPlayer. Happens 100% of the time.

To reproduce:

  1. Join the game
  2. Click “Ships” from the menu, and then “Test Ship”
  3. Drive around the track by holding left click and steering by moving the mouse.
  4. Click right mouse button (which is the brake) and trying to steer with the mouse will no longer work as the MouseBehavior has been changed to Default instead of LockCenter.
  5. You can hit Left Alt to manually set the mouse to Default (to navigate menus) and again to set it back to LockCenter to test it repeatedly.
  6. To get the dev console to print the MouseBehavior, press Right Alt.
#47

I manually fixed these games before you reviewed them, the issue still stands as these recent posters have noted.

#48

I’m having the same problem, there are no camera or control scripts in starterplayerscripts.
It’s been happening for me for about a week, completely breaks my planes and other things.

#49

Yeah, it looks like I inverted the problem. If you want to quick fix it before my next patch to these issues is live, you can copy the current CameraScript hierarchy into your place file, in StarterPlayerScripts, and find the following code block in RootCamera, at around line 456:

if camera.CameraType == Enum.CameraType.Scriptable then
		UserInputService.MouseBehavior = Enum.MouseBehavior.Default
		pcall(function() 
			if GameSettings.RotationType ~= Enum.RotationType.MovementRelative then
				GameSettings.RotationType = Enum.RotationType.MovementRelative
		end
	end)

Comment out this line:

UserInputService.MouseBehavior = Enum.MouseBehavior.Default
2 Likes
#50

Thanks a bunch that fix works.

#51

Just a head’s up, we’re going to turn off the place filter tomorrow that was allowing a few games to use the old C++ code. The fixes are all live, and most of the games should continue to work, except for those that have forked old copies of our playerscripts and have not merged in the changes. As noted earlier in this thread, there will inevitably be a few games that use the old scripts that will need minor changes made by the developers. The new playerscripts we’re about to introduce have a significantly different structure than the old ones, and it’s simply not possible (or desirable) to guarantee that every edge and corner case is handled exactly the same by the two versions. Trying to force them into agreement with lots of special-case if clauses would just make a spaghetti mess of the new system.

That said, if you have a game that is currently exempt from the UserAllCamerasInLua flag, and you haven’t made any pre-emptive updates to make it work with this flag on, please let us know if something breaks, and how.