Instance:Destroy() or game.Debris:AddItem

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 ="WeldConstraint", hrp)
	local hitbox ="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 +,offset.Y)
	hitbox.Parent = character
		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

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


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

	game.Debris:AddItem(hitbox, linger)

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. :smile:

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():

1 Like

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!

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.

  1. 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

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

  1. 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.

  1. Slightly more advanced option addressing point 3

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

1 Like

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. :wave:

1 Like

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