Adding Debounces to Remote Events

Help and Feedback Scripting Support
,
#1

Should I add debounces on remote events, I think it is needed as firing remote events excessively can exhaust scripts and crash your games. I’ve seen hackers make games crash by firing remote events excessively, like spamming to throw multiple grenades. It made the game lag, freezes the game, and crashes the game.

How would I add debounces when doing from the client to the server or the other way around, without the server rejecting multiple events from the client (Basically make other clients using the same tool experiencing a delay when using the tool) or the other way around.

So I here’s an example. Whenever a player clicks his/ her mouse, I used the RemoteEvent:FireServer(mouse.Target) from a local script stored in a Tool (Gun) and send the mouse.Target argument.

The server with the OnServerEvent event will listen to it and check if the mouse.Target is a character and it’s not nil. The server will then determine to damage a character or not.

So, here’s my local script stored inside a Tool, I added debounce on the client but hackers can just delete that.

(I’m also confused if we should put local script inside the StarterPlayerScripts or the StarterGui. StarterCharacterScripts obviously replicate the local script/ script inside your character. I’ve seen people storing a local script inside the StarterGui with a code for the UserInputService. But isn’t that the same thing of putting the local script inside StarterPlayerScripts?)

local RS = game:GetService("ReplicatedStorage")
local GunEvent = RS:WaitForChild("GunEvent")

local Tool = script.Parent

local Handle = Tool:WaitForChild("Handle")

local Players = game:GetService("Players")

local player = Players.LocalPlayer
local char = player.Character or player.CharacterAdded:Wait()
local humanoid = char:WaitForChild("Humanoid")

local Sound = Handle:WaitForChild("Activate")

local mouse = player:GetMouse()

local Debounce = false

Tool.Activated:Connect(function()
	if Debounce == false then
		Debounce = true
		if humanoid.Health > 0 then
			Sound.Playing = true
			Sound:Play()
			local mousePosition = mouse.Hit.Position
			local mouseTarget = mouse.Target
			GunEvent:FireServer(mousePosition, mouseTarget)
			print("RemoteEvent has been fired")
		end
		task.wait(0.1)
		Debounce = false
	end
end)

and here’s my Server Script also stored inside a Tool.

local RS = game:GetService("ReplicatedStorage")
local GunEvent = RS:WaitForChild("GunEvent")

GunEvent.OnServerEvent:Connect(function(player, mousePos, mouseTarget)
	
	local char = player.Character
	local humanoid = char:WaitForChild("Humanoid")

	if humanoid.Health > 0 then
		if mouseTarget and mouseTarget ~= nil then
			if mouseTarget.Parent and mouseTarget.Parent ~= nil then
				local EnemyHumanoid = mouseTarget.Parent:FindFirstChildOfClass("Humanoid")
				if EnemyHumanoid and EnemyHumanoid.Health > 0 then
					EnemyHumanoid.Health -= 20
				end
			end
		end
	end
end)

Can anyone help me with this issue?

#2

Just add a debounce under the OnServerEvent, instead of the local script.

#3

Anytime the server script receives the fired message, store their name in a table, then after running your code after a certain amount of time, remove their name from the table

Make your normal debounce check statement but instead of “if debounce == false” you would check if the fired player’s name is not in the table.

1 Like
#4

I mean that will just make other players that are using the Tool experiencing a delay as the Server rejects multiple events.

#5

That is true, however with my reply above you can use a table to give each individual player their own server debounce which would work just fine

#6

use a table debounce = {} and then check for debounce[player.Name] and add the player to the table with debounce[player.Name] = true remove player with debounce[player.Name] = nil

#7

Should we like add a wait for that? on the server?

#8

Yes that’s possible. If you need more help. I can once I am home.

#9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.