Recipe tooltip fixes

[eigenraven]

Fix bad lighting in recipe tooltips and sometimes blank tooltips for handlers that expect the current GUI screen to be a GuiRecipe.

Fixes GTNewHorizons/GT-New-Horizons-Modpack#13954

[wlhlm]

For posterity: this fixes an issue reported on Discord where the nei-custom-diagram handlers in tooltip widgets would only draw over the main GuiScreen area:

I have pushed an additional commit to fix GTNewHorizons/GT-New-Horizons-Modpack#13954. The root cause was that a recipe handler (in this case nei-custom-diagram) might modify Minecraft.currentScreen (for example via Minecraft#displayGuiScreen) while the hack was applies, but this would be undone again when close is called.

However, there are actually multiple possible ways to fix these issues. The purpose of the height hack originally was to make certain legacy recipe handlers compatible with the layout changes (as I understand it). Considering that enabling it required explicit opt-in through heighthackhandlers.cfg, adding parts to it that apply even outside of the isHeightHackApplied check changes this and we should record our reasoning for this change.

The override for Minecraft.currentScreen was added in #398, because certain legacy handlers expected Minecraft.currentScreen instanceof GuiRecipe. For example, here is a snippet from IC2:

private void drawLiquidTooltip(FluidStack stack, int x, int recipe) {
    int y = 55;
    GuiRecipe gui = (GuiRecipe)Minecraft.getMinecraft().currentScreen;
    Point mouse = GuiDraw.getMousePosition();
    Point offset = gui.getRecipePosition(recipe);
    String tooltip = stack.getLocalizedName() + " (" + stack.amount + "mb)";
    GuiTooltipHelper.drawAreaTooltip(mouse.x - (gui.width - 176) / 2 - offset.x, mouse.y - (gui.height - 176) / 2 - offset.y, tooltip, x, 55, x + 12, 102);
}

The IC2 handlers are configured to have the height hack applied by default so those were fixed. However, it turns out that nei-custom-diagram also assumes a similar condition and breaks with the recipe tooltip widgets. The thing is. nei-custom-diagram is not a legacy handler, it was made with GTNH NEI in mind and didn't require the height hack previously. We could've fixed it in a number of ways:

1. add nei-custom-diagram toheighthackhandlers.cfg
2. fix the nei-custom-diagram code to not assume Minecraft.currentScreen instanceof GuiRecipe
3. apply the currentScreen override unconditionally to all handlers

Here is how I see it: Why not add it to heighthackhandlers.cfg? Because it's not a really a legacy handler and if it has issues with our NEI, it should ideally be fixed in the handler. Why not fix it in nei-custom-diagram directly? IMO this should be the first option to be considered. If possible, we should fix the handlers themselves instead of applying workarounds through NEI. This might need more code. The question to ask here is whether Minecraft.currentScreen instanceof GuiRecipe is a reasonable thing to assume in a handler or if it is bad code. My gut feeling is that this is a reasonable assumption and tooltip recipe widgets breaking this assumption should be handled on NEI side. So, option 3 sounds reasonable.

The issue I see with option 3 is that it doesn't really fit with the purpose of "height hacking" (it's not meant to only apply for legacy handlers since it's unconditional). The only similarity is that it need to be applied through the same mechanism. As such I think the HeightHack class should be renamed (and the javadocs adjusted), since the height hack, i.e. overwriting guiTop and height when configured, will only be a part of the mechanism now.

What do you think @eigenraven? I hope this made sense.

[github-actions]

Warning: 2 uncommitted changes
#404

[eigenraven]

@wlhlm I agree that this should be handled on the NEI side, does renaming HeightHack to CompatibilityHacks (only the class, not touching csv) seem reasonable?

[wlhlm]

@wlhlm I agree that this should be handled on the NEI side, does renaming HeightHack to CompatibilityHacks (only the class, not touching csv) seem reasonable?

Sounds good. Can you maybe move the code lines so that we have the height hack overrides together and then separately the currentScreen override. That is, move trueGui = NEIClientUtils.mc().currentScreen; below the height hack. Also, move the javadoc blurb about the height hack into the constructor closer to the height hack overrides.

[wlhlm]

Added a commit to fix overlay button offsets as reported on Discord:

While testing that I found a rendering bug with animations (not fixed):

[wlhlm]

This should be ready for review now. PTAL!