I know that I can use .Magnitude, but, I think .Magnitude can only work by directly referencing parts. Another reason is that there are going to be so many parts and referencing each one is going to be such a pain. I cannot use partsinregion because the part is moving. Here’s a quick(yet awesome) illustration:
Is there any way of doing it? The blue is the radius, the part highlighted in blue is the part that does the detection, the parts that are highlighted in yellow are the detected parts.
I would recommend using GetTouchingParts() and magnitude checking to detect those parts.
You can define the hitbox of the radius using a sphere or block, and run the GetTouchingParts() function to retrieve a table of all objects that are intersecting the hitbox.
I would suggest setting a PrimaryPart for each model, and ignore any other parts that are part of model (but not the PrimaryPart) using an if statement.
Edit: If that is not feasible due to the amount of models in your game, you could alternatively loop through all the parts found and ignore any extra parts that pertain to the same model a part was already found in.
When using GetTouchingParts(), you cannot ignore any of the parts that are touching it. What you can do is use if statements to ignore any parts that pertain to a model that was already found by another part.
local objectsFound = {}
for i, part in pairs(partToCheck:GetTouchingParts()) do
if part.Parent:IsA(“Model”) then
local foundObject = false
for i, object in pairs(objectsFound) do
if object == part.Parent then
foundObject = true
break
end
end
if not foundObject then
table.insert(objectsFound, part.Parent)
end
else
table.insert(objectsFound, part)
end
end
This example would assume that all of your models do not go deeper than 1 child (if you have parts within parts within models, you will need to check for more than just one parent up to see if it is within a model, potentially by using the IsDescendentOf() method or the FindFirstAncestorWhichIsA() method.
Edit: The objectsFound table is going to be a list of your parts found, no more than one part per model. Your blue part will be one of these, you probably want to add an if statement to ignore that part as well.
It is probably most efficient to just use all the parts found rather than eliminate repeating model’s parts considering this is going to be checked very frequently as the “blue part” moves.
Why is it important for you to only get one part per model, if you don’t mind me asking? This may help with me determining the best solution for this problem.
Suuuper sorry for the late reply. Here is the function that I use to check collisions:
Similarly to @Hazania’s reply, I use sanity checking to filter out parts. If you only want to detect a single part within a model, you can set its name to a specific name that makes it easily distinguishable in a script
local desiredpartname = "name of part you want to detect in the function"
local connection = hitbox.Touched:Connect(function() end) --just in case your parts' collisions are off
local touching = hitbox:GetTouchingParts() --gettouchingparts() will return a table of everything intersecting the part
if touching ~= nil then
for _,detected in ipairs(touching) do --I personally use ipairs to skip anything that may have become nil at the time of running the function
if detected.Name == desiredpartname then
--run function or whatever here
end
end
end
Bless you for using ipairs. I don’t think it should really be about potential nils but rather what you’re iterating over and understanding the difference between ipairs/pairs. ipairs should be used for arrays.
ipairs is designed to iterate over arrays, where the keys are numeric and incremental from 1 to the length of the table. Therefore, your iterations are occurring where your keys are known at [i+1]. It is also, compared to the old VM, significantly faster. A benchmark reading at RDC showed around 6.49 speedup.
pairs should be used in cases where you’re working with dictionaries, or otherwise where your keys are not known from the beginning and can be arbitrary. pairs calls next and gets the next element based on the last key.
Another thing: ipairs will iterate your elements in order. Order is not guaranteed nor known when it comes to pairs-based iteration. Even if you have numeric keys and you use pairs, it will not default to incremental iteration. There may be some cases where order is important!
It’s kind of a strange situation where you don’t need to connect a .Touched event, but you will have to anyways to create a Touch Interest.
Sadly, I don’t think there is another way to get one.
I would just create a .Touched event connected to the invisible part you made and let it be; it’s a waste, but it’s not going to be hampering performance.