HUD component visibility state handling

[HeresHavi]

Summary

Updated isPlayerHudComponentVisible to report whether a HUD component can actually be drawn, including the global showhud state and fullscreen map suppression.

Radar child components now follow the parent radar state without losing their own visibility settings.

Motivation

Previously, isPlayerHudComponentVisible only checked the state of the requested component. This meant the radar could be hidden by showhud while the function still returned true.

The fullscreen player map also used the same global HUD state. Closing the map could re-enable a HUD that the player had already hidden with showhud.

For example, a resource might display a custom minimap only while the GTA radar is hidden. If the API incorrectly reports that the radar is still visible, the resource cannot reliably decide when to show its replacement.

Fixes #5026.

Test plan

Runtime

• Before Fix: Running showhud hid the radar, but isPlayerHudComponentVisible("radar") still returned true.
• After Fix: The function returned false while the HUD was hidden and returned true after restoring it.
• Valid Case: Hiding the radar directly, toggling showhud, and restoring the HUD kept the radar hidden until it was explicitly restored.
• Player Map: Opening the fullscreen map temporarily hid the HUD without replacing the state requested through showhud.
• Radar Children: radar_map, radar_blips, and radar_altimeter followed the parent radar state while keeping their own visibility settings.
• Reset: Reconnecting restored the global HUD and component visibility defaults.

Builds and Tests

• Debug | Win32: Client build passed.
• Release | Win32: Client build passed.
• Client tests: 304 tests passed.
• Ran clang-format.

Checklist

• Your code should follow the coding guidelines.
• Smaller pull requests are easier to review. If your pull request is beefy, your pull request should be reviewable commit-by-commit.

[FileEX]

What makes this PR better than #5027 ?

[HeresHavi]

@FileEX Apologies, this PR was meant to stay as a draft because I wasn’t done finalizing it yet. I’ve prioritized it and pushed the remaining changes so it doesn’t become stale

I've incorporated your suggestions and made some further improvements to how HUD visibility is handled. Compared with the other PR, I think this approach is more complete because it fixes the underlying issue while preserving the existing behavior for scripts. It also keeps the requested HUD state separate from temporary suppression and effective visibility, which avoids changing the meaning of the existing API

[FileEX]

At the moment, your PR replicates the behavior of #5027, including adding a new argument to the function 👀

[HeresHavi]

At the moment, your PR replicates the behavior of #5027, including adding a new argument to the function 👀

I compared it with mine just now, and at this point they provide essentially the same API and behavior. Though mine is somewhat smaller and avoids the suppression enum, bitset, and additional state methods, but that is an implementation trade off rather than a clear advantage over #5027. I don't think the remaining differences are enough to justify using my PR.

There are still a couple of smaller implementation details from this PR that may be useful there such as:

• HUD component visibility state handling #5028 uses std::memcmp / Fix HUD visibility API and showhud/player map state conflicts #5027 uses unqualified memcmp
• HUD component visibility state handling #5028 uses reinterpret_cast for the HUD byte pointers / Fix HUD visibility API and showhud/player map state conflicts #5027 uses C style pointer casts
• HUD component visibility state handling #5028 uses brace initialization such as parent{HUD_ALL} and m_isAppliedDisabled{false} / Fix HUD visibility API and showhud/player map state conflicts #5027 uses parent = HUD_ALL and m_isAppliedDisabled = false

Basically your PR suggestions.

You can close this one in favor of #5027, I don't mind it!

[FileEX]

Closing in favor of #5027