Incompatibility with Quark's hotbar feature

[ali-afk]

When 'Z' is pressed, most HUD elements on-screen move along with it. This also applies to other HUD elements such as the pause screen.

Here are two pictures for the before and after:

[yurisuika]

Please provide some more info such as versions, mods involved. Raised is going through a rewrite at the moment so this may no longer be reproduceable, but to ensure that I'll have to test your setup.

[ali-afk]

Sure! Just give me a second to set it up.

[ali-afk]

Forge: 47.3.0 MC: 1.20.1

Mods to reproduce issue: (Quark, Zeta, Embeddium) Note that original pictures were from a large modpack though

[yurisuika]

Usually what this behavior involves on Forge is another mod is calling a pre-event but not a post-event. Having a balance of pre and post events is critical to Raised being able to envelope both vanilla and modded HUD elements to translate them.

It might be a little while until I am able to test this out while I finish the rewrite, but in the meantime I'd recommend trying to set the extended mod "support" option to false and see if that stops it. Otherwise, it probably is an incompatibility that I cannot resolve from my end.

[yurisuika]

https://github.com/VazkiiMods/Quark/blob/master/src/main/java/org/violetmoon/quark/content/management/module/HotbarChangerModule.java#L70

Okay, so I've had a look into it, and here is what I've gathered so far.

Quark uses its own analogue to Forge's event bus system. It uses these events to translate the player health, and counter translate the F3 overlay and effects icons. Everything that renders between those two gets translated.

Against Raised 4.x, Quark manages to translate the health, but not the rest of the status bar stuff. I am having a hard time getting down to understand exactly how it is initiating these events, I'd assume it works like a mixin inject, but it seems it is relying on the counter translation for the F3 menu or effects to stop it. Something similar was how Raised work earlier in 3.x before I had a better understanding of the render system (I still am a total noob though).

I've tried eliminating as much of Raised's stuff from running as I can, removing some functionality to make it as basic as causing a pop and translate on the RenderGuiOverlayEvent.Pre and do a pop on the ~.Post. Still it causes the effects icons to move, but also does the pause menu/raised's own options menu, and sidebar too when its cut down to JUST the hotbar element on that event.

If I disable Quark's hudHealthPre, hudDebugTextPre, and hudPotionIcosnPre from running, then of course none of the status icons move, but nothing else moves that shouldn't. If I make it push and pop on the pre and post events or at least do a countertranslation on the post event, then at least only the health translates and nothing that shouldn't

I assume the reason Quark is doing it like it is is to capture any mod stuff added between the health bar and the effects icons added with RegisterGuiOverlaysEvent, in which you can insert your overlay before or after another one, vanilla or modded.

It has these events for some of the element types that Forge has created, but only the ones that it seems to focus on as endpoints.

https://github.com/VazkiiMods/Zeta/blob/main/src/main/java/org/violetmoon/zetaimplforge/client/event/play/ForgeZRenderGuiOverlay.java

In Forge's VanillaGuiOverlay enum, going from PLAYER_HEALTH, you then go through ARMOR_LEVEL, FOOD_LEVEL, AIR_LEVEL, MOUNT_HEALTH, JUMP_BAR, EXPERIENCE_BAR, ITEM_NAME, and SLEEP_FADE before you hit POTION_ICONS or DEBUG_TEXT.

https://github.com/MinecraftForge/MinecraftForge/blob/1.20.1/src/main/java/net/minecraftforge/client/gui/overlay/VanillaGuiOverlay.java

This would mean Quark is also running a translate on the sleep overlay too, which I can only assume it probably doesn't want to do.

In order to capture any overlays registered with RegisterGuiOverlayEvent and not just RenderGuiOverlayEvent (in which your overlay is rendered when and where (either pre or post) one of the vanilla encapsulations is rendered and thus is wrapped by Raised's actions), Raised tracks if the registered overlay is in relation to one of the overlays it translates (this is a string resourcelocation that it is registered with), and if it does then it also adds it to the list of overlays to be translated. Thus, every added overlay that meets this criteria is wrapped in the push/translate and pop.

I'd think that this might be the best approach that Quark might want to avoid such a conflict with Raised. I really am not sure what I could do on Raised's end to alleviate this, but it seems that if Quark fleshed out its Zeta events to wrap in the push/translate + pop for every element type it wants to move AND also do what I have done for Raised for the registered overlays, then I think it would work flawlessly.

[yurisuika]

Here you can see that it doesn't translate the RECORD_OVERLAY because it falls outside of that endpoint but it does translate the sleep fade (kinda tough to see but it is there). This is vanilla Quark without Raised installed.

I personally consider the record overlay to be part of the hotbar section because of its placement, but that is up to Quark's dev to decide it if should be part of that or not, As it is set up, it can't move it, but if it does my recommendations it can.

[yurisuika]

Okay I found it, as I suspected it fires these events when the RenderGuiOverlayEvent is ran for the corresponding element types.