Even if it were possible to have multiple camera instances in workspace, there should never be a reason to have that, its a safe assumption to say that there will only ever be 1 camera in workspace unless a accident happens and if that accident were to happen it would be easily fixed
Forgot to factor in actual parts or models named Camera, that does make a valid point
I can give multiple reasons to have multiple cameras, starting with a payday 2 like CCTV camera system.
Directly indexing for children is bad practice anyways, it is not forwards compatible as you are assuming Roblox won’t introduce a member with the same name as the child. Remember that class members have higher precedence over children when indexing. Use :FindFirstChild and :WaitForChild instead. So the advice given in the documentation is valid.
I don’t quite understand the example you gave, you can just modify the existing camera or if you have a specific camera object at the very least it should be parented to a model or even have a different name?
Directly indexing in this case should be quite valid? when your using .CurrentCamera that just a property referencing the camera object of the player viewport, even if there was a chance for camera to be nil the property(value) would be nil aswell, so the same argument can be made about directly indexing a proprety for the camera reference
Instances can’t be nil. And not sure what you mean by everything else. workspace.CurrentCamera is safe, and it is never nil.
Well I assumed the reason you mention waitforchild/findfirstchild was because the camera object might be nil when I reference it? (might of misread so extra clarification would be nice if I did get this wrong)
Instances can be nil in a sense that they didn’t fully load in yet, for example Player.Character is also a proprety and the proprety can be nil if the character hasent fully been loaded in yet or hasent been set yet by roblox back-end stuff which is why people tend to do
Player.Character or Player.CharacterAdded:Wait()
Yes however that is intended that is why Roblox has an event for it. There is no “Workspace.CameraAdded” event.
workspace:GetPropertyChangedSignal(“CurrentCamera”):Wait()
I was stating that if camera was impossible to become nil, then there no harm in directly referencing it without .CurrentCamera, unless obviously there was multiple objects with the same name
There is, you are assuming Roblox won’t add in a member named Camera as a part of Workspace. Use :FindFirstChild if you are so keen on avoiding the property.
Alright, I was just wondering why people use .CurrentCamera over just directly getting it from workspace, its not like im avoiding i was just curious thanks for your input 
You can use Workspace.CurrentCamera is a property of the workspace and Workspace.Camera is an instance. Like both work, their is no one concrete method so there is no diffinitive method but Workspace.CurrentCamera is the more ideal method for finding the active camera.
This post answered the question perfectly F.Y.I.
7 Likes
that was pretty much my logic, “more ideal”
1 Like
Technically the main camera could be named something different than Camera, and there could also be more than one Camera (used for ViewportFrames). So you should definitely always use the CurrentCamera property if you’re trying to access the camera the player is using for the game viewport.
Is it common for scripters to parent viewport cameras to workspace? I always parent them to viewport frames seems like the most logical thing to do
asking this because other guy made a similar point earlier
But it’s not required that you parent it to the VeiwportFrame. Roblox simply added a property of the workspace that allows game developers to easily find the camera the client is using. If you really want to use Workspace.Camera you can do that.
Probably not. But it’s not a matter of commonality, but rather possibility. It is possible to have name conflicts where workspace.Camera is either nil or refers to the wrong camera. Thus using CurrentCamera is definitely the way to go.
I never use workspace.Camera and never will.
I understand where your coming from
It just seems like if you know what you’re doing then there nothing wrong in using workspace.Camera, incapaz made a valid point earlier that roblox might add a property named “Camera” which would def. cause issues but probability wise that close to 0 and even if it did come to happen, scripters would get warned ahead of time similar to the mandatory filtering enabled update
In a scenario if you were working in a team with unknown scripters then I would def see the reason in using CurrentCamera since you don’t know if the other scripters will add in multiple cameras under workspace
seems like it mostly just a protection against (in my opinion) dumb mistakes
When it comes to making programming design decisions, it’s always best to choose the most robust and safe option, given that the performance and implementation differences are minuscule. In this case, it’s as easy as changing the word Camera to CurrentCamera.
I understand that either work in most situations, but it makes more sense to use the property that was added specifically to keep consistency with interfacing with the player’s camera.