Killer damage HUD (replacing menu)

[nullsystem]

Description

• Replace the menu-based killer/damage info with HUD
• Right-side, generally gives slight more killer/damage info than menu
• Keybind toggle
• Pagination
• Convar+settings on how it pops up/interacts (cl_neo_kdinfo_toggletype)

Toolchain

• Linux GCC Distro Native Gentoo/GCC 14.3.0

Linked Issues

• fixes [FEATURE] Replace killer/damage info menu with a proper UI #667

[Rainyan]

Would it be possible for us to completely cut/not render the killfeed for the pixels overlapping the KID panel? Or if that's unreasonably much effort (not too familiar with the UI details), perhaps having the KID panel bg take full (or fuller) alpha opacity, and rendering the killfeed under it, so that it doesn't distract the reading as much at areas where the two overlap.

Another possible option would be to make it such that:

• If the Killer Info panel is open
• And if there's a killfeed item that would overlap with it
• Expire any upper killfeed items for as long as it takes to resolve the overlap

in which case we could dodge this problem. But I'm not sure which is the best approach.

And I guess another option would be to simply move the panel way more to the left, such that it will not overlap no matter what carnage is happening in the killfeed. Maybe this would be cleaner actually?

---

It's also a bit complicated to understand since it's quite busy visually, and many elements/info is packed very close together, but that could maybe be a thing to improve in the future for some visual design/UX pass, instead of getting too fixated on it for this PR.

---

One thing I might like to see changed is the Killed by: <weapon> language, since we have two of them appearing at the same time:

• Killed by <Player name>
• Killed by: <Weapon name>

which makes it a bit hard to read, since they're so similar.

Maybe it'd be better to have:

• Killed by <Player name>
• Weapon: <weapon name>

[nullsystem]

@Rainyan I've decided to just move it to the left, don't have to deal with killfeed overlap at least. Also changed wording Killed by: <Weapon name> -> Weapon: <Weapon name>

[AdamTadeusz]

Would it be possible for us to completely cut/not render the killfeed for the pixels overlapping the KID panel? Or if that's unreasonably much effort (not too familiar with the UI details), perhaps having the KID panel bg take full (or fuller) alpha opacity, and rendering the killfeed under it, so that it doesn't distract the reading as much at areas where the two overlap.

Another possible option would be to make it such that:

* If the Killer Info panel is open

* And if there's a killfeed item that would overlap with it

* Expire any upper killfeed items for as long as it takes to resolve the overlap

in which case we could dodge this problem. But I'm not sure which is the best approach.

And I guess another option would be to simply move the panel way more to the left, such that it will not overlap no matter what carnage is happening in the killfeed. Maybe this would be cleaner actually?

It's also a bit complicated to understand since it's quite busy visually, and many elements/info is packed very close together, but that could maybe be a thing to improve in the future for some visual design/UX pass, instead of getting too fixated on it for this PR.

One thing I might like to see changed is the Killed by: <weapon> language, since we have two of them appearing at the same time:

* `Killed by <Player name>`

* `Killed by: <Weapon name>`

which makes it a bit hard to read, since they're so similar.

Maybe it'd be better to have:

* `Killed by <Player name>`

* `Weapon: <weapon name>`

A few extra pixels of space between each player in the report would be nice

[nullsystem]

@AdamTadeusz Added some extra spacing

[AdamTadeusz]

Any chance we could include damage from the environment and neo_npc_targetdummy (Jeff)?

[sunzenshen]

LGTM. Damage from Jeff isn't counted (blank results if you only took damage from non-player entities), but I think that kind of detail is optional. Otherwise results look good.

[nullsystem]

@AdamTadeusz @sunzenshen Will look at it separately: #1275