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.
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.
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)
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.
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.
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.
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.
Hello! As others have mentioned, this was an intentional change. We didn’t have any guarantees on the methods and members of the CameraModule, and it was very likely that directly accessing the values will lead to errors with future updates. E.g. we might remove the GetCameraToSubjectDistance method altogether. We’re currently in the process of a major Playerscripts change and one of the areas we’re working on is a better API to interface with the system for common properties like first person.
Regarding the zoom level, the best way I’ve seen to determine first person without forking is to measure the distance between the camera’s CFrame and the camerafocus’s CFrame.
Glad to see that we’re getting a better API for this system soon, it is a hazzle relying on hacky methods to access a value for a project that requires it.
I’ll definitely give it a try in my systems when I have to calculate distance from camera to character.
