for _, player in Players:GetPlayers() do
if not player.Character then continue end
player.Character.Humanoid.DisplayDistanceType = Enum.HumanoidDisplayDistanceType.None
player.CharacterAdded:Connect(function(character: Model)
character.Humanoid.DisplayDistanceType = Enum.HumanoidDisplayDistanceType.None
end)
end
Players.PlayerAdded:Connect(function(player: Player)
player.CharacterAdded:Connect(function(character: Model)
print("Printing children")
for _, child in character:GetChildren() do
print(child.Name)
end
print("=================")
self:disable(character.Humanoid)
end)
end)
We don’t have Head, we don’t have Humanoid and other parts.
Is this on the client or server?
I believe the guarantee is only true for the server, but the documentation could certainly clarify that to avoid confusion.
Sure you can do that but that’s not the point, the point is the behavior of characteradded doesn’t follow documentation (plus making this change makes it easier obviously)
Sorry to come back to this somewhat old thread, I have a question.
Would it be safe for me to do so? I imagine calling WaitForChild on character in this case could be dangerous, no? If the humanoid or head never loads (eg, because the player left immediately after the CharacterAdded call), wouldn’t the code be stuck waiting for humanoid or head forever, taking up server memory?
You can use :WaitForChild() with a second timeout parameter to avoid that or you can create some other workaround.
But we are talking not about server in this case. On the server if CharacterAdded was fired, it’s guaranteed that you will have Humanoid and other parts of character such as Head and so on. The problem you are talking about appears only on client.
Thanks for the report, we will add clarification to the documentation that the guarantee of all parts being loaded when the signal fires is only true on the server. The client receives them later through replication, like any other Part instantiated on the server.
