I noticed in the post Hiding players from player list and the solution isn’t exactly right, if you do what the solution says you will get an error telling you something like
"(player name) parent has been changed to NULL, returned to Players"
Well my friends, I have a found a solution! And it’s not that different!
game:GetService("RunService").RenderStepped:Connect(function()--every frame
local players = game.Players:GetChildren()--get every player in the game
for i = 1,#players do--do something for all players
players[i]:Destroy()--Delete players
end
end)
So if you just read that and left, thinking that was all you needed to know, there’s a chance you might’ve got the error again when putting this into say, the StarterPack. This is because the backpack takes time to load.
So, here’s what you gotta do,
Step 1: Create a local script inside of the ReplicatedFirst this will allow it to load before anything else except core stuff like the CoreGui (Still can’t crack a way to get into it! Pesky CoreGui injectors! I’ll get you one day!)
Step 2: Put the code into the local script. This code will now launch instantly after the core stuff is done loading.
Step 3: Enjoy! Keep in mind, this is only destroying the player on the CLIENT! Not the server.
Alright, so now we’re done with that. But now we’ve got new problems. Most of the core stuff just stopped working! This is because it is trying to access the player, but you destroyed the player!
So how do you fix this? Well, you can’t. You gotta start over and rewrite your own custom stuff, like a custom character or custom chat, etc. You can recover some of the stuff by destroying all players except the local player.
if player[i] and player[i].Name ~= game.Players.LocalPlayer.Name then
So now you know how to do it, but now you might be wondering,
"But Kotojokes, that looks like a lot of work you silly goose! What’s the benefits?"
Fear not my friend, I, Kotojokes, will use bullet points.
Benefits:
-
Stops “logging” in your game! Say a really strong player joins your RPG game, he’s known for beating up players. Well, by not having this system, a player can simply check the player’s list, and if he sees someone dangerous, he just hops to a different server. This can be game breaking because people will intentionally search for the easiest servers!
-
Makes games harder to exploit! It doesn’t make it impossible, but exploiters will assume that they can access a “player” so they execute a script under that assumption and get an error. This can detour some exploiters! But remember, it takes a very clever developer, to defeat a very clever exploiter. All games are different.
-
Makes the game more spooky and unknown! Especially if you’re using Universes and players can’t see the amount of players, if you have some RPG with a huge map, anyone could be around! Maybe the server is empty, maybe the server is full, maybe you’re safe, maybe you’re not… Expect the unexpected!
Downsides:
-
Remaking systems like chatting can be a drag and take forever! By using this, you’re practically doubling the development time needed to make a game!
-
Unknown population can make the game feel empty! If players don’t know if anyone is playing with them, it can feel as though the game is empty and doesn’t have many players. The player will have no idea if there’s 20 players online, or 0!
-
Performance can be hurt. You are searching and destroying players every single frame, let’s say your game is running at 60 frames per second, that’s running that code 3600 times a minute! That’s a lot of search and destroy! Not to mention this looks “hacky” and unprofessional!
Also, please do give credit if you decide to use this!
I took a good bit of time trying to discover this!
Good luck and happy scripting!
Thanks for reading!!!