The CharacterAdded event fires when a player’s character spawns (or respawns). This event fires soon after setting
Player/Character to a non-nil value or calling
Player/LoadCharacter. Note, CharacterAdded fires when the Character is assigned to the
Player, which is before the Character is parented to the
This can be used alongside the
Player/CharacterRemoving event, which fires right before a player’s character is about to be removed, typically after death. As such, both of these event can potentially fire many times as players die then respawn in a place. If you want to detect when a player joins or leaves the game, you can use the
Players/PlayerRemoving events instead.
Note that the
Humanoid and its body parts (head, torso and limbs) will exist when this event fires, but clothing items like
Pants may take a few seconds to be added to the character (connect
Instance/ChildAdded on the added character to detect these).
An instance of the character that spawned/respawned.
This code sample automatically removes
Accessory objects like hats from the
Player's character when they respawn. Warning: this includes hair, so this script may cause acute baldness.
Player/CharacterAdded|added, we wait for
RunService/Stepped to fire once (using the
wait function of events). This is so the accessory removal logic runs one frame after the character spawns. A warning can appear if you delete accessories too quickly after the player spawns, so waiting one frame will avoid that.
Respawn at Despawn Location
This code sample will cause players to respawn at the same place they died. It does this by keeping track of where the player despawned using
Player/CharacterRemoving. Note that the player’s location is saved on-despawn, not on-death. This can be problematic if the player falls off a ledge and dies due to
Workspace/FallenPartsDestroyHeight - their respawn position won’t be saved in this case.
It’s also important to note the need to “forget” the location of players who leave the game. We use
Players instead of
Players/PlayerRemoving. This is because PlayerRemoving fires before CharacterRemoving - and we need to make sure we don’t forget the player’s respawn location then immediately remember a new one (this is a memory leak; potentially many players could visit, respawn and leave). So, we use ChildRemoved on Players so the event fires after the character is removed.
Detecting Player Spawns and Despawns
This code sample demonstrates the usage of
Player/CharacterRemoving in order to detect the spawning and despawning of players’ characters. You can use this as a boilerplate script to make changes to players’ characters as they spawn, such as changing