Incompatibility with Quark's reach-around placement indicator

[Xefyr0]

Issue only arose after updating to 3.0.0. Issue only replicated on 1.19.2. Forge-only, since Quark is not on Fabric.

PROBLEMATIC BEHAVIOR

Reach-around placement brackets (<+>) and underside placement brackets ([+]) are doubled & shifted upwards on 1.19.2 regardless of "support" config setting.

Minecraft version 1.19.2: Forge version 43.3.0 & 43.3.2 Quark version 3.4-414 Raised version 3.0.0

EXPECTED BEHAVIOR

Placement brackets are only shifted, not doubled on 1.18 when "support" config setting is true.

Placement brackets are not shifted or doubled on 1.18 when "support" config setting is false.

Minecraft version 1.18.2 Forge version 40.2.10 Quark version 3.2-358 Raised version 3.0.0

I posted this issue here instead of on Quark because the change in version what what led me to notice this bug. It may be the case that the changes in Raised merely uncover an previously-undiscovered bug in Quark. If this is the case please let me know so that I may re-post this issue there instead.

[yurisuika]

Try turning off extended mod support in the config, it may stop moving it. On Forge 1.18.2 this disables translating any mod that draws its elements on the ALL type for RenderGameOverlayEvent or registers them with OverlayRegistry.

If something is being drawn twice, I am pretty sure it is something that is already present in the mod. I've uncovered such issues in several mods like Inventorio and Create when making these changes. All Raised does is translate the Y position of the matrix stacks. It doesn't call on them to render or anything like that.

[yurisuika]

Sorry, I didn't read through this fully at the time, I was in the middle of something.

If it is doing it when the extended support setting is false, then it is rendering in accordance with either the hotbar, health, armor, food, mount health, air, jump bar, exp bar, item name, or record overlay.

It looks like this should be using the Crosshair element. I don't know where in Quark's source this is to confirm it, though.

[yurisuika]

Okay, my reading comprehension is not the best right now, been up too long. So it works fine on 1.18, but not 1.19.

So it seems that Quark is using the ALL element type in 1.18... On the 1.19 version it us using the Crosshair as I expected.

https://github.com/VazkiiMods/Quark/blob/1.18.2/src/main/java/vazkii/quark/content/tweaks/module/ReacharoundPlacingModule.java https://github.com/VazkiiMods/Quark/blob/master/src/main/java/vazkii/quark/content/tweaks/module/ReacharoundPlacingModule.java

Well, I'll look deeper into this soon and see if I can come up with a solution.

[yurisuika]

Okay, I think I found the solution.

They are rendering it on every event EXCEPT for the crosshair event... it should be like this.

As you can see from the screenshot, it works.

[yurisuika]

Basically since 1.19, Forge has used something called NamedGuiOverlays to replace all of the vanilla HUD elements. When they are rendered, it triggers an event. As noted before (although a little different cause those were from 1.18), Raised will only translate on a few certain ones. But since Quark was doing the inverse of what it meant to do, It was rendering every time every vanilla hud element was rendered except for the crosshair. This means everything from things like portal overlay to scoreboard.

[yurisuika]

Further visual proof of that is cause Raised also can translate the chat separately, here we have 3 visually shown ones... One for the chat, one for the hotbar, and the other one assumedly for the vignette. If I were to change gamemode and have stuff like health bar, armor, etc also render, then it would be drawing another one for each type drawn. (using the latest quark release)

So yeah, it is a bug on Quark's end. It is literally changing 1 character in the code though, so it would be super easy to fix yourself in the meantime.

[Xefyr0]

First off, thank you so much for putting this much effort into the issue despite the cause being on Quark's end. It seems that there's a pre-existing open issue for this over there, so I will share the information you provided here and credit you for discovering what seems to be the cause.