While this may have been marked as solved, the solution provided is overkill for what is needed and I personally wouldn’t recommend it. If there’s over 100 parts, that means you’re easily creating 100 threads. Instead, you should be setting the color in a loop, waiting for a bit, and repeating the loop again after the wait like so:
local partFolder = script.Parent
local prompt = workspace.yes.Attachment.ProximityPrompt
local function setPartsColor(newColor: Color3)
for _,descendant in partFolder:GetDescendants() do
if descendant:IsA("BasePart") then
descendant.Color = newColor
end
end
end
prompt.Triggered:Connect(function()
if prompt.Enabled then
prompt.Enabled = false
setPartsColor(Color3.fromRGB(0, 0, 0))
task.wait(5)
setPartsColor(Color3.fromRGB(255, 255, 255))
prompt.Enabled = true
end
end)
As you can see, there’s no need to use multiple threads for a simple task like this one. The setPartsColor
function goes through all the descendants of partFolder
and if the descendant is a BasePart (an abstract class that includes stuff like Part, MeshPart, WedgePart, ect.), then it’ll change the color of the part to the provided newColor
. Your original code uses BrickColor, which isn’t necessarily a bad thing, but you’re better off using a Color3 because you can use more colors. If you want to use a BrickColor still, you can do the following:
setPartsColor(BrickColor.new("Really black").Color)
With such a function, you just need to call it once to change the colors of the parts, wait a bit with task.wait, and then use it again. Coroutines are useful in certain circumstances, but this is one where they don’t need to be used. If you’re interested learning more about creating threads and whatnot, I’d recommend using the task library.
You’ll notice I’m using ProximityPrompt.Enabled
for a debounce, but it isn’t necessary for solving your problem.