.CharacterAdded event fires when character isn't a child of workspace

According to the wiki, the CharacterAdded event fires when the character is added to workspace, however the actual behavior contradicts this.

Wiki

The following demonstrates current behavior:

game:GetService("Players").PlayerAdded:Connect(function(Player)
	
	print(Player.Parent)
	
	Player.CharacterAdded:Connect(function(Character)
		
		print(Character.Parent)
		
	end)
	
end)
Result


The current behavior could prove troublesome for developers who are specifically relying on .CharacterAdded being fired only after the character is a descendant of workspace. Whether or not it is good practice to do this could be debated, however that is a different subject altogether.

Edit: whoops wrong category, fixed.

6 Likes

I think the overarching bug is that Roblox fires the signal a frame too early. If you want to instantly place the character on spawn you have to wait() otherwise Roblox will ignore it, the same follows for the parent.

It should only fire when the task is complete.

5 Likes

I really hope this isn’t a bug, and that the wiki is describing it wrong. As it is right now, when I try to modify non-R15 characters, the way to do it is very hacky and results in death sometimes unless you disable the dead state of the humanoid. The reason I really don’t like doing that is because you have to tell the client to do the same locally before modifying the character.

To explain why this is relevant to discussion here, using CharacterAdded I’m able to modify characters before they make their way into workspace, and have never experienced them dying from doing so. If we keep the current behavior, then we continue to have that window of opportunity open. For me personally, I don’t have any published projects which would suffer from changing it to the behavior described in the wiki. However, there could be people not realizing the current behavior is necessary to not break their code, and changing it now would break things.

I don’t know how long the behavior hasn’t matched the wiki, but I’ve had code that modifies character appearance before they enter the workspace since 2015 (at least I assume they haven’t entered the workspace, since the characters never died like they do when changing joints later).

If the behavior has been the way it is now for years (like I assume it has), I would really argue to not change it now. It’s not worth breaking existing code, and with the current behavior it is possible to wait for the character to enter the workspace.

As said in my post, I’m making assumptions on how long the current behavior has been around based on my character modifying, which to me seems to work flawlessly because they aren’t in the workspace yet when it happens. I could be wrong, and engineers at Roblox would definitely know more. Just figured explaining what I did felt worth it.

1 Like

A valid point, however the exact opposite could also be said about people not realising that the wiki is incorrect.

Before submitting this bug I too was unsure whether the behavior documented on the wiki was correct or not, however judging from the behavior of the PlayerAdded event I figured it’d make sense if it was the same for CharacterAded.

1 Like

It definitely makes sense, and it wouldn’t bother me personally if it would change to match what it says on the wiki since it wouldn’t break anything meaningful for me. I’m worried about it breaking existing code, though for my case of modifying characters it isn’t a big deal. The solution there would be to deprecate the new method under the humanoid for swapping out R15 parts, and instead replace it with a more flexible function which isn’t limited to just R15.

Really hope this issue gets cleared up one way or another. Wiki descriptions of behavior not matching engine behavior was always annoying when trying to start out scripting on Roblox.

2 Likes