I will count it as a vital bug, because it’s pretty logical that players need to have a player instance to communicate with the server while Lua scripts identify player actions and such.
There are fellow devs who managed to join a game session without provoking .PlayerAdded server-side (or :Kick() doesn’t work after the player object is gone missing) and managed to perform exploits.
My anti-exploit is very efficient at catching exploiters with “custom filtering”, but it just can’t work if the client-side part of this system doesn’t work and if clients who are missing in the “Players” instance can’t be kicked with a script or disconnected automatically.
You can kick players without a Player object, because I’ve seen admin commands that kick non-existent players. This can really be considered a workaround instead of a solution, though.
Don’t rely on the client for catching exploiters. It’s a bad idea because the client is what they exploit through.
“but it just can’t work if the client-side part of this system doesn’t work”
Not to say that I support your chosen solution to the problem (Really… it would probably be less work to just convert the game to Filtering), but that said: The solution would be to use a LocalScript in ReplacatedFirst when that feature comes out. Those scripts run at pretty much the earliest point possible during the startup process, and aren’t parented under the player, so they should be pretty hard to circumvent.
[quote] “but it just can’t work if the client-side part of this system doesn’t work”
Not to say that I support your chosen solution to the problem (Really… it would probably be less work to just convert the game to Filtering), but that said: The solution would be to use a LocalScript in ReplacatedFirst when that feature comes out. Those scripts run at pretty much the earliest point possible during the startup process, and aren’t parented under the player, so they should be pretty hard to circumvent. [/quote]
Is there any date we can expect for the release of ReplicatedFirst?