How can I delay this Value Decrease?

Hello, I need a bit of help with a .Touched Function:

I would like the oxygen Value to gradually decrease if the player is inside of the part, however I just don’t know what to do to slow down the script, I guess? What I have so far is below:

Brick1.Touched:Connect(function(plr)
	local Player = game:GetService("Players"):GetPlayerFromCharacter(plr.Parent)
	if Player then
		local Value = Player:FindFirstChild("OxygenLeft")
		Value.Value -= 10
		wait(1)
	end
end)

I would like it so every 1 or however many seconds the value looses 10, however it’s just constantly decreasing the value, if that makes sense, I believe this is because of all the R15 Parts touching the part, but I could be mistaken.

Thanks, Arid.

is the part a cube or rectangular prism?

Just a cube, sorry.
It’s a Part, inside a Folder, inside another folder, in the workplace.

That’s exactly it. Part.Touched runs for each part that touches it, so with R15… you get the idea.

So, there are multiple ways to go about this to make it ‘slower’; you could add a debounce/a cooldown using waits and coroutines, or maybe store the player’s name in a table to check if they’ve already had their value drained, etc. There’s a bunch of different options available.

the problem is touched doesn’t run if you don’t move, you need a more efficient method

Sorry, I’m not so great at ServerSided Scripting, could you give me an example, or explain what to do and why? Thanks!

I believe this topic can help you. It explains debounce and has some examples.

Ohh, I missed the part where it was supposed to be overtime, my bad lol.
In that case, another possible option is to periodically check the magnitude between the player and the part, and drain the value when the distance between the player and part is low.

I think magnitude works best when it comes to spheres

this is a cube so it’s a bit more different

lol ive never heard of magnitude being less accurate with cubes, is there a source i can read more on that?

magnitude looks for the distance between two things, and that makes it cover a sphere perfectly when detecting distance

I’m assuming you want everyone who is in the part to get their oxygen decreased. So, you should do a while wait() loop and :GetTouchingParts() along with a table of got players for an extra measure of not getting them multiple times.

while wait(1) do
	local touchingparts = Brick1:GetTouchingParts()
	local gotplayers = {}
	for i,v in pairs(touchingparts) do
		local player = game.Players:GetPlayerFromCharacter(player)
		if player and not gotplayers[player] then
			gotplayers[player] = true
			player.OxygenLeft.Value -= 10
		end
	end
end
1 Like

if its firing more than once for one player, it may be the multiple bodyparts are touching the block
find and put the player inside of a table and check if theyre there before inserting again

local playerTable = {}

local block = whatever

block.Touched:Connect(function(Touched)
if not table.find(playerTable,Touched.Parent) then --might want to check if human too, depends on your situation
table.insert(playerTable,Touched.Parent)
--Whatever here
end
end)

i didnt test this, so you might want to check if everything is correct

That’s not how magnitude works though.
When using magnitude to find the distance between two parts, all it is doing is simply subtracting Vector3 position between each other and returning the length of the vector between them, or the distance. A part’s shape does not affect it’s Position value.

If you want to test, I definitely recommend going in studio and just printing out the magnitude between two parts, then change the shapes of whichever you like after each print; you might notice that the printed distance between them doesn’t change at all. The length of a vector doesn’t change when a part has a different shape, as their position in the world is not affected by shape.

This solution is pretty ideal for OP’s original goal. @AridOats, did this work out for you?

and right there is where you misunderstood me, kinda wish I could draw a picture for you but I’m on my phone :confused:

1 Like

You really need to disconnect functions rather than not letting them run because that’s 1 listener running infinitely causing memory usage.

Then why is it a code in the first place? If it works, then it works. You should use it when it can be supportive.

Performance over quantity. If it works it doesn’t mean it is going to be good for a game. Bad practice not taking account of performance. Code is there because you’re suppose to utilise it yourself.

I wasn’t trying to disagree with you because you do have a good point after all. But what I was trying to say was that when you can use the code, you should. What I was trying not to say was you should use the code for everything. I only use it for trap parts in games because it won’t really do much that way.