vscript vgui HUD visibility control

[samisalreadytaken]

I think this might be the best way to handle HUD visibility; this wasn't part of the main PR because I just hadn't thought about this issue for many months.

Global hidehud bits set the visibility of multiple elements at once, which is not ideal at all. For example with the existing custom HUDs (CSGO and TF2) using the previous method, there is no item pickup icons, no zoom or damage indicators.

This allows individual management of every HUD element listed below

CAchievementNotificationPanel
CHUDAutoAim
CHUDQuickInfo
CHudAmmo
CHudAnimationInfo
CHudBattery
CHudChat
CHudCloseCaption
CHudCommentary
CHudCredits
CHudCrosshair
CHudDamageIndicator
CHudDeathNotice
CHudFilmDemo
CHudFlashlight
CHudGeiger
CHudHDRDemo
CHudHealth
CHudHintDisplay
CHudHintKeyDisplay
CHudHistoryResource
CHudLocator
CHudMenu
CHudMessage
CHudPoisonDamageIndicator
CHudPosture
CHudSecondaryAmmo
CHudSquadStatus
CHudSuitPower
CHudTrain
CHudVehicle
CHudWeapon
CHudWeaponSelection
CHudZoom
CMapOverview
CPDumpPanel

Two things I'm uncertain about,

the namespace of this function:

vgui.SetHudElementVisible( "CHudCrosshair", false );

SetHudElementVisible( "CHudCrosshair", false );

and the capitalisation of 'hud':

SetHudElementVisible( "CHudCrosshair", false );

SetHUDElementVisible( "CHudCrosshair", false );

---

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[Blixibon]

Looks good to me.

I think the function's namespace and the current capitalization of Hud work well as-is.

[Blixibon]

Is there any reason in particular this was marked as a draft?

I was planning to merge this for Mapbase v7.1, and while it's okay if you have reasons for this to not be merged yet, I would either have to wait for this PR or remove the current SetHUDHiddenBits functionality separately before I can release the update.

[samisalreadytaken]

I set it to draft as I was fixing some bugs, but then I noticed more issues to resolve, I thought I would just include them here (let me know if you think the non-vgui fixes should be a separate PR).

a1c8dba

3D skybox angle calculation is reduced from angle -> vector -> transform -> normalise -> matrix -> quaternion -> angle & rotate into angle -> matrix -> concat -> angle.

55b8c8d

fake_worldportal optimisation also reduces multiple angle/matrix/vector conversions into simple matrix calculations.

b42086c

This clipping plane fix technically changes what the entity used to display, but the existing values made no sense. Here is a video comparing old and new: https://youtu.be/4AJ5tbOAGMw

---

The worldportal optimisation changes some existing questionable design choices.

In 7.0, brush angles are used in view transformation, which is an issue on its own as brushes never have any angles unless manually input by the user. Map-placed brushes with render target faces in different directions will result in inconsistent renders.

This could have been avoided by choosing to implement Portal 2's linked_portal_door entity behaviour, using 2 point entities which could be oriented freely; however the m_PlaneAngles offset angle (which also modifies the clip plane) can be used to simulate the rotation of the portal surface.

I would consider this inconsistency a bug, hence the fix to ignore the brush entity angles.

[Blixibon]

This looks good to me, and I'm alright with including these changes in this PR.

I really appreciate that you optimized the fake worldportals and 3D skybox angles. I didn't know much about what I was doing when I designed them and I was kind of embarrassed by how sloppy their implementation was.