Lizard-Of-Oz
commented
10 months ago Upon further thinking (although without knowledge of TF2 code), having PD HUD read arbitrary template values (like %score%, %cooldown%, etc) from a table which can be sent from server to client with VScript on a per-player basis seems the easiest and most straightforward, while also achieving the desired goal.
With custom gamemodes being made with an expectation to be featured in TF2 Updates, such as VS Saxton Hale, Zombie Infection and an upcoming adaptation of Open Fortress, gamemode creators want to make gamemode HUDs that don't stick out like a sore thumb.
If proper custom VGUI support is unfeasible to implement, I propose a simpler and safer solution.
TF2 already supports a custom Player Destruction HUD you can build into the map, which can display any arbitrary UI elements, but lacks two important functions:
Because there's already a map IO input to toggle the cooldown container or set its time, I assume the system for sending PD HUD changes from server to client is already in place.
If not, some values on PD HUD appear to be read from an outside table (e.g. team scores and deposit cooldown) - maybe it'd be possible to write arbitrary values for any UI element into that table with IO or VScript, which would ultimately achieve the same result.
Is simpler words, this would allow to have, say, a dozen text elements on PD HUD and change them at any time on a per-player basis.
UPD: Upon further thinking (although without knowledge of TF2 code), having PD HUD read arbitrary template values (like %score%, %cooldown%, etc) from a table which can be sent from server to client with VScript on a per-player basis seems the easiest and most straightforward, while also achieving the desired goal.
Having it per-player is important, but I imagine it being hard to achieve with other methods, as it would use conventional entity synchronisation. However, If this custom table has to be sent manually with vscript, like proposed here, this problem will be avoided.
While it doesn't allow for clickable menus, it would satisfy much more custom gamemode needs than the existing solution. If VScript could read Number Keys (currently it can't) map creators would have the ability to make interactive menus. Currently it's not possible as the server has no way to distinguish
slotNfromprevinv/nextinv.I understand that things might be more difficult under the hood - making that remark would hurt text readability. Especially with per-player instancing, which is crucial for custom gamemodes.