Issue Description:

When playing with Ender IO, Crafting Tweaks and JEI installed, the recipe book button can not be detected by Crafting Tweaks, causing Crafting Tweaks' "hide recipe book" option to no longer work and the button to overlap with Crafting Tweaks' own buttons.

What happens:

Ender IO takes the recipe book button and wraps it in a custom class with a different id making it impossible for other mods to find the button without specifically special-casing Ender IO. As a result, Crafting Tweaks is unable to either move the button out of the way, or hide the button (depending on the user config).

https://github.com/SleepyTrousers/EnderIO/blob/be323475483d6ace21ec450a86154b9d96e3de69/enderio-base/src/main/java/crazypants/enderio/base/handler/RecipeButtonHandler.java

https://github.com/blay09/CraftingTweaks/blob/1.12/src/main/java/net/blay09/mods/craftingtweaks/CraftingGuideButtonFixer.java

What you expected to happen:

Ender IO could listen to the ActionPerformed.Pre event instead of (unnecessarily?) wrapping the original button in its own class. Alternatively, it should probably use EventPriority to try and run its InitGui event handler last.

Steps to reproduce:

1. Place a Vanilla crafting table.
2. Open the crafting table to see Crafting Tweaks no longer being able to react to the recipe button as it should.

Affected Versions (Do not use "latest"):

• EnderIO: 5.0.22
• EnderCore: 0.5.20
• Crafting Tweaks: 8.1.8
• Just Enough Items: 4.9.1.168
• Minecraft: 1.12.2
• Forge: 14.23.3.2673

Your most recent log file where the issue was present:

N/A

TwelveIterationMods/CraftingTweaks#116
TwelveIterationMods/CraftingTweaks#117

Seen this?

(PersonalConfig.recipeButtonDisableAlways.get()
        || ((PersonalConfig.recipeButtonReplaceWithJei.get() || PersonalConfig.recipeButtonDisableWithJei.get())

Yes, but a config option is not a good solution to a compatibility issue, especially when most people won't even know where to find it (Ender IO isn't the kind of mod you would expect to alter Vanilla crafting tables, which is why it was initially difficult to even track this issue down).

If a config option isn't a good solution, then how come is fine for crafting tweaks to use a config option? Also, it's much better for us to give the option then hard code support for every slight mod conflict out there

You got it the exact wrong way around though. You don't need hard code support for a specific mod, you just need to apply the fix I've mentioned in my first post that would preserve compatibility with any other mod trying to find the recipe book button. I am the one who would require hard coded support for Ender IO, which is completely unnecessary in this case for the reasons I have already outlined above.

Crafting Tweaks doesn't use a config option trying to avoid mod conflicts because it doesn't have this issue to begin with. It doesn't effectively wrap and hide the button from other mods. This is an issue in Ender IO's implementation of the RecipeButtonHandler regardless of which other mod is affected.

Crafting Tweak should not put their buttons where we put our button. They should detect that another mod is using that space and place their buttons somewhere else.

Why would Crafting Tweaks have to move its buttons? Looking at the two we have

1. a mod specifically aimed at altering the Crafting Table, which had these buttons placed next to the grid even before the recipe book became a thing; and once it did become a thing, started moving the recipe book to a more fitting place

2. a tech mod that also happens to have an unrelated tweak to the Vanilla Crafting Table, imitating the recipe book button, but in a way that breaks other mods that are trying to find the recipe book button

I'm not asking you to move your button. I'm asking that, if you're imitating the vanilla button, don't obscure it in code so that other mods will no longer be able to detect it; causing these mods to appear broken to the end user. For that I have provided two perfectly good and clean solutions.

Either way I have decided to change my code to adapt to EnderIO now, and it seems the other recipe book altering mods are currently functional (one due to EventPriority, the other due to load order luck), but the issue on your side of being unnecessarily invasive persists.