-- if you parent yourself to nil on all other clients excluding your own and the server then it isn’t going to kick u, otherwise that behavior would allow exploiters to just delete players clientside and have them kicked from the server
1 Like
Since a lot of people seem to need this hacky method to “ghost” themselves, can you implement an alternative to this functionality?
If a Regular likes this idea, can you please forward this idea in #feature-requests:engine-features?
I propose two new functions in the Players service, HidePlayer(plrName: string) and RevealPlayer(plraName: string), which as the name suggests, hides/reveals the player based on the player’s name
The HidePlayer function would make their character model invisible to all expect themselves, and delete their presence from the built in sidebar and escape menu
The RevealPlayer function would reverse what the HidePlayer function does
These two functions should be enough to satisfy developers, and if developers need more, they can implement further functionality themselves
6 Likes
-- this would make more sense as a single function, such as ToggleVisibility or even just as a field on the Player object itself
We still need a toggle-able option, default should be on instead, but reason we need this toggle-able is because of this, and i know why.
Some people prefer to delete the player from the DataModel so they can spy on their players or something, and assuming even with custom playerlist, the actual playerlist would still be there or i think
Personally, this is good fix and i dont really care tbh
you could hide your name on the leaderboard as a developer in script builders by parenting your player to nil
1 Like
If you want to parent the player to nil then how are you going to make a LocalScript inside the player would work? I just want to know.
It would be nice to implement an official way to kick players without removing their character/guis so we dont lose some of the creativity that came with the bug.
A special attribute for players that toggles their visibility on the ESC menu leaderboard would be nice, too
1 Like
Does this mean I can no longer place exploiters to nil to make them have the “Kicked due to unexpected client behaviour” message…
Why did this take 15 years to add
Hello,
I tested the issue on my side and yes it’s weird nothing work except the settings and the report menu.
So yeah, it’s a good thing to add.
As others have said, as long as this doesn’t change the behavior of locally removing or hiding other Player objects (essentially allowing a developer to hide themselves or anyone else from the playerlist), then I see no issue.
I also agree with what others have suggested about a proper built-in way to hide a player from the playerlist. Now I’m not sure that we need an Incognito Mode. But it would, at the very least, be nice to have a proper way to hide players from the client completely (preferably so exploiters also wouldn’t be able to tell the difference). It would also be nice, for that same function, to include a default behavior (perhaps globally or per-player). This way a specified user or perhaps all players join invisibly without even alerting a client that they have connected, until a method is called on the server to reveal them. Then once revealed or made hidden, it would trigger PlayerAdded/Removed events on all other clients.
The above is essentially already possible with the current behavior, all except for hiding by default (because a client would be able to detect a player joining even if they’re immediately destroyed or moved to a different location) and also making it look like the player disconnected rather than anything else.
1 Like
Any update on this? I’m using this in my anticheat, but it doesn’t seem to disconnect you yet.
Hi everyone,
Apologies but upon rollout, we noticed this change has some negative interactions with other parts of the Engine. Because of this, we’ve made the decision to roll it back and investigate the issue. We’ll work to bring this change back to you guys as soon as possible.
We know that some of you were looking forward to this change - as a workaround, please use the method Player:Kick() when you remove the Player from the DM for now. It is a bit wordier than just removing the Player object, but we’re hopeful we can fix this soon!
We will give you guys a heads up once we’re ready to roll this out again.
Thank you.
3 Likes
Surely Player:Kick() has less characters than Player:Destroy() or Player:Remove() but, oh well. Hopefully you guys will find a fix.
Wait what was wrong with using Player:Kick() in the first place?
Am I missing something?
Sorry, I was unclear. There isn’t any issue with using Player:Kick() in the first place, but I assume that some of you guys want the functionality of automatically kicking a player when the Player object is removed from the DataModel - Player:Kick() won’t automatically be called when you do player.Parent = nil or player:remove() or player:Destroy(). If you want to disconnect when any of those are called, you’ll have to hook up a listener yourself for the time being.
2 Likes
Ah I see! My bad.
I’ve always just used the Kick method to remove the player.
2 Likes
This hasn’t been still rolled back. Why is this taking a month to roll it back or has this been forgotten?
I wish we have a option to turn it off or on.
Do I need to do this to clear all connections now?
Players.PlayerRemoving:Connect(function(plr)
plr:Kick()
end)
1 Like
That’s strange, the change described in the DevForum post has been rolled back. I think it might be the case that there might be some other new feature (i.e. some new security feature) that might lead to similar behavior.