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