local region = Region3.new(Vector3.new(5,0,5),Vector3.new(15,15,15))
local part = Instance.new("Part")
part.Anchored = true
part.Size = region.Size
part.Parent = game.Workspace
part.CanCollide = false
part.Orientation = Vector3.new(0,0,0)
spawn(function()
RunService.Heartbeat:Connect(function()
local partsInRegion = workspace:FindPartsInRegion3(region,part,math.huge)
for i, part in pairs(partsInRegion) do
print(part.Parent.Name)
if part.Parent:FindFirstChild("Humanoid") ~= nil then
print("FOUND!")
end
end
end)
end)
I think it could be name confliction? You named the 2nd return of pairs as part, and you also have a variable named part, try changing the name of one of them and see if that does anything?
Even if parts share the name, it seems like detection works, and the code block gives locally defined parts the priority. I feel like the issue is with region positioning. It might actually work, but your character in fact doesn’t touch it. Region seems to be somewhere in the ground, inside baseplate.
The following is an easier approach to create region3 based on a part. We use its position and its size to determine corners of newly created region.
local RunService = game:GetService("RunService")
local region, part; do
part = Instance.new("Part")
part.Anchored = true
part.CanCollide = false
part.Parent = workspace
part.Position = Vector3.new(0,5,0)
local position, half_size = part.Position, part.Size *.5
region = Region3.new((position - half_size), (position + half_size))
end
local connection = RunService.Heartbeat:Connect(function()
local partsInRegion = workspace:FindPartsInRegion3(region, part, 1000)
for _, object in pairs(partsInRegion) do
if (object.Parent:FindFirstChild("Humanoid")) then print("Found!") end
end
end)
Just a quick tip: you don’t have to use spawn() to run a RunService.Heartbeat loop. spawn() runs at 30Hz and yields the thread.The best alternative to spawn() is coroutine.wrap(). Rather use coroutines in a newer work.
EDIT @Water_KKnight I tested it and your region is in the ground yet working. Rather use the above approach.
Then it’s likely that the region is not properly detecting anything, I think if you follow along what @EssenceExplorer stated, it should work as I think something is up with how you set up the Region
That is correct, neither the use of spawn nor coroutine.wrap() or coroutine.resume(coroutine.create()) (slowest to fastest call) yield the current thread. Call time is no longer than a few micro seconds.
What I meant with yielding is the delay in start of the newely created thread. Because of the way Roblox manages threads, the resume budget, and the way spawn is built, there is apparently no guarantee when the newely created thread is going to execute. In the best case scenario, it will resume the second frame after it’s called, which is very unlikely. I’ve even had some problems with spawn personally.
Coroutines are currently the best alternative.
To keep this reply brief, I’m appending two important links with further explanations of why spawn, delay and wait() (letter without time parameter) should not be used in any work that is supposed to meet certain efficiency and up-to-date standards.
I am well aware of how Roblox task scheduler works. The first link is what explains it thoroughly, but again, spawn resuming just after 2 frames is normal, not something rare unless there are too many threads needed to be resumed in the queue or due to low frame rate.
What you have mentioned comes with a few citations which I think don’t need to mentioned since you would probably know assuming you have already read those 2 links.
@EssenceExplorer, I’ve noticed you pinging multiple times in a single reply when replying to me, you do realize that the person is notified already?
That is true, albeit relative. Once a person starts working on a bigger, perhaps more complex game/project, spawn should without doubt be replaced with coroutines. I’ve personally worked on a larger game, and sometimes kept detecting visible delays (not as critical as described in the topics I pasted above) until we replaced spawn with coroutines, which improved the situation significantly. spawn() really no longer has place in the newer code. Sure, there won’t be any serious delays with a couple of spawns, but still, why use any if there is a better alternative associated with better practice?
It’s like using wait() without time parameter in while-loops. Code won’t be too negatively affected, but when there are multiple loops running in the game, negative impact may start to harm experience of your players.
Event based waiting and coroutines seem to be the answer.
Yes, please excuse me for that, I’ve intended to ping you only once as part of reply without you getting the notification, because even though anyone can read it, the post was meant to address you.
That is true, albeit relative. Once a person starts working on a bigger, perhaps more complex game, spawn should without doubt be replaced with coroutines . I’ve personally worked on a larger game, and kept detecting visible delays (not as critical as described in the topics I pasted above) until we replaced spawn with coroutines, which improved the situation significantly. spawn() really no longer has place in the newer code
That’s correct, you’re on the right track. What I mean was for smaller scale projects where there isn’t really any need to replace, though definitely they should be once you start working on a big project. Of course larger games would result in 30hz operations start throttling a bit.
Sure, there won’t be any serious delays with a couple of spawns, but still, why use any if there is a better alternative associated with better practice?
The better alternative should be used, definitely. Though my point is that there isn’t really any need for it if you’re working on a smaller scale project where such optimization isn’t even needed in the first place, it’s like switching wait to Heartbeat:Wait when there wouldn’t really any be differences at all (small scale). Sure, coroutine is definitely more reliable, but that reliability will only be noticed once you start working on larger scale games where there is a lot going around.
You’ve made a few good points. We can discuss more in discord if you would like to pursue discussion.
