New Humanoid Functions

Hello, everyone.

I’m here to propose an idea that would help speed up development and would make it less confusing for developers.

Here is my idea:

Deprecate or do no changes to the Humanoid.HealthChanged function that can be fired when called.

Add in new functions that would be Humanoid.HealthDamaged(amount) and Humanoid.HealthHealed(amount). These would fire upon health being taken away or added, respectfully.

I do know you can script these in already, but this method would be much easier.

Use case?

You can find the difference in health by the method on the wiki (keep currentHealth up to date, and change it each health change after calculating difference)

https://wiki.roblox.com/index.php?title=API:Class/Humanoid/HealthChanged

3 Likes

The two functions would replace the need to add in extra variables and such to code, and would overall make it cleaner.

API bloat ~= cleaner*

I don’t have a health healed vs damaged in my own games, if I am healing it’s -damage in Humanoid:TakeDamage for example

4 Likes

True, but this would be for something along the lines of say, for example, pain noises being played when your health is damaged, but a different sound plays when you are healed.

1 Like

As TheAmazeman said, these aren’t really needed and would just be a bloat.

You can easily detect if health was lost or gained:

local OldHealth = Humanoid.Health

Humanoid.HealthChanged:Connect(function(NewHealth)
    local Damaged = (OldHealth - NewHealth) > 0
    local Difference = math.abs(OldHealth - NewHealth)

    if Damaged then
        print("A player lost " ..Difference.. " health!")
    end

    OldHealth = NewHealth
end)

In my opinion the only change that could be useful would be adding a ‘difference’ argument to the HealthChanged signal - then you wouldn’t need to track OldHealth and could see if the difference was negative or positive.

1 Like

That’s more or less what I’m aiming for to be honest, but I’m entirely sure how that would be implemented [ the difference argument. ]

Why not?

It’d be far more practical than deprecating a useful signal and adding two more niche signals.

1 Like

You can either account for that by doing the wiki method, using currentHealth > health for pain and currentHealth < health for healing. Or you can play the sound on the event that causes the health difference in the first place.

1 Like

It could be implemented, but I’m not sure how it could be - not saying it’s a bad idea or anything.

@TheAmazeman

All three of those sound good.

Just thought my idea might make things a bit easier.

Leave that to the engineers, they made Roblox after all.

3 Likes