(GAME-BREAKING): Players can set Camera Mode regardless of DevComputerCameraMovementMode setting in StarterPlayer

It seems I’m not the only one experiencing this issue, but this is actually very game-breaking for me, since my game employs a custom camera, which is completely unusable for some users who use custom camera settings.

This seems to only happen to me per-place, so I can’t create a minimal repro; however, I’ve extensively searched my codebase for anything that affects StarterPlayer.DevComputerCameraMovementMode, Player.DevComputerCameraMode, and similar settings, and found nothing. I’ve also created the following local script to print out the DevComputerCameraMode setting on the local player:

while wait(2) do
	print(game.Players.LocalPlayer.DevComputerCameraMode)
end

DevComputerCameraMode never changes from “Classic” on the local player


Yet I’m able to change the setting regardless:

This only happens in a live server, and never happens in studio.

My guess is that this is a race condition, which the CoreGui menu is taking a snapshot of when you join the game, before the value of DevComputerCameraMode, copied from the value set in StarterPlayer, is replicated. It changes from “Set by developer” to the UserChoice option after game.Loaded is set to true, as evidenced by the fact that this changes only after my ReplicatedFirst splash screen fades away.

So my guess is it’s a race condition something along the lines of this:

  • Player object is created on the server, with DevComputerCameraMode set to UserChoice by default
  • Server sets DevComputerCameraMode to the value equivalent to StarterPlayer.DevComputerCameraMovementMode
  • Player object is created on the client, with DevComputerCameraMode set to UserChoice by default
  • The CoreGui menu takes a snapshot of this value on the Player object
  • Client receives the newly replicated value of LocalPlayer.DevComputerCameraMode
  • The CoreGui ignores this new value because even though the value has changed.

I’m guessing maybe the Changed property of Player isn’t firing client-side when this all happens, and that’s why there’s a race condition? The RobloxGui menu seems to be listening to Changed to see if the DevComputerCameraMode property changes, but this is probably why.

This is the place that this happens on:

This bug is driving me nuts, since it’s completely out of my control, and it actively harms my users’ experience.

15 Likes

Hi,Thanks for the report! We’ve filed this internally and we’ll follow up here when we have an update for you.

7 Likes

I am in the process of checking over bug reports and following up on some bugs that haven’t received any activity in a while.
Is this issue still occurring or can you confirm that this bug has been resolved?

It is still occurring on Dawn of Aurora, yes, although I was never able to pinpoint a repro.

Can confirm this is still happening. I can reproduce it in my games as they have that setting disabled in StarterPlayer already and rely on a custom camera system. When the player changes their camera mode in the menu (which they shouldn’t be able to), the camera breaks permanently and no matter what the player does, there is no way to fix it.

Alright, when there is any info on this issue i will pass it on.

4 Likes

I first noticed this bug a few months ago and I thought that it was a one time glitch until I saw this thread the other day. I have been trying to reproduce this bug on a bunch of devices with a bunch of different accounts and I have been able to reproduce this 50-60% of the time and I have also found a somewhat hacky workaround for this.

I have not been able to reproduce on an account that is using the Windows or macOS desktop client that is in the AB test for the new in game menu that Roblox has been testing for almost a year now. Currently any user that has “00” as the last 2 digits of their UserId has this new menu. I tested this on my account which has the UserId 711587500 and on my sisters account which has the UserId 453848800 on the macOS client. I have been able to reproduce this issue on all of my alt accounts that I have tested this with.

I am still able to reproduce this issue on users that are in the new in game menu A/B test in the mobile app (I have only tested the iOS app so I am unsure about Android) and in Roblox Studio test mode (I have not tested Team Create Test yet).

I have noticed that this bug mostly occurs when joining a public server after playing in a private server (and vice versa) but it also seems to occur at random times.

Workaround:

I have found a workaround that is kind of hacky but has worked for me whenever I have tested it. If you use PlayerScripts:ClearComputerCameraMovementModes() / PlayerScripts:ClearTouchCameraMovementModes() and then use PlayerScripts:RegisterComputerCameraMovementMode([[Camera Mode Enum here]]), it will only display the camera modes that you called this function with in the menu so if I only register Classic, the camera mode will say that it is set to “Classic” but it won’t have any other options so the user cannot change the setting if this bug occurs If the bug does not occur, it will just say “Set by Developer”.

Here is the place where i have the workaround applied: Roblox Camera Bug Repro / Workaround - Roblox

RBXL file with the PlayerModule and the workaround script: RobloxCameraBugRepro.rbxl (142.3 KB)

Screenshots:

The Camera Mode always says “Locked by Developer” in the A/B test in-game menu.

Old in-game menu with camera mode locked.

With the workaround, it will not let you change the Camera Mode when the bug occurs.

2 Likes

There is still no word on this and it has not been fixed yet. A lot of players end up changing their camera and get confused when the game breaks and they’re unable to move their camera properly anymore.

Edit: For anyone also facing this issue, you can temporarily work around this without forking PlayerModule by comparing the camera’s position versus the expected position. If the difference is too large, destroy the CurrentCamera and assign it again as soon as a new Camera exists in workspace. This is, of course, case specific, and can lead to buggy behavior. At least there is a way to minimize the impact until Roblox fixes this!

2 Likes

Hey I’m experiencing this issue on mobile too. Is it just me or iOS iPad is also experiencing this too? A workaround I’ve found is wait a few minutes and It’ll stop or esc and mess around with the settings.

Hey, sorry I’m late to the party. I’m taking a look at this personally and will try to have a fix out soon :grinning:

4 Likes

Update: Should be fixed now :smile: Thanks for bringing this to my attention!

2 Likes