Issue description

Originally discovered in a personal instance (modpack development) of mine, I noticed after having configured the Raised mod to have a more lifted, bedrock-esque, hotbar visual, equipping a MekaSuit would have its HUD moved up by the equal amount as it was cut off at the top already, normally sitting comfortably within what's visible on screen
I was able to recreate this behavior within an isolated instance only using Mekanism and Raised, not even Sodium (+Iris) present. I also created an issue yurisuika/Raised#100 and was shortly informed on their discord of them seemingly only hooking into the existing GUI layers present. Of course given the clearly unintended behavior, I can only assume the MekaSuit HUD is tied to that of the hotbar which should instead be disconnected and resolve this issue (fingers crossed).

Steps to reproduce

1. Equip a full set of MekaSuit armor
2. Access the Raised config via "`"
3. Move the hotbar (top left has options for chat etc. which are unaffected) on the Y axis using the top right slider
4. Watch as the HUD moves off-screen

Minecraft version

1.21.1 (Latest)

NeoForge version

21.1.84

Mekanism version

10.7.7 (Latest)

Other relevant versions

Raised 4.0.1 (Latest 1.21.1 as of now) https://modrinth.com/mod/raised/version/NeoForge-1.21.1-4.0.1

If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)

https://mclo.gs/IjUkWxk

Thanks to yurisuika's help, never previously dealt with IntelliJ as your average consumer, I did manage to change the ClientRegistration.java line 318

event.registerAbove(VanillaGuiLayers.HOTBAR, Mekanism.rl("hud"), MekanismHUD.INSTANCE);

into

event.registerAbove(VanillaGuiLayers.CROSSHAIR, Mekanism.rl("hud"), MekanismHUD.INSTANCE);

as this seemed to be the most reasonable option available, although I tried

event.registerAboveAll(Mekanism.rl("hud"), MekanismHUD.INSTANCE);

covering up chat and the F3 menu, probably bad idea, same for BelowAll as yurisuika hinted at me regarding just the vanilla frozen or portal overlay whilst attaching it to the crosshair keeps it behind all those whilst unaffected by what appears to be any and all of Raised's configuration options, effectively solving the problem I was dealing with

and please tell me if there's a better way to demonstrate this, literally first time going this "deep" into the matter

EDIT: setting it below the SLEEP_OVERLAY may be the smartest choice available and a direct recommendation from yurisuika

I believe this is on Raised to fix. Layers are named with ResourceLocations and therefor they should not be moving layers that aren't the intended target.

Crosshair does not seem like the correct layer to target it to either, but glad it works for your use case.

That is why I mentioned the sleep overlay part, past that point it's their business what to make of this information

the Forge GUI registry doesn't determine when a modded GUI element renders, it is only determining where it renders in the layers

That's not correct, it determines the order they render in. There are even events for before and after a layer has rendered. See net.neoforged.neoforge.client.gui.GuiLayerManager

There should be no need to capture anything related to other gui layers. The pre/post render events have the layer name supplied, so you could do your translations there.

What I was trying to explain is that the Forge GUI registry doesn't determine when a modded GUI element renders, it is only determining where it renders in the layers. Going by the vanilla layers, hotbar is near the bottom with crosshair one below it. So if you're registering your GUI below the hotbar, it will be above the crosshair. In realistic usage in this mod's case, no matter how much you squish the screen around, you still can't get any of the GUI stuff to intersect with the crosshair. So, if you were to register it below the crosshair, it would make no difference visually. Any vanilla stuff is going to render above it, like the boss bars presently do if your window is narrow enough.

In order to support mod GUIs that use the register event on Forge instead of the render event, Raised captures any modded HUD element's resource location that is "associated" with the vanilla layers it must translate. The only way to make this association that I am aware of is to determine for which vanilla layer it is registered above/below. Effectively, registering above the crosshair and registering below the hotbar does the exact same thing, that is until you have other mods doing one or the other and then you gotta get the event priority involved. Hence my suggestion, as it would resolve the conflict and should not realistically impact anything visually.

As far as the sleep overlay goes, I was suggesting that a GUI element should be placed no higher than that, unless you want it clearly visible when you sleep. Like the crosshair, Raised does not interact with the sleep overlay layer in any form.

The only reasonable non-hardcoded way to make a change on my end would be to add some sort of Forge exclusive blacklist that a user could configure with a command. This would still rely on the user knowing that the blacklist exists and understanding how to use it. Users may still end up filing reports because of this. Would be leagues better than having users have to manually add the modded registered overlays to the Raised overlay groups in a config, but still not without a substantial loss in ease-of-use.

However, changing the mekanism hud to be associated with a different element (such as crosshair) would eliminate any conflict and have no negative results. Register above crosshair, below crosshair, above camera overlays, it should all visually produce the same result w/o conflict w/ Raised.

For reference, these are the elements that Raised may translate. Of course, the toasts do not have a Forge encapsulation. https://github.com/yurisuika/Raised/blob/NeoForge-1.21.1/src/main/java/dev/yurisuika/raised/util/Overlay.java

At the end of the day changing the variable out retains the same implementation but set to a different GUI layer as mentioned with my original post
This argument could go on forever based on opinions or whatever but the end result is likely to be changing parts of this
event.registerAbove(VanillaGuiLayers.HOTBAR, Mekanism.rl("hud"), MekanismHUD.INSTANCE); to registerBelow(VanillaGuiLayers.SLEEP_OVERLAY as suggested speaking to them on their discord server
it could also merely be swapping VanillaGuiLayers.HOTBAR to VanillaGuiLayers.CROSSHAIR or whichever one really ends up fitting the best whilst not conflicting with the other, simple as that

To me this sounds most logical and does not require much of an argument to get done as even after personal testing running the mod set to VanillaGuiLayers.CROSSHAIR for the sake of proving a point with nothing to report other than it now not being affected by the Raised mod ¯\_(ツ)_/¯

Not to mention it wasn't really any different with another different case of this sorts using https://modrinth.com/mod/camerapture which was resolved by very much doing the same thing but in Mekanism's case even easier given the existing code only needing a word or two swapped
chrrs/camerapture#35
chrrs/camerapture@f76beb3