I’m proposing the creation of a new character class to replace humanoids.
Currently if you need to do something like, say, check if a player dies you need to reference their character and then wait for the humanoid to appear, and to check if a model is a character you need to check for a humanoid. It all just seems annoying for something that should be simple.
A container that holds all character related parts and information, such as all current Humanoid properties and functions, I believe would be better than using humanoids. Instead of player.Character:WaitForChild(“Humanoid”).Died you would just do player.Character.Died. Instead of checking if a model has a humanoid, you would be able to just do “model:IsA(‘Character’)”. It was always strange to me that player characters are just models with a humanoid when we have dedicated classes for pretty much everything else.
I believe a dedicated character container would just be logical.
It would be creatable for use with game NPCs, same as humanoids are now. I would also expect humanoids to stick around but just be deprecated, for legacy support, or people who really like humanoids for whatever reasons they may have.
I couldn’t really think of a reason not to implement something like this. Legacy Humanoids tend to be tricky and hacky to work with and can be annoying at best and game breaking in worst case scenarios.
This should honestly serve as a better replacement for the current Humanoid system in both usability (no having to wait, player.Character contains all the needed functions) and performance (not having to check IsA('Model') and then FindFirstChild('Humanoid').
As for how it’s implemented it could also free us to do things like Character:ClearAllChildren() to rebuild characters without clearing out the Humanoid and having to hook a new one.
Also humanoids currently, to my knowledge, need to be in a model to work anyway, so why not just skip all that entirely and instead of a humanoid with a model just have the “Character” container.
It would be nice if ROBLOX’s character hierarchy had been set up with the Humanoid as the character:
but regardless of what better ways we find to organize characters now, I think it’s too late to change them at this point. Anything we do has to be backwards-compatible, and that’d be difficult with a change like this.
True. They could always do some magic with the character object to make it return itself if something tries to index “Humanoid” from it, or just leave humanoids for now in addition to the new container just for legacy support. I believe we shouldn’t shy away from doing what makes sense. Sometimes things seem good at the time, and become too ingrained to fully remove or change, I know, but that isn’t a reason to forever stick with something old and outdated.
The two suggested ways of changing them are awful and definitely don’t makes sense.
Redirecting Humanoids:
Roblox developers may implement hacks like this in their games, but it’s not scalable to an entire platform. Eventually they stack up, and then it’s either exponentially harder or even impossible to implement similar changes in the future when we need to have multiple layers of features redirecting themselves.
Coexistence:
This is almost the same as redirecting humanoids. We’d be replicating every single modification of a Humanoid to the character. This is a bad idea for the same reason redirection is.
If we were going to update characters/humanoids, it would have to follow a similar process to what we did with R6/R15 (a missed chance), where games support specific avatar types. We may have another chance with vertex deformation characters as that would be another change on the same scale R6->R15, but other than that I don’t think Roblox would ever look into this for such a weak use case as "I don’t like using character:WaitForChild("Humanoid")"
Structurally speaking, I find it completely logical for physical characters to be Models containing a Humanoid that controls the behaviour of the parent Model (which is then recognised as a character with certain requirements).
Sure, it may look easier in some cases, but I don’t see the implementation of your suggestion granting any advantages in terms of flexibility in development. In fact, I don’t see it changing anything at all.
The "I don’t like using character:WaitForChild("Humanoid")" reason is not the only reason for this argument; performance comes into play when you’re iterating over workspace and doing hacky checks.
Inconveniences come into play when Humanoid doesn’t load in at all (in cases where the character is created just as a player leaves and the thread is kept pending for who knows how long).
And lastly, convenience comes into play when you now have 1 instance to handle the function of a Model with a Humanoid so you no longer need to keep track of 2 instances when trying to do things such as removing parts from said model without touching a Humanoid (example, ClearAllChildren) and not running into the issues like the character dying and the Humanoid going with it.
As for how to implement? We already have booleans for loading character appearances in properties (forgot which service) so it wouldn’t be hard at all to just make players spawning with it a property, too.
Just like we pushed for FilteringEnabled, a boolean based game feature which could break legacy games if enabled, we can push for Character objects, a boolean based game feature which could break legacy games if enabled.
I like the idea of having an optional setting for whether or not to use it for players. Would also still be usable going forward for newly created NPCs.
Humanoids are sketchy at best so I think most people support an overhaul of them.
I don’t really think a character object is necessary. A character is still a collection of parts in both cases so it might as well still be a model. In many game engines characters are implemented in similar ways.
Suggesting a boolean setting is generally a red flag that a feature request is bad. They can be useful for absolute necessities (usually security-related), but otherwise they’re typically requested as a get-out-of-jail-free card where we just want something changed and don’t care about the lasting consequences.
The other use cases you’ve provided don’t seem very convincing either, and likely signify a need for better design on the developer’s part instead of any real concern with Humanoids.
Infinite yield for Humanoid on player leave
This will never happen. The humanoid is already present when CharacterAdded fires, and hierarchy is preserved when the character is removed, so any scripts attempting to access the humanoid after the player leaves and the character is removed will still find it. Repro code:
game.Players.PlayerAdded:connect(function(player)
local character = player.CharacterAdded:wait()
print("Humanoid on CharacterAdded", character.Humanoid)
player:Kick()
wait(10)
print("Humanoid after character removed", character.Humanoid)
end)
Results:
19:19:32.316 - Player -1 added
Humanoid on CharacterAdded Humanoid
19:19:33.428 - Player -1 leaving
Humanoid after character removed Humanoid
Performance
Repro or it’s premature optimization. That’s how all performance improvement requests work. I can already tell you that indexing humanoids for every NPC in your game is not going to cause performance problems.
Convenience
As far as we know, needing to dynamically swap entire characters except their humanoid for some reason is just bad design. This can’t hold up as a use case for a feature request unless you provide sufficient reasoning for why this approach is necessary.
Booleans aren’t a red flag; they’re used all over the place for things that can very well potentially break game mechanics if toggled.
The following are examples of this (although maybe one or two are less breaking and more user preference):
As for the yield I’ve experienced it before and usually when a player has a visibly bad network, and if it wasn’t a thing we wouldn’t need to do methods such as Character:WaitForChild('Humanoid'), it isn’t leave alone exclusive, but I will try to somehow 100% repro it if I can.
Performance-wise, when you’re doing things such as aoe in magic games (for say, quick magic bullet streams as an example) it tends to take a toll in script performance, and especially so when you have a larger number of players.
Lastly, convenience, I can’t possibly see how it is bad design when it’s making the life of development more comfortable. It’s an all-in-one model if you wish. As @AbstractAlex did mention we could always have Humanoids be used as characters.
This, however, brings me to my next problem. A ROBLOX bug actually. Humanoid seems to treat Workspace as a valid model parent.
