What is the differece between FindFirstChildWhichIsA and FindFirstChild

I’m reading this article and something bothers me
article link: Collisions | Documentation - Roblox Creator Hub
The code that bothers me

local part = script.Parent
 
local function onPartTouched(otherPart)
	-- Get the other part's parent
	local partParent = otherPart.Parent
	-- Look for a humanoid in the parent
	local humanoid = partParent:FindFirstChildWhichIsA("Humanoid")
	if humanoid then
		-- Do something to the humanoid, like set its health to 0
		humanoid.Health = 0
	end
end
 
part.Touched:Connect(onPartTouched)

As you can see on line no.7 he used FindFirstChildWhichIsA(“Humanoid”)
but i always use FindFirstChild in this kind of situation i wonder what’s the difference

1 Like

:FindFirstChildWhichIsA is used to find children that are of the class specified as a parameter. For example, in your case partParent maybe a character and the code is checking if there is a child which is of type “Humanoid” inside the character.

:FindFirstChild is used to find a child that has the name specified as a parameter between the parantheses. If you used :FindFirstChild here, even a normal part named “Humanoid” could be found.

11 Likes

FindFirstChild will find anything by given name, FindFirstChild(objectName). If given object name was not found, it would return nil. FindFirstChildWhichIsA is same like FindFirstChild but the difference is it required class of object. It not required object name but required object class. Example: (BasePart, UnionOperation, DataModel, Part, NegativePart). If class object was not presented with given class object. It would return nil else return the object. (If there is multiple object with same class, it choose random.).

4 Likes

For example of using FindFirstChild:

local part = workspace:FindFirstChild(“MyPart”)

For example of using FirstFirstChildWhichIsA:

local humanoid = game.Players[“rifqizahin_devforum”].Character:FindFirstChildWhichIsA(“Humanoid”)

Wrong FindFirstChildWhichIsA method:

workspace:FindFirstChildWhichIsA(“MyPistol”)

1 Like

oh so FindFirstChildWhichIsA is looking for the type while FindFirstChild is looking for the name of the child? oh ok now i get it thanks :slight_smile:

3 Likes

They are both pretty self explanatory, FindFirstChild finds first child with a given name and FindFirstChildWhichIsA finds first child that is a given class

FindFirstChildWhichIsA find the class object type (Object Class Type). FindFirstChild will search given arguments (InstanceToSearch).

1 Like

To make a more precise response than past ones. There are 3 methods:

  • findfirstchild - finds by first object having certain name
  • findfirstchildofclass - will find first object having certain class
  • findfirstchildwhichisa - will find first object being the same class OR being it’s extension.

Now what’s the difference between findfirstchildofclass and findfirstchildwhichisa

Let’s suppose you have a Part class object in the workspace.

Part extends BasePart class (just like UnionOperation, MeshPart and other extensions)

  • Workspace:FindFirstChildOfClass(“Part”) - will find the part
  • Workspace:FindFirstChildOfClass(“BasePart”) - won’t find the part (since the class is Part and not BasePart).

BUT

  • Workspace:FindFirstChildWhichIsA(“Part”) - will find the object, because Part is a Part indeed
  • Workspace:FindFirstChildWhichIsA(“BasePart”) - will find that part too, because Part extends BasePart (so it belongs to BaseParts)

Tl;dr FindFirstChildOfClass is more strict check than FindFirstChildWhichIsA

5 Likes

But wlll it still work if i use FindFirstChild instead?

It indeed will (Humanoid in characters is usually named “Humanoid”)

BUT
That’s exactly how cheaters make themselves god if you do damage on client side - they rename humanoid name and scripts which use :FindFirstChild(“Humanoid”) simply break because Humanoid isn’t named Humanoid anymore.

That’s why you should use FindFirstChildOfClass(“Humanoid”) or FindFirstChildWhichIsA(“Humanoid”)

It’s safer if cheaters try to mess with your game or Roblox introduces some breaking change (hopefully not) :slight_smile:

4 Likes

The mistake here would probably be the developer’s decision to do damage on client side

2 Likes

oh ok so its like the same but with more security

indeed. That was just an example as I’ve seen some people doing that.

The key point is that it breaks finding humanoid in client scripts.

1 Like

And your scripts are less likely to fail when a cheater comes into your game
Yes

1 Like

thanks so much now i know how to improve my game’s security

1 Like

It is not about security, but rather safety (in the case of avoiding errors), but if there is an exploiter you should not bother increasing safety just for them. Remember that the server should never trust the client anyways

2 Likes

ok thank youuu for providing such helpful informations :slight_smile:

1 Like

Is it because client can be easily manipulated?

1 Like

Exploiters can completely manipulate the client and all its LocalScripts, yes

1 Like

Yes. In general everything on client can be changed. Even the methods like :Kick in the worst scenario. Not on the server.

1 Like