HUD customizer v1 (rebase)

[Chudesnov]

Revival of https://github.com/momentum-mod/panorama/tree/feat/hud-customizer-v1

Closes momentum-mod/game/issues/2158

Checks

• I have thoroughly tested all of the code I have modified/added/removed to ensure something else did not break
• I have followed semantic commit messages e.g. feat: Add foo, chore: Update bar, etc...
• My branch has a clear history of changes that can be easy to follow when being reviewed commit-by-commit
• My branch is functionally complete; the only changes to be done will be those potentially requested in code review
• All changes requested in review have been fixuped into my original commits.
• Fully tokenized all my strings (no hardcoded English strings!!) and supplied bulk JSON strings below
• None of the above yet. Just made sure ES Modules are used instead of namespaces and TS/ESLint don't complain. Also, any of the panels added between the old branch and current 0.10 aren't hooked up to the HUD customizer.

POEditor JSON Strings (if needed)

[
	{
		"term": "",
		"definition": ""
	}
]

[tsa96]

Have you tried this out ingame? I could be wrong, but I don't think HudCustomizer will be exposed to the JS context scripts in XML run in. I would wrap all the functions in HudCustomizer in a HudCustomizer class with a @PanelHandler decorator, that will instantiate the class and ensure it's exposed to the main context.

[Chudesnov]

I forgot to add the decorator, will fix.

[Chudesnov]

Moved functions and most initialization into a HudCustomizer class with the PanelHandler decorator in ae53a57. Also refactored some sections, e.g. the "default" component layouts, so they can be more easily refactored to use the proposed HudCustomizerAPI.GetDefaultLayout() based mechanism.

[Chudesnov]

@tsa96 After actually trying to use this in game (with the 0.10.0-pre branch in Steam), I see that this is still not working as expected.

The events originally used in this module (HudChat_Show and HudChat_Hide) never actually seem to fire when I'm in game. I tried using events that looked like their replacements with the new HudTabMenu prefix (HudTabMenu_Opened, HudTabMenu_Closed, HudTabMenu_OnMouseActive), with the same result.

Also, despite being exposed to the context object (tried both @PanelHandler() and getOrCreateGlobal ), and being available to the inline onload handler on <Hud> -- see below --, HudCustomizer doesn't seem to be available to other inline event handlers like onmouseover/out on #HudCustomizerSnaps , I get a bunch of ReferenceError: HudCustomizer is not defined when hovering over them.

Might’ve been a pointless detour, but I also decided to investigate how and when the HUD customizer class actually gets initialized. The customizer.ts script gets loaded multiple times, first in the main menu, then each time I load into a map. As far as I understand, this is expected, but I'm not sure the initialization code is working correctly with the HUD instance that appears in game: when I add logging (with $.Warning) to the module (in the top level scope) and the onPanelLoad method, the only warning I see logged in the console consistently when loading into a map is the module scope one. The onPanelLoad one only gets logged when I first load into the main menu (even if I manually re-subscribe to the PanelLoaded event the next time @PanelHandler is called with this specific class, the event handler is never called again), same for the inline onload="..." handler I tried adding to the root <Hud> element in hud.xml. - it only gets called once in the main menu.

// Loading into main menu
[panorama] HudCustomizer: HudCustomizer script loaded
...
[panorama] HudCustomizer: HUD loaded... (onPanelLoad)
[panorama] HudCustomizer: XML loaded (Hud onload=''). HudCustomizer class accessible from XML
...
// Loading into a game mode
[panorama] HudCustomizer already in scope. This is a special case, trying to rerun panel handler logic (subscribe to PanelLoaded), this is probably a bug
[panorama] HudCustomizer: HudCustomizer script loaded
...
// Opening tab menu
// Trying to interact with a panel that calls HudCustomizer methods
[panorama] JS Exception! *** Skipping rest of script ***

Panel#HudCustomizerSnaps - onmouseover
line:1, col:0

>> HudCustomizer.showSnapTooltip();

ReferenceError: HudCustomizer is not defined
    at Panel#HudCustomizerSnaps - onmouseover:1:1

[panorama] JS Exception! *** Skipping rest of script *** 

Panel#HudCustomizerSnaps - onmouseout
line:1, col:0

>> HudCustomizer.hideSnapTooltip();

ReferenceError: HudCustomizer is not defined
    at Panel#HudCustomizerSnaps - onmouseout:1:1

What could be the cause of this issue? Is it somehow related to Hud having useglobalcontext="false" -- not sure what exactly that does? I’m stuck on this right now.

[tsa96]

I debugged this briefly and Panorama is reloading the hud.xml layout file on map load, presumably something Valve added. I think what's happening is the JS context is maintained, so @PanelHandler() sees an instance already exists and early returns.

I'm asking internally if we know why the reload every time is necessary, perhaps we can remove that. It's probably possible to re-register everything but tricky, and I'm very confused as to why the thing with onload in the <Hud> element didn't work.

[tsa96]

Removing the layout reloading code in C++ seems to fix stuff, though now I get an error about failing to load the hud.kv3 file. Getting more and more wary of us working on hud customizer stuff atm, if there's further C++ work required I'm afraid I absolutely will not have time for it after 0.10.0

[Chudesnov]

Understandable. Can we at least verify that TS stuff for dragging/resizing works (without relying on save/load functionality) with HUD reloading disabled in engine and merge that (as a temporarily disabled/hidden feature until C++ stuff required for storage access is resolved post-0.10)? The flattened HUD layout part would probably need to be reverted though, unless baking widgets' "default" positions and sizes into the TS file (as JSON) is okay.

[tsa96]

Yeah I think disabling trying out disabling the re-layouting is the right approach, so long as other devs are on board, have made a PR on our game repo, will try get that out in a Steam build this week.

Also, figured the reason loading wasn't working, needs a hud_default.kv3 file in momentum/cfg to work. So need to download this, rename to .kv3, and stick in there. Typedefs for HudCustomizerAPI explain the behaviour around those files.

hud_default.txt

[tsa96]

Never mind sorry, register-for-gamemode stuff seems to be broken by this. I'm afraid I really don't have time to investigate this much further this week what with all the other 0.10.0 stuff on. I could write up some notes on how we may to be able to get the customizer working with the reloading behaviour, will do on Discord later.

[Chudesnov]

@tsa96 Got busy with work and other real-life stuff the past few months, but I’ve got some free time now to work on projects. Let me know if it makes sense to rebase again, or if I should wait for your go-ahead (I remember there was some C++ work in progress that was blocking proper widget onload handling or something like that).

[tsa96]

@tsa96 Got busy with work and other real-life stuff the past few months, but I’ve got some free time now to work on projects. Let me know if it makes sense to rebase again, or if I should wait for your go-ahead (I remember there was some C++ work in progress that was blocking proper widget onload handling or something like that).

I have to be honest, I have no recollection of what needed changing in C++. Could you try dig up previousy Discord messages?

If there's unfinished stuff on here you're welcome to work on it further, but I'll be very busy over the next few weeks with 0.10.0 release. Happy to try and answer questions, but unlikely to have time to read significant amounts of code.

Also note with rebasing, the 0.10.0 branch has now been merged into main so you'll need to rebase onto there.

[Chudesnov]

I have no recollection of what needed changing in C++.

There's an unresolved thread on this PR that seems to get into great detail on what's broken #212 (comment) but not sure how much of that is still relevant.

The tl;dr is that the layout from hud.xml and its associated HudCustomizer class initialize correctly when you load into the main menu, then Panorama is reloading the hud.xml layout file on map load, which the script doesn't expect (it expects to be initialized once), and manual re-initialization isn't possible either because neither onload nor PanelLoaded fire again, and the references to the old HudCustomizer from inline callbacks in XML code (e.g. <Panel id="HudCustomizerSnaps" onmouseover="HudCustomizer.showSnapTooltip();"> don't resolve anymore, causing ReferenceError exceptions.

I can rebase this onto master in the meantime.

[Chudesnov]

@tsa96 I've "successfully" rebased the branch again. Nothing still works as intended, and I don't really understand what needs to be changed for it to do (the HudChat_Show and HudChat_Hide either don't fire or aren't handled correctly by the customizer.ts script), but at least nothing crashes now when trying to interact with the "virtual" panel's elements when I add a hud_default.kv3 file to my cfg folder.

[tsa96]

@Chudesnov Hey, sorry to have been so unresponsive on this, had too much on. I've been looking into HUD customizer stuff over the past few days and seem to have stuff working, your work has been really helpful.

I'm not 100% sure what the issue with the PanelHandler decorator was but roughly, when the game loads into a new map it reloads the entire hud.xml layout file, however doesn't seem to reset the JS context for that panel. There's some pretty intricate handing for panel reloads cleaning up event listeners and related stuff registered with Panorama from a JS script, which wasn't getting run for hud.xml.

There's probably some ways to get it to work, but I decided to keep stuff simple and created a new <HudCustomizer /> panel in C++ (replaces HudCustomizerAPI) so it gets it's own context, then the JS code just accesses all the HUD components by calling $.GetContextPanel().GetParent() to access the <Hud /> customizer panel it lives inside of. So it behaves like any other HUD component panel.

Currently all my work is on a very messy branch feat/hud-customizer-reborn which is based on top of your stuff on feat/hud-customizer-v1. Not really sure what the best approach is, would like a spend a few more days on stuff before figuring out how to structure the branches. I can try get the C++ changes merged relatively soon so the Panorama branch is usable by other people, but again would like a couple days to ensure this approach makes sense before getting a game PR in.

[Chudesnov]

@tsa96 thanks for the update Tom, happy I could help somewhat here. Let me know when the C++ stuff lands or if there is an alternative approach worth taking.