Instance:Destroy() or game.Debris:AddItem

[alexisbabyq (Prata)]

Hey! I was following a certain tutorial and script. I wanted to make an ability for my PVP fighting game.
I was just wondering the following question:

function newHitbox(character, size, offset, damage, linger, kb)
	local hrp = character:FindFirstChild("HumanoidRootPart")
	if hrp == nil then return end
	local weld = Instance.new("WeldConstraint", hrp)
	local hitbox = Instance.new("Part")
	
	weld.Part0 = hrp
	weld.Part1 = hitbox

	hitbox.Transparency = 1
	hitbox.CanCollide = false
	hitbox.CanQuery = false
	hitbox.Massless = true

	hitbox.Size = size
	hitbox.CFrame = hrp.CFrame + hrp.CFrame.LookVector * offset.X + Vector3.new(0,offset.Y)
	hitbox.Parent = character
	
	hitbox.Touched:Connect(function(hit)
		if hit.Parent:FindFirstChild("Humanoid") == nil then return end

		for _, v in pairs(hitbox:GetChildren()) do
			if v:IsA("ObjectValue") then
				if v.Value == hit.Parent then return end
			end
		end

		local hitCounter = Instance.new("ObjectValue", hitbox)
		hitCounter.Value = hit.Parent

		hit.Parent.Humanoid:TakeDamage(damage)

		if kb <= 0 then return end
		knockback(hit.Parent, character, kb)
	end)

	game.Debris:AddItem(hitbox, linger)
end

In the last lines, I was wondering if I should use Instance:Destroy() or game.Debris:AddItem. Just so game.Debris:AddItem doesn’t lag out my game a lot if players use it alot.

[icy_oasis]

As far as I know Debris still relies on wait() instead of task.wait(). I’d go for Instance:Destroy(), combined with task.defer() or task.delay() if need be.

Why wait() is inferior to task.wait():

Coroutines V.S. Spawn()... Which one should I use?

EDIT (2020-08-12): This post gets a lot of attention. If you want to learn more, you can read this brief article. Please do not use spawn. It’s a hold-over from Roblox’s 30hz pipeline and has no guarantees about when (or if) it will begin executing the new thread. spawn is especially evil because it seems innocent at first, but once you have a lot of code that all uses spawn, you can see significant delays in execution upwards of several seconds in a resource-intensive game. Roblox throttles e…

[alexisbabyq (Prata)]

Hmm, I see, altough when I use Instance:Destroy this is what happens: firstly, it requires yielding the code with a wait, which is not always desirable. Secondly, before the 3 seconds have elapsed the object may have already been destroyed (for example, if it reached Workspace.FallenPartsDestroyHeight).

And I don’t really wanna use a yield, which can cause infinite yield that I am specifically ABSOLUTELY TERRIBLE at trying to solve this type of issue.

Is there any other way to destroy/delete a part without having the risk of causing any errors (you get the point) and no wait point.
My excuses if it is a bit hard!

[icy_oasis]

I understand your concerns. Let’s address them more in depth.

1. The uncertainty of indefinite yield

An indefinite yield is improbable because no section of the code is designed to yield indefinitely.

2. Yielding of the main thread

Debris was created long before the task library with the purpose of disposing of an object after a specified period of time without yielding the calling thread. Internally, it still utilizes wait().

As highlighted in evaera’s article, it’s a good idea to avoid wait, spawn and delay in any new work, and consequently Debris (unless it has been updated without my knowledge, which I highly doubt).

In a nutshell, the article explains how these functions can quickly exhaust the resume budget in the task scheduler, leading to potential inconsistencies and delays, particularly as their use increases. Your calling environment will be just fine, but the more waits there are, the lower the guarantee that an object in Debris will in fact get destroyed after a given period of time and not with additional delays, be it .06 seconds or 1 second or more.

I strongly suggest using the task library.

local DELAY_TIME = 5
task.delay(DELAY_TIME, function()
    if Instance then
        Instance:Destroy()
    end
end)

The code snippet does the same job as Debris:AddItem(5, Instance).

3. What if the instance is destroyed before the code runs?

This concern is also addressed in the provided snippet, where the if-statement verifies the instance’s existence before calling Destroy. As the matter of fact, attempting to destroy the same object multiple times won’t raise an error.

---

---

4. Slightly more advanced option addressing point 3

• Promises

• Promise implementation, at its finest , also by evaera

• Great explanation by B Ricey on Youtube

There is no one limited way to use promises. They are very versatile and can be chained, passed into one another, cancelled, immediately resolved…

[alexisbabyq (Prata)]

Oh, now I get it, thanks for making in further more details and explaining me more about these diferences. I’ll use Instance:Destroy().

I appreciate your help.