Native CameraModule returns blank table value

I have no idea whenever this is intentional or not, but attempting to use PlayerModule:GetCameras() returns a blank table. If looking at a native CameraModule script (which is obtained by forking PlayerModule when ingame), for some reason, instead of returning object with it’s methods and dictionaries, it returns {}, a blank table value.

This happens with Native (or from Roblox’s Engine) CameraModule that is inserted with PlayerModule when there is no PlayerModule module present in StarterPlayerScripts.

This ruins my workflow, as the impact is mediocre and I have to access GetCameraToSubjectDistance method to get the zoom of the camera, but it’s not possible. If I want to access it, I have to fork the module and make it so the CameraModule returns constructed object.

Here’s pictures of

this happening

If this issue is addressed, I won’t have to fork PlayerModule just so I can fix the camera module myself while keeping those up to date without me manually keeping it up to date.

The reproduction steps can be found here:

CameraModuleRepro.rbxl (42.1 KB)
… Or can be done via local script provided below.

local PlayerModule = require(game.Players.LocalPlayer.PlayerScripts:WaitForChild("PlayerModule")) --await for native playermodule
--we're waiting for Roblox's PlayerModule to show up in PlayerScripts.
--By Roblox's PlayerModule, we mean the original module that is inserted when there is no module of the same name in StarterPlayerScripts
--Roblox does not overwrite PlayerModule with original one if there is already a module of the same name in StarterPlayerScripts, allowing to make forks or modifications of it.

local Cameras = PlayerModule:GetCameras() --this should return a camera object or array containing camera objects (unsure what does this return)
print(Cameras) --an empty table is outputted into console instead of what its supposed to be an object with its methods and directories.

Expected outcome:

Array of camera objects or a camera object (not an instance, by object, we mean as in OOP context)

Actual outcome:

CameraModule returns {} (blank table)


We’ve filed a ticket into our internal database for this issue, and will come back as soon as we have updates!

Thanks for the report!


Alright, also just to clarify, this is a potentially Engine related bug, not just studio bug. It appears to spread outside of Studio, I have ran local script in-game and the issue exists here too.
local a = require(game.Players.LocalPlayers.PlayerScripts.PlayerModule) for i,v in pairs(a:GetCameras()) do print(v) end
If everything’s fine, this should’ve output what would camera object contain into console, but it doesn’t. Done this with Adonis’ local script vLua, though relatively same should happen with actual LuaU.

1 Like


This is not a bug, but rather an intentional change Roblox first introduced in 2020. (The situation might have been changing a little, though I haven’t always actively kept track). It seems to be a conscious decision to prevent developers with less experience from modifying the modules and potentially creating exceptions that could render their game unplayable.

On the contrary, many, including myself, are compelled to fork the CameraModule and modify the last line to return the object and acquire access. Personally, I modify camera on regular basis (smoothing, modified mouse lock, modified poppercam etc.), and it would be easier to have a default path.

It doesn’t seem like a big issue, but rather an inconvenience. Camera modules may get updated and the forked script won’t reflect those changes.

We cannot require individual modules either, because they are classes configured by the default camera.

All those things considered, reinstating public access wouldn’t hurt. Developers carry certain risk of their game breaking, but that’s just part of the developer’s work. If they are sceptical about doing any changes, they can always leave those modules intact.

Edit. I’m glad you’ve opened a newer discussion on this. You have my vote :slight_smile:


oh. Yeaah this feels rather inconvinient that now the camera object is protected. Thanks for mentioning it, I just really needed to get camera zoom to know whenever the person is in First person without doing CFrame math and hopefully saving potential performance.

local player = game.Players.LocalPlayer
return player.Character.Head.LocalTransparencyModifier > 0

That technically won’t work if the player uses the mouse scroll in small enough increments, but overall having a very simple variable that just tells you when the player is in first-person will be way better than resorting to checking for side-effects of being in first person, like character transparency or whether the mouse is locked.