You can use FindFirstChild to properly prevent and handle these errors, that is how you should check for missing instances or instances you’re not sure will be there at all times. You do something like this with the player’s character already, it will be nil if it doesn’t exist, and you can do that where you are encountering your error too, for the player’s HumanoidRootPart.
Aside from that I also have some suggestions and info for you too that I hope you find helpful.
Generally if I were to write the code you wrote I’d write something like this (minus all the comments)
local character = player.Character
-- Then we can actually check for the character and the root part in the same line
local rootPart = character and character:FindFirstChild("HumanoidRootPart")
-- OR, with an if else expression (I usually like the latter for this stuff since it's short and still readable)
local rootPart = if character then character:FindFirstChild("HumanoidRootPart") else
-- We can check for the root part and then cancel if they don't have it
if not rootPart then return end
-- All the checks passed, so we are good to set their CFrame
rootPart.CFrame = CFrame.new(71, 27.5, -60)
table.insert(playersPlaying, player.Name) -- P.s. I might store the player themselves instead of the player's name
It is good to note by the way that nil values are falsy, so not nil is true, and it’ll act like false in conditions, and that can be nice if you want to keep your code simple.
The “if thing then return” pattern is called a guard clause I believe. I like to keep my guard clauses on one line given I am not returning anything at all (unlike most other things actually). I think it’s generally more conventional not to though, that is entirely just a preference of mine. Guard clauses can help a lot to avoid really big deep nested if statements and are nice to read, and easy to write. I often have tons of them in my code, and, it’s a really great pattern I think.
I would also suggest, rather than using FindFirstChild on the workspace, and using player names, it’s probably a lot cleaner to use player.Character, and it will be a bit more readable and a bit faster, and won’t let players with weird names (like Terrain) break your game. That’s something really good to keep in mind about using player names to find and keep track of stuff! (Player’s UserIds can often be a lot better, especially if you are storing data, because player names can change). If you already have the player (which I can assume you do judging by v.Name) you should totally use that instead. If the player doesn’t have a character you can check it easily since it’ll just be nil (and won’t throw an error since it’s a property of the player, rather than a child instance).
Generally, you would want to work with the Player instance instead of the player’s name, or getting their player by their character or character name, since you can get both from the player instance when you need them. Just some stuff to keep in mind, not that any of it is necessarily the “correct” way to do things (imo there isn’t a correct way to do anything, there are just ways with benefits and drawbacks).
