Your immediate problem can be fixed by removing damager from the FireServer call -- the LocalPlayer is already given to the server script by Roblox, so if you send it again, the server ends up with the first two parameters being the same.
Next, your server script isn't finding the player to damage correctly. FindFirstChild takes in a name, not an instance - a simple fix is to have damaged.Name instead of damaged on that line.
A potentially big problem is one that you won't run into unless your game attracts exploiters. The rule with RemoteEvents is to assume that someone will have complete scriptual access to every RemoteEvent you make (ie they can trigger any RemoteEvent/RemoteFunction with any arguments they want, as many times as they want). ex, imagine that an exploiter ran this script in your place (which they could do):
01 | local dmg = game.ReplicatedStorage.RemoteEvents.Damage |
04 | for _, player in ipairs(game.Players:GetPlayers()) do |
05 | if player ~= game.Players.LocalPlayer then |
06 | dmg:FireServer(player, 1000000) |
09 | dmg:FireServer(game.Players.LocalPlayer, -100000) |
Everyone is now being constantly killed except the exploiter (who is continually healing himself) and your server would be happily accepting these commands! Things to do:
- The server should know the damage level; it doesn't need the client to tell it. You should be able to look up the weapon that the player is currently using and how much damage it is supposed to do.
- Ideally, make sure that the player is at least near the person they are theoretically damaging. Also make sure that players aren't teleporting around too much (an exploiter should be able to do this with ease).
- Consider keeping track of weapon cooldowns so that an exploiter can't attack more frequently than you want them to.
Do note that just because a player has requested to attack while on cooldown, that doesn't prove that they're an exploiter (even if you have code in the LocalScripts to respect cooldown as well) -- lag can play a part. Similarly, the server may see characters appear to "teleport" short distances legitimately if the client had a lag-spike.
0
