I’ve said the output two times it says the packet won’t process. Whatever that means.
Try remove plr:Kick("You have been banned by ".. player ..". If you have a problem with this talk to a SHR.") and see if it works. It is probably a problem on why pocket cannot be successfully sent.
Okay, I’ll see if it works.
Hi there, here’s some help with the topic:
For your client script I suggest to check whether “player” is nil or not and ignore the call otherwise or else when the nil gets to the “print(player)” it will supposedly error out your script and not fire the ban event in the first place.
RemoteEvents fire server-side with the first value being the Client (player) that fired it, if it’s not intentional I suggest removing “placeholder” as an argument and making sure that victim and plr are not equal to nil as well.
And here are some suggestions that I can make to improve your scripts as a whole:
Client
-
Avoid teleporting/destroying parts locally for specifically an admin script or you may wind up encountering bugs such as people not actually dying when you destroy their head or not actually teleporting on their screen, or your anti-exploit (if you hopefully have one in this case) kicking people because they are teleporting around locally which is indicative of an exploiter in some cases outside of ping/lag.
-
Do not kick other users on the client script, it does not work as “When used from a LocalScript, only the local player’s client can be kicked.” (Player | Documentation - Roblox Creator Hub)
Server
-
Update the name and value of the StringValue you’re making before parenting it, out of good practice in cases where a script checks when ChildAdded is fired.
-
If you are banning someone only on that server you can just add the player’s name to a table and check to see if someone is in that table when they join, rather than taking some extra effort from the server-side in such a case that it doesn’t work (i.e. in this one).
-
Sanity check the ban event firing, checking whether the client (Player) is actually an admin or not or else you may wind up in a sticky situation if an exploiter finds that they can fire it as they please. As a rule of thumb with remote events receiving traffic from the client, never trust they’ll do the right thing and you’ll be fine as far as security is concerned.
In General
- It’s easier to debug your code when everything is properly indented and whitespace consistently (and hopefully not overly so), so I definitely suggest saving yourself and others a headache.
And sorry for the long response, I just hope that some of it at minimum helped! 
The server is unable to process the packet sent via the RemoteEvent because the client which sent it doesn’t exist.
Ignoring everything else, you can comment out line 29 of your localscript or yield (a remotefunction can be used in this case) until the server completes the task before line 29 and the stringvalue will be created successfully.
I highly recommend you re-think what you’re trying to achieve, which appears to be some form of administrative tool. As it stands, you’re throwing around arbitrary variables and you’re relying on the server instructing the client on what to do (changes you make on the client won’t replicate). It’s also possible for the client to ban any user due to there being no server-sided validation by simply running the following code:
game:GetService("ReplicatedStorage").GuiRemoteEvents.Banning:FireServer("{VictimHere}", "{AdministratorHere}")
I’d recommend listening on the server, validating the user has permission to execute the command and then executing the command on the server. “pseudocode”:
local Admins = {}
local function isAdmin(Player)
for _, id in pairs(Admins) do
if id == Player.UserId then
return true
end
end
return false
end
game:GetService("ReplicatedStorage").RemoteEvent.OnServerEvent:Connect(function(Player, Command, Victim)
if isAdmin(Player) then
-- if command == x, do y
end
end)
from the client…
game:GetService("ReplicatedStorage"):WaitForChild("RemoteEvent"):FireServer("Ban", game:GetService("Players").{Victim})
I’d also like to note that you shouldn’t send the localplayer as an argument using :FireServer, since the LocalPlayer is already passed automatically to the server and will always be the first argument. This cannot be manipulated, unlike sending the localplayers name to validate it’s identity as an argument.
2 Likes