As a Roblox developer, the current ordering of avatar loading events makes no guarantees when you would otherwise expect them, such as the visitor’s character and its related components being loaded when CharacterAdded fires. If you want to code character scripts the right way you have to go through great lengths to avoid memory leaks as well (see RbxCharacterSounds AtomicBinding as well as the legacy code which the AtomicBinding module replaces).
If Roblox were to address this issue, it would improve my development experience because I can continue to handle characters via the CharacterAdded event as I do any other event with an absolute guarantee that the character will exist, be constructed and parented when it fires and without introducing unnecessary complexity to solve for issues like memory leaks, characters being deparented before the full avatar loading pipeline completes and animation loading issues.
The update was postponed due to technical challenges however in 157 days (as of this thread’s creation) we will be coming up on the 4th year since the announcement’s release with zero word on progress towards fixing this critical part of avatar development. Announcement available here. I have made noise at minimum one time every year on feature requests and discussions related to avatars including a number of requests for updates when the announcement thread was open. With focus to avatars becoming increasingly apparent, I would like to see this issue fixed.
Tacking onto this, the unreliability/lack of thorough of avatar loading events makes it incredibly difficult to work around default engine behavior (see: Allow developers to modify the default spawn system - #3 by https_KingPie about the annoying difficulties on making adjustments to spawning [which necessarily requires waiting on the initial parent to DataModel] and how cumbersome it is with existing tools) in a succinct and efficient way. It should not be this difficult to efficiently build onto an aspect that nearly all experiences share: the basic loading-in of the avatar/character.
Honestly, I would consider this more of a bug now that I see what’s the actual issue:
Eventually, they claim “that the Humanoid and its default body parts (head, torso, and limbs) will exist when this event fires”. This isn’t true for the client, however; noting that the event triggers just when the property Player.Character is not nil anymore instead of it when is fully loaded. I believe the issue of this happening is because of replication, but this behavior is so bad and contradicts completely their documentation that they need to make a patch for it.
The code that prints the output in the picture is shown:
Server Code:(Script under ServerScriptService)
game.Players.PlayerAdded:Connect(function(Player)
Player.CharacterAdded:Connect(function(Character)
print(Player.Character, Character:GetChildren()) --> GetChildren returns all the stuff.
end)
end)
Client Code:(LocalScript under PlayersScripts)
local Player = game.Players.LocalPlayer
Player.CharacterAdded:Connect(function(Character)
print(Player.Character, Character:GetChildren()) --> GetChildren returns an empty table.
end)
They should indeed add an event however named Spawned which triggers when everything is totally loaded and the character can be safely used. Both client and server, if they don’t wish to change the behavior of the current events.
Keeping up the tradition of making noise about this feature on a yearly basis. I still at the very least want atomic loading on character models since there were technical challenges with even just rearranging the ordering of avatar loading events. I’ve had to create this system myself on numerous occasions to guarantee the initial character subtree but I still want to see this addressed natively. It is very easy to run into character race conditions and memory leaks with current ordering and not easy to make a consistent utility that works out of the box with every project and style (this meaning: the concepts remain the same across the board but not the implementation).
