Just tested it: I can still get studio camera and be in nil without having the server shutdown.
There is one thing I want to clear up here: some of you make it sound as if changing game mechanics is the save all. Let me give you a hint: itâs not
Itâs not as easy as counting 1, 2, 3 ⌠POOF! AND WEâRE FIXED! Its not always as simple as throwing a couple if then lines around. Designing mechanics to be nonexploitable can be difficult and time consuming, and we donât have an unlimited life span here. Sure, weâre talking a few years at most here ⌠But a few years is still quite a lot of time. Why do you think weâve developed shortcut methods? Cause we donât have all the time in the world. We have jobs, families, social engagements, fixing our cars, doctors appointments, seeing that special someone, aka life. And again, a few years at tops could be all you need! But unless creating games IS YOUR JOB (which for some it is, for most itâs not), then we simply donât always have time to write 5000 lines of code just to prevent someone from rapidly clicking that mouse button.. Yes, itâs a somewhat exaggerated example (why would it take 5k lines to fix a problem like that?!), but its still a very time consuming process. Thatâs one of my major points I seem to have missed on developing in op, and I apologize.
Source: first hand experience. I work 40 hour night shifts at Amazon, then have loads of stuff to do during my three days off such as laundry and bills . Leaving me about a days worth of development time
EDIT: another point I thought of. A possible counter to my argument is âwell, you shouldnt be working on a game/game of that scale thenâ. No, you should! Even if its a one time thing, itâs an experience to see your game flourish despite flaws! Just because you canât design perfect mechanics shouldnt stop you from enjoying your game, and you should have tools to control your game.
You could definitely work on your presentation
3 Likes
Bolding and italicizing so much will make each one less meaningful and more distracting
1 Like
I admit Iâm not the best writer or presenter! 
However, respectfully, I ask we stay on topic for the sake of the topic. I am open to criticism, and will take any feedback youâd like to share over a Direct Message at any time.
1 Like
After looking through this thread, Iâm mostly surprised that Roblox still allows you to reparent Player objects. Not to mention that they can get aorund Kick() by doing so.
1 Like
I believe there is not much they can do to prevent the reparenting of the Player as the Player Instance is created on the Client, then replicated to the Server. The same somewhat applies to the NetworkReplicator class, however there is the difference between a ServerReplicator and a ClientReplicator (biggest being ServerReplicator canât be touched by Client 
). In regards to the :Kick() improvement, if they would unlock ServerReplicator:CloseConnection(), and keep Player:Kick() for compatibility, it should be impossible to evade being kicked. Maybe I should make a separate Bug Report thread for this, but I chose not to cause itâs also a feature request.
If I am a server and a player parents themselves to nil locally, kicking them will not work? (What about with FE on/off)
Regardless of the state of FE, isnât the issue of someoneâs Player instance magically disappearing from Players on the server yet still requesting info/updates both easy to detect and easy to solve (by disconnecting them)? Last time I checked, getting rid of your Player disconnected you already (try game.Players[yourName]:Remove() in the console and youâll get booted), so the fear of exploiters doing this might just be paranoia of past events.
If it was that simple, I wouldnt be requestinh these features. There are such admin cmand scripts called ânil adminsâ ran on the Client. Yes, on a FilteringEnabled game, what they can do is very limited. However, they can still spectate and fly around, which can be an unfair advantage you canât exactly deal with easily if they disable LocalScripts on their client. And with Windows 10, is easy to have two clients running (UWP and Win32 apps).
EDIT: I should also mention this is the reason why we had Player:Kick(string reason) implemented. However, itâs an incomplete function, as it does not deal with nil Players
I was referring to detection on ROBLOXâs end and ROBLOX terminating the playerâs connection â not you doing it manually. Also, do you have any concrete confirmation this is still an issue (not âI think I heard about someone doing thisâ), or are you just assuming it is? Because as I mentioned in my last post, setting the playerâs parent to nil with player:Remove() disconnects them.
Can confirm it is still a problem, as tested in ScriptBuilder + Studio
EDIT (sorry on mobile so I keep forgetting things): donât forget that the Player instance is created and owned by the client. What we see in ServerSide Players is a replicated LocalPlayer instance from the Client. The Client can do whatever it wants to the LocalPlayer, and have most of the properties replicate regardless of Filtering (iirc, testing soontm)
ScriptBuilder in Studio or ScriptBuilder and Studio?
Reproduction steps?
Studio and ScriptBuilder. Repo steps will be edited into this post when back on PC
Verified issue in-game. It looks like itâs only the developer console that disconnects players when theyâre removed. We had a discussion about how the server trusts the client and therefor the client can remove the Kick method from the player, or remove the player itself, meaning Kick wouldnât work in either of those cases. Both OP and I agreed that itâs pointless to have Kick if it doesnât work 100% of the time. OPâs suggestion was deprecation of Kick and unlocking ServerReplicator since ServerReplicator.CloseConnection doesnât ask the clientâs permission to disconnect them, but I disagree.
Iâm not a fan of unlocking ServerReplicator because exposing ports and packets seems beyond the scope of ROBLOX. IMO Kick should be a front for ServerReplicator.CloseConnection, and then thereâs no longer an issue of clients ignoring Kick requests. To deal with clients who modify themselves unexpectedly, the server should just stop trusting them less and disconnect them automatically if it detects anything weird (the Player instance not existing, not being where it should be, etc) Now Kick works 100% of the time because if itâs for some reason not available, the client has already been automatically disconnected.
As for which of the two, if either, is the right solution, thatâs something ROBLOX can decide.
Small correction:
The server doesnât ask the client to disconnect iirc, but forces them to close when using Player:Kick(). However, once Players.PlayerRemoving fires, Player:kick() loses the ability to kick the player. As to why? No clue.
Hmm, this seems a bit odd.
In a FE game, setting the parent to nil should be rejected. For a non-FE game, it should also be ignored as there is code to only accept Players as the parent for a Player.
For non-studio, there is also code that should block new-instances/properties/deletions/etc⌠when the ServerReplicator doesnât have a player.
Are you saying that Kick doesnât work from LocalScripts, or that it doesnât work from scripts on the server?
IServerSide. As soon as Player.Parent = nil, Player:Kick() does nothing. However, the reason I ask for a method to close it verse patch is because there is a use for game devs/moderators who are watching over a game. If they have permission to go ânilâ, they can moderate games from a spectator standpoint, and no one would ever know theyâre in there. Thatâs ⌠Another one of my reasons at least
It seems like it would be better to have a property on player to have them hidden.
1 Like
Actually, that seems like the better way to go. Then the server would still know the player exists and remote events/functions would work correctly.