Issue with .Touched script not always working?

Help and Feedback Scripting Support
#21

Okay I will try your solution and @NyrionDev 's solution. Thank you. I’ll just put one reply as the solution since so this post appears solved.

However, I’m not sure how I’ll be able to test it out without possibly losing all the players again :sweat_smile:

#22

Yeah that’s true, a pcall would be the safest scenario. But it’s probably way to expensive to run it for .Touched events by 200 checkpoints so I’ll only use it if there’s really no other option.

1 Like
#23

I’m still curious as to why in every solution but mine the debounce variable is being declared locally inside the loop.

You just end up redeclaring the same variable hundreds of times.

#24

It’s a debounce for each different checkpoint, although I wonder why the creator sets it to true for all the parts touching it(not only the characters).

#25

I don’t see any script in this thread with a problematic debounce, all of them are being set back to false regardless of what occurs in the script itself (unless it errors, in which case that wouldn’t be an issue with the debounce but the error itself).

#26

It isn’t a debounce for each stage though, think about it logically.

#27

Oh that’s simply because there’s a Debounce needed for every single checkpoint, that’s why I declared it in the loop.

#28

If you wanted a debounce for each stage you’d need to make use of a table.

#29

According to the creator it is, also there is a chance 2 different debounces have different values at a given point in time(therefore a global variable can’t be used).

#30 
for _,checkpoint in pairs(Checkpoints:GetChildren()) do --looping through all the checkpoints
	local Debounce = false --a debounce to prevent players to get the checkpoint reward twice

Remember the execution of this code is contained inside a single script, so “Debounce” is just being redeclared for however many checkpoints there are.

#31

I just set it to true asap after the event got fired. If there would be even the slightest delay, then the if Debounce == false then might be activated too many times.

#32

Also considering this is a server script multiple players will end up triggering the debounces for one another.

#33

That for loop is running when the game first begins, not when a new checkpoint is touched so redeclaring “Debounce” multiple times isn’t actually creating a unique debounce for each stage.

#34

As long it isn’t an incredible large server(let’s say 100 players) it will have no effect(at this point we are just overcomplicating the topic).

#35

Alright, and you asked about testing, can’t you test in Studio?

#36

Oh wait is that a question to me or to PAGO?

#37 
local Checkpoints = workspace:WaitForChild("Checkpoints")
local Debounce = {}
local Players = game:GetService("Players")

for _, checkpoint in ipairs(Checkpoints:GetChildren()) do
	checkpoint.Touched:Connect(function(touched)
		if touched.Parent:FindFirstChild("Humanoid") then
			local Humanoid = touched.Parent:FindFirstChild("Humanoid")
			local Character = touched.Parent
			local Player = Players:GetPlayerFromCharacter(touched.Parent)
			if Player then
				if table.find(Debounce, Player) then
					return
				end
				table.insert(Debounce, Player)
				local stageNum = tonumber(checkpoint.Name)
				local leaderstats = Player:WaitForChild("leaderstats")
				if leaderstats then
					local Stage = leaderstats:WaitForChild("Stage")
					if Stage then
						if stageNum == Stage.Value + 1 and Humanoid.Health ~= 0 then
							Stage.Value = stageNum
							Player.RespawnLocation = checkpoint
						end
					end
				end
				task.wait(0.5)
				if table.find(Debounce, Player) then
					table.remove(Debounce, table.find(Debounce, Player))
				end
			end
		end
	end)
end

Yeah, should’ve been for you, and here’s a player specific debounce.

#38

Oh yeah a player specific Debounce would be even more safe so that every player can for sure get the checkpoint. And even if for some reason one player sets the Debounce to true forever (the thing that’s been causing the bug yesterday), then it wouldn’t affect the other players. It might be a bit expensive, but at least it’s super safe ig.

About this, yes I will of course test it as much as possible in Studio. But I might not notice any problems, because the cause of this issue was that on very few occasions a player leaves the Debounce enabled forever. That’s also what happened before, and why I made this post.

1 Like
#39

So WaitForChild will not error, but will keep looking for Humanoid, even if it isn’t there, which can be a problem! FindFirstChild will return whatever you are looking for instantly, or if it doesn’t find it, it returns nil. You should use FindFirstChild on player objects (Or the descendants of the player objects) to avoid the rare instance that Humanoid wasn’t found, so the system can at least know it returned nil.

1 Like