I think you forgot to make it uncopylocked
Aside from that, this is really op. I would gatekeep something like this for myself 
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 
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. 
Today, I (re)learned something… Good-to-know functionality pitfalls, I guess.
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 (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.
After some experimenting, it’s clear that it is impossible to fix player.Character returning nil after the invisibility command is used, as the character property of the player becomes nil to clients after the player’s parent is set to nil.
In scripts where you reference the player’s character, get the character instead by doing this: workspace:FindFirstChild(player.Name, true).
1 Like