You can write your topic however you want, but you need to answer these questions:
What do you want to achieve? Keep it simple and clear!
I want to detect the parts touching the grey transparent part (except my character)
What is the issue? Include screenshots / videos if possible!
Problem is that I detect nothing, so when I put a touched event on the test grey part, nothing is firing, not even the spawn location, and everything has the CanTouch on, here is a video where I try to touch the spawn location with the grey test part, but nothing is firing :
What solutions have you tried so far? Did you look for solutions on the Creator Hub?
Yes, I tried to see on the devforum however I didnt find something that could helps me, HOWEVER I did try to make the grey test part unanchored and it worked, but like when its anchored its not working so I dont really understand why?
local RunService = game:GetService("RunService")
local Player = game.Players.LocalPlayer
local TestPart = Instance.new("Part")
TestPart.Parent = workspace
TestPart.CanCollide = false
TestPart.Anchored = true
TestPart.CanTouch = true
TestPart.Transparency = 0.5
TestPart.Size = Vector3.new(10,10,10)
TestPart.Name = "TestPart"
Player.CharacterAdded:Wait()
RunService.Heartbeat:Connect(function()
TestPart.Position = Player.Character.HumanoidRootPart.Position
end)
TestPart.Touched:Connect(function(Hit)
if Hit.Parent:FindFirstChild("Humanoid") then return end
if Hit.Name == "Handle" then return end
print(Hit)
end)
local RunService = game:GetService("RunService")
local Player = game.Players.LocalPlayer
local TestPart = Instance.new("Part")
TestPart.Parent = workspace
TestPart.CanCollide = false
TestPart.Anchored = true
TestPart.CanTouch = true
TestPart.Transparency = 0.5
TestPart.Size = Vector3.new(10,10,10)
TestPart.Name = "TestPart"
Player.CharacterAdded:Wait()
RunService.Heartbeat:Connect(function()
TestPart.Position = Player.Character.HumanoidRootPart.Position
local Touching = workspace:GetPartsInPart(TestPart)
for _, Hit in Touching do
if Hit.Parent:FindFirstChild("Humanoid") then return end
if Hit.Name == "Handle" then return end
print(Hit)
end
end)
Actually, it might be that .Touched only fires with physics collisions.
Each :GetPartsInPart() call takes approximately 0.002 milliseconds or 2 microseconds. I don’t think you’re gonna notice that. In fact it takes ~50000x longer to blink than it takes to call GetPartsInPart()
Great advice.
10/10
Amazing performance.
I guess you may notice a performance hit when running at ~500,000 FPS (actual number).
Did you forget that your game will be running during it?
Any tight loop, especially the ones bound to every frame execution, HAS to be as optimized as possible.
It’s not data you can compile once and keep performance for the rest of the game.
Also, you keep the rest of your CPU cores unutilized, which is a huge shame and lost opportunity.
TL;DR keep using .Touched.
0.2 Seconds is a very insane waste for only 100K loops.
Thanks, however, I used Touched event for a specific reason, so I can like know if the part touched it once, and then it left the touch with touch ended, for example, when the grey part touch the spawn location it fires, and while spawnlocation is inside the grey part it doesnt fire, and then if I use a touch ended, it fires when the spawnlocation is not anymore inside the grey part, I dont know if you see what do I mean.
But I think I can figure a way to make some kind of a touched event with workspace:GetPartsInPart… but the problem is why its not working with touched, like why is it “unreliable”?
I think of Part’s NetworkOwnership is not client.
Client will not receive physics events because of that or other reasons
Any part (server-side) that is Anchored is true (on server-sidely) will force NetworkOwnership to nil (Server).
use Motor6D, it connects Part0 to Part1
And you don’t need to use Anchored or Run a loop (in order to position to Player.Character) since this exists (same goes to Weld but it’s behavior different from Motor6D)
No… you can’t just check once, you have to check every frame to make sure that something is being touched.
This is almost as optimized as possible and a totally fine alternative to .Touched.
Running this in parallel would be more inefficient than just running this serialized since you would have to split something that probably takes less than a 5 microseconds between multiple threads.
Ok, but the issue in the first place was that .Touched wasn’t working. I agree that using .Touched is the best method but if it doesn’t work then I would use :GetPartsInPart() as an alternative.
Yes, that would be insane waste… except that we only have to run that a single time and 2 microseconds is an extremely short amount of time. If we were going to run it 100k times I wouldn’t recommend my method.
You could use a simple checking method:
local PreviousTouching = {}
local function Touched(Hit)
if Hit.Parent:FindFirstChild("Humanoid") then return end
if Hit.Name == "Handle" then return end
print(Hit)
end
local function TouchEnded(Hit)
end
RunService.Heartbeat:Connect(function()
TestPart.Position = Player.Character.HumanoidRootPart.Position
local Touching = workspace:GetPartsInPart(TestPart)
for _, Hit in Touching do -- This controls touch starting objects
local WasPreviouslyTouched = table.find(PreviousTouching, Hit) ~= nil
if WasPreviouslyTouched then return end -- Only continue if the object wasn't already detected
Touched(Hit)
end
for _, OldHit in PreviouslyTouching() do -- This controls touch ending objects
local StillTouching = table.find(Touching, OldHit) ~= nil
if StillTouching then return end -- Only continue if the object isn't being touched anymore
TouchEnded(Hit)
end
PreviousTouching = Touching
end)
Now you basically have .Touched and .TouchEnded available to you except they use :GetPartsInPart() under the hood. This isn’t a perfectly optimized script but I’m sure it will suit your needs.
I know parallel is pretty good for some things but you can’t use it for everything. There’s no reason to split between multiple threads (I think you may have mixed up cores and threads, cores are the physical thing on the CPU, threads are what code is split up into) for simple tasks especially for editing parts since you are required to edit parts in serial anyways.
There is major overhead with parallel lua. This isn’t a raytracer, no point in spreading out work in a pretty serial task anyways. How would you even spread out this task to several cores anyway?
200ms isn’t exactly a good thing, as more optimized approaches can take a couple microseconds, so it’s definitely not a performant alternative .
Unless absolutely necessary to run constantly, I’d suggest setting a timing limitations such as 1/15 or 1/10 seconds rather than having it run a constant 1/60 seconds as it becomes very expensive to run alongside other processes, so cutting down on these areas would be most beneficial without needing to compromise in other areas.
Nope, it’s not a misinterpretation, just general advice.
All the test does is to measure and compare the amount of time it takes. If it only needs to be run once, there is no need for it to be run every 60 steps in a heartbeat Event as either:
It’s a waste of resources to have constant checks, in which it can be limited
You can create a listener to check and run the condition once, which is far more performant
In games, performance is everything.
Query functions will vary in performance depending on how many objects are found within it’s bounds, which more complex logic is required (such as the previous mentioned timing limitations) in Order to allow better scalability to it’s uses.
And as an extra note, a recommendation is to use : Getpartboundsinbox() where can also use OverlapParams blacklist feature to help with filtering out objects
It does need to be run every frame to check for newly touching parts, the entire point of this was to either fix the .Touched function or to present an alternative. I don’t know how to fix the .Touched issue but I know that you can use :GetPartsInPart().
I know that performance matters a lot but we’re talking about a maximum of around 100 microseconds on a single thread. OP is using only 1 of these checks so I doubt this will matter much at all.
Yes, this will be an issue if you use this method for a huge part but I think just checking a couple parts around the player really doesn’t matter too much.
:GetPartsInPart() also has the OverlapParams feature. I know that your method will be more performant by a bit but I think ease of use is more important (maybe OP wants to change the detection part to be a cylinder or something).
I know that my method isn’t great but I don’t see any alternatives. If you have a better method, then you should post it here so OP can use that instead :)
