Halflife: Remove the 255 cap from the Health HUD

Created on 20 Apr 2019  ·  24Comments  ·  Source: ValveSoftware/halflife

Title. If you have more than > 255 HP your HUD wont display more than that value.

Feature Request

Most helpful comment

I think the safest way to handle this is just to add a health2 message as described and deprecate the health message, to ensure the HUD always has an up to date value for such an important field and to make the least amount of breaking changes possible.

At least where it doesn’t create a significant amount of otherwise unnecessary work, given the long history and community support for all of the Half-Life games, I’d always rather err on the side of not breaking things that our players may rely on regardless of what they are.

Sent with GitHawk

All 24 comments

This is because the network message Health (global gmsgHealth) sends the value as a byte. Sending it as a short should allow for much larger health values, but would require changes to be made to any third party plugins that intercept the message (i.e. AMXMod).

I think' there must be unsigned int.

It would be very nice.

@shelru maybe unsigned short int?
If you plan to increase the size of the Account - then you need to reduce $100,000 -> $100k. Or use nickname abbreviation (as examble AAAAAAAAAAAAAAAAAAAA...) in ShowScores
image

It can also break backward compatibility with old clients that are used in no-steam versions of the game, which can cause an outflow of players, since there are no proper ways to change Health. It may be worth creating a new message Health2, in which the int32 value of health will be transmitted. This will not create problems.

Split radar from the HUD HP and AP would not be superfluous to be able to hide the radar separately (via amxx plugin).

To be fair no steam versions shouldn't be supported, to begin with.

However, I still agree that the safest bet would be creating a new "health2"

It can also break backward compatibility with old clients that are used in no-steam versions of the game, which can cause an outflow of players, since there are no proper ways to change Health. It may be worth creating a new message Health2, in which the int32 value of health will be transmitted. This will not create problems.

This message exists in game code, so if you're using a server dll that has this you should also be using a client dll that matches it. Plus, as @Uiharu said, no-Steam is not supported by Valve and should not be considered in any decisions.

If open sourcing is possible then no-Steam as it exists now will no longer matter anyway.

+1, non-steam shouldn't be supp.

@SamVanheer,

The presence of non-existent user messages on the client is optional. The callback list is initialized in the client library, which calls HookServerMsg function, which sets a callback for each message. If message is not set by client library, the message will remain uninitialized, but it will not affect the client. Due to this, the work of the current protocol is not violated if we use the Health2 solution.

Although no-steam should not be supported by official GoldSrc developers (with which I, in general, agree), but server online in the gaming community also has value, since most players prefer no-steam instead of steam. Changing the protocol can cause some excitement in the community. That's why I think this should also be taken into account when working on updates.

У него никнейм с r на конце.
Anyway we can check user client version by sv_info, rigth? With amxmod'x, before sending msg via message_begin.

@SamVanheer,

The presence of non-existent user messages on the client is optional. The callback list is initialized in the client library, which calls HookServerMsg function, which sets a callback for each message. If message is not set by client library, the message will remain uninitialized, but it will not affect the client. Due to this, the work of the current protocol is not violated if we use the Health2 solution.

Although no-steam should not be supported by official GoldSrc developers (with which I, in general, agree), but server online in the gaming community also has value, since most players prefer no-steam instead of steam. Changing the protocol can cause some excitement in the community. That's why I think this should also be taken into account when working on updates.

I agree with the Health2 solution for Half-Life itself on account of mods that only have a custom server dll requiring backwards compatibility, but other games don't need it.

There is only one Counter-Strike, TFC, etc so if you're running the wrong client dll for one of those then you need to update, regardless of whether you're running a Steam or no-Steam version.
No-Steam, WON2, Xash, etc are all in violation of the EULA so Valve need not provide any support for those.

I hope that the engine and the games will be open sourced, providing a legal path to making versions of these games that do not require Steam auth. That should be the only way to play them that is in any way "No-Steam".

@wopox1337 они чего, серьезно вынесли деньги в таб?
А что еще из графики обновили?
@2010kohtep

@shelru,
Не знаю, не смотрел. mikela сказал, что проблема текстур временная и будет исправлена: #2148

The client already knows the actual value of health from health field of clientdata_t. I think we can just use it. By default it is encoded with 10 bits (values from -512 to 511 IIRC), but it can be changed in delta.lst.

True, but networked fields may be changed to the wrong value if the client simulates an old frame, so the HUD may change values for single frames. This should be tested before being added.

@kisak-valve can you add a Feature Request to this please?

I think the safest way to handle this is just to add a health2 message as described and deprecate the health message, to ensure the HUD always has an up to date value for such an important field and to make the least amount of breaking changes possible.

At least where it doesn’t create a significant amount of otherwise unnecessary work, given the long history and community support for all of the Half-Life games, I’d always rather err on the side of not breaking things that our players may rely on regardless of what they are.

Sent with GitHawk

Alfred was fired from GoldSrc dev. team?

Does this fix covers the Armor hud too?

CS GO is free, why CS 1.6 not?

@mikela-valve We gonna receive this on Half-Life and others? Pretty much all Goldsource games has this.

Split radar from the HUD HP and AP would not be superfluous to be able to hide the radar separately (via amxx plugin).

You can create anothe issue. I haven't seen any related to this yet.

With this cap removal, it could be also removed the display cap of:

  • armor (currently 999);
  • round time (currently 546:00);
  • money (currently 999999);
  • ammo/clip (currently 255).

Basically, all countable things that are displayed in the HUD.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

WhiteFang1319 picture WhiteFang1319  ·  3Comments

perforatorRU picture perforatorRU  ·  3Comments

magister4813 picture magister4813  ·  3Comments

twisterniq picture twisterniq  ·  4Comments

perforatorRU picture perforatorRU  ·  3Comments