Invisibility Command (Remove Player from Playerlist)

Have you ever wanted to play your own game in a public server without being recognised? You could use an invisibility command from a free admin module, but that would make your character invisible to everyone - including you, and besides, players will be able to see you in the leaderboard.

What if you could completely hide your player and character from other players? Well, it’s completely possible to do so through some client-sided shenanigans (changing the parent of the target player and their character on every client except for the target themselves)! Here in this uncopylocked place is a TextChatCommand that will make you invisible to other players: Invisibility (Command is /ToggleInvisibility) - Roblox.

To toggle invisibility, simply use the /ToggleInvisibility command. You will be able to see yourself on your screen, but to every other player, it appears as though you have left the game. Once you disable your invisibility, it will be like you rejoined, and your position will update on everyone elses’ client as soon as you move after disabling your invisibility. See this video for an example of how it works!

To import this invisibility command into your game, paste these instances into your game:


Make sure to parent them to the exact instances they are parented to in the invisibility command place!

If you want to restrict the use of the invisibility command to members of a group who have a high rank, go into the InvisibilityHandler Serverscript and the InvisibilityIndicator Localscript and uncomment the ‘if (Plr:GetRankInGroup(–[[Insert a group ID here if you want to check if the player has a rank in the group]]) >= 254 --[[Rank ID]]) then’ lines, and set the group ID as well as the rank’s index.

Have fun being a ghost!

24 Likes

I think you forgot to make it uncopylocked
{D124A3A8-292B-40AD-9F40-C830EB5FAF50}
Aside from that, this is really op. I would gatekeep something like this for myself :sob:

2 Likes

This is really cool! Will 100% be using this!

2 Likes

Sorry about that, I indeed forgot to uncopylock it. It should be fixed now!

4 Likes

I’ve been experimenting with this, it’s cool but the character seems to be put into a permanently being removed state on the client :confused:

1 Like

Yeah, the same thing that happens to TimeFrenzied also happens to me. I’ve also tried to toy a bit with it to put it into something like HD admin but I think I’m too dumb and kept messing it up lol
But overall it’s an insanely cool concept. Specially for popular horror games, for devs to mess with their players like LSplash did with Kreekcraft in Doors

it’s strange, other scripts can still pick up player.character now so it seems fine

a funny issue is that it calls playerremoving and probably playeradded on that client

I think another event call denoting the changed status of the player should fix this. Though this will not address the underlying problem of server-client security…

My main worry about this utility is that it simply hides the “invisible-tagged” players’ characters in the ReplicatedStorage for every client. It isn’t hard to write a client-sided utility to delete the running LocalScripts and re-add the player models (I simply tried this in Studio, though there is potential for competitive vulnerability here). I feel like it would be safer to delete the invisible players’ models from every client other than the one whose character is invisible. Then, replicate the server-sided player model (from the server) as another remote is fired to change an invisibility status.

I feel like this could also be improved as some players can downright delete the invisibility handler before it performs any actions as it is client-sided, but I haven’t looked into any better solutions.

1 Like

When you destroy a script don’t connections still work? I thought I read that somewhere but if not that’s unfortunate.

Here’s a random post of a few that I found on the topic–sadly, the connections won’t continue upon script deletion here:

However, I do remember something about certain parts of Roblox code running upon script deletion, but I can’t remember all instances of this phenomenon. It’s been a while for me. :tongue:

Today, I (re)learned something… Good-to-know functionality pitfalls, I guess.

1 Like

:thinking:

1 Like

There is a way to unhide the player from the playerlist after hiding the player without rejoining.
Simply use :Remove() instead of :Destroy() as it does not lock its parent
Then reparent the player instance back to the Players service when you want to unhide him.
Your welcome

1 Like

According to the documentation, setting the parent to nil is the correct way to temporarily remove objects. Actually, Instance:Remove() does the same exact thing but is deprecated.

Does your solution prevent the issue of playerremoved being called?

Instance:Remove() is a deprecated function, which is why it’s not documented.

It’s the same as setting Instance.Parent = nil, so it doesn’t disconnect any connections that might exist unlike Instance:Destroy().

You cannot parent a player instance to nil, it throws an error, hence why I suggest to use :Remove().

Probably not. Even then this wont really matter since, only the client is parenting the player to nil. The only thing this would affect is leaderboards and custom ones, which is good since it achieves the effect of hiding the player from then.

Excuse me what

where is this information coming from, i dont get any errors

Remove just parents the object to nil lol

1 Like

This invisibility script should only affect clients, not the server.

1 Like

yes, but a quirk of it is that it breaks player.Character on the client :thinking: (use cases: replication systems, etc.)

I was wondering if there was any way to circumvent this, although I assume it would be in the post if someone knew.

You are correct, the character cannot be referenced at all by the client even when they are visible again. A potential fix could be to create an ObjectValue in the Player that references their character, but this will not fix Player.Character returning nil. Unfortunately, this is the price to be paid for doing things with the Player instance that were never meant to be done.

Actually, thinking about it twice, it may be possible to fix this by reparenting the contents of the player’s character instead of the actual model instance, leaving their character as an empty model in the workspace. I’ll look into it and see if it works.

1 Like

truee

I mean you can always use the workaround that the invis script does, but it still requires updating all client scripts that reference it.