[🐞]: Diagonal Windows mod causes Create compat window panes to lose recipe on reload command

[littlej541]

Code of Conduct

• Always check you are using the latest version of the mods and its dependencies
• Remove mod that enhances Minecraft: Optifine, Sodium, others. The issue still persists.
• If you are unsure which mod is the culprit.
  Disable all of your mods and enable them 1-2 mods each time to isolate the culprit
• Confirm that there is no existing issue with a similar description submitted in the list of issues.

Version - Loader (DO NOT FORGET TO SELECT THE CORRECT VERSION)

1.20.1 - FORGE

EveryCompat Version

everycomp-1.20-2.7.10.jar

Moonlight Lib Version

moonlight-1.20-2.13.45-forge

Issue with mods

Diagonal Windows

Issue Detail

With Diagonal Windows, Create, and some other EveryCompat supported mod, any Create-style window pane block added by EveryCompat loses its recipe after calling the /reload command. Because of this, the aforementioned blocks will no longer be able to be crafted.

By stepping through with a debugger attached, it seems that Diagonal Windows replaces the BlockItem#block with a ForgeDiagonalGlassPaneBlock sometime after the initial load. So when you call /reload, and this function call from Moonlight occurs, it is called with a diagonalwindows:create/oak_window_pane block instead of a create:oak_window_pane block. Because there is no Diagonal Windows compatibility module or other method that registers that type of block to the WoodTypeRegistry#OAK_TYPE object, the call returns null. This value ends up propagating to this line in Moonlight where an exception is thrown, which is finally caught here,

WoodGood/common/src/main/java/net/mehvahdjukaar/every_compat/misc/ResourcesUtils.java

Lines 307 to 309 in e1c6d9f

	} catch (Exception e) {
	EveryCompat.LOGGER.error("Failed to generate recipe @ {} for {}: {}", oakRecipe, i, e.getMessage());
	}

the outcome being that no recipe ends up being registered.

OPTIONAL: Latest.log | Crash-report Attachment

There is no crash, but a bunch of errors like

[Server thread/ERROR] [Every Compat/]: Failed to generate recipe @ create:oak_window_pane for c/biomesoplenty/mahogany_window_pane: Could not convert output item oak_window_pane from type minecraft:oak to biomesoplenty:mahogany

are spit out into the log.

OPTIONAL: To Produce

1. Add Create, Diagonal Windows (requires Puzzles Lib), and some other mod with EveryCompat support (I used Biomes O' Plenty, which also requires TerraBlender and GlitchCore) to your mod list.
2. Load/start a world and attempt to craft some window panes such as Mahogany Window Panes with Mahogany Windows. Everything works as it should.
3. Use the /reload command
4. Attempt to repeat step 2. You should no longer be able to craft any EveryCompat added window panes.

[Xelbayria]

the item is actually everycomp:c/biomesoplenty/fir_window. but when you place it. it will become
diagonalwindows:everycomp/c/biomesoplenty/fir_window as you placed the window. that's what allow these windows to be diagonally placed or not. The recipe should remain the same to allow you craft the item.

do you have KubeJS or CraftTweaker installed?

[Xelbayria]

If you are developing a modpack with EC and other mods. Then you should read the last comment via #467

there is a similar issue with Diagonal Fences. I want you to try break the window in survival to see if it would drop. let me know if it doesn't, then I can apply the fix.

There is no way to fix the problem with reloading the recipes using /reload. EveryComp only generate the recipe when you are loading into the world. After the generation, the recipe get loaded so you can craft any product. my best guess is an issue on KubeJS or CraftTweaker.

[littlej541]

ISSUE 2

The pared down test mod list is as follows (so many libraries):

• create-1.20.1-0.5.1.j
• PuzzlesLib-v8.1.25-1.20.1-Forge
• DiagonalWindows-v8.1.5-1.20.1-Forge
• moonlight-1.20-2.13.45-forge
• everycomp-1.20-2.7.10
• TerraBlender-forge-1.20.1-3.0.1.7
• GlitchCore-forge-1.20.1-0.0.1.1
• BiomesOPlenty-forge-1.20.1-19.0.0.94

I'm not able to get an item to drop when breaking the window panes, even with a silk touch pickaxe, either before or after a reload. The block's drop table must not get set correctly (maybe it doesn't even exist?) when it is converted to a diagonalwindows:everycomp/c/biomesoplenty/fir_window_pane, or something to that effect.

In any case, everything you've said is true. It may very well cause issues (like the drop table problem), but it does not cause the issue I've reported.

All my information came from attaching a debugger to an instance outside of a development environment via IntelliJ, with a breakpoint placed right about here. When a world is started/loaded, BlockType#changeType ends up first being called with an Item. If this fails (it does and should in our case) to produce a key, and Item is a BlockItem, the function is then called with the Block gotten via BlockItem#getBlock. This is what we get before a reload:

And after a reload:

As can be seen, current holds the object BlockItem@29013 before a reload. Since this exists in the map, a key is found and everything works as intended. After a reload, however, current is suddenly ForgeDiagonalGlassPaneBlock@38457. This causes BlockType#changeType to fail to find a key, since the new object is nowhere to be found in the map. After further inspection, it turns out that through a convoluted chain of events between Diagonal Windows, Puzzles Lib, and Diagonal Blocks (a mod jar-in-jar'd into each Diagonal mod by fuzs) use two mixins to alter BlockItem#block and Block#item after the TagsUpdatedEvent is fired by Forge. I'm assuming this event fires after EveryCompat does its thing and is why this issue only happens after a reload. As a test, since I've already gone this far, I added the following snippet

public void addDynamicServerResources(ServerDynamicResourcesHandler handler, ResourceManager manager) {
    if (PlatHelper.isModLoaded("diagonalwindows")) {
        String childKey = windowPanes.getChildKey(this);

        windowPanes.getBaseType().getChildren().stream().filter(child -> child.getKey().equals(childKey)).findFirst()
                .ifPresent(oakWindowPane -> {
                    if (((Block) oakWindowPane.getValue()).asItem() instanceof BlockItem bi) {
                        oakWindowPane.setValue(bi.getBlock());
                    }
                });
    }

    // snip, snip, snip...
}

to CreateModule#addDynamicServerResources to "fix" the appropriate map entry. This fires regardless of whether a reload has happened or not, doing essentially useless work when no reload has happened and placing the altered BlockItem#block in the map when a reload happens. The capture when calling BlockType#changeType after a reload is now like so:

Now current matches an object in the map, that being ForgeDiagonalGlassPaneBlock@32738, and a key is found. More importantly, the recipe still exists after a reload. I don't know if this change causes any new issues, but I have not noticed any.

---

FIXED in v2.7.11

[Xelbayria]

I'm not able to get an item to drop when breaking the window panes, even with a silk touch pickaxe, either before or after a reload. The block's drop table must not get set correctly (maybe it doesn't even exist?) when it is converted to a diagonalwindows:everycomp/c/biomesoplenty/fir_window_pane, or something to that effect.

i already know how to fix that problem. don't worry about it.

EDIT:
I've looked in a similar issue involving Diagonal Fences for Macaw's Fences & Walls. I know what's the problem.

[Xelbayria]

The issue with dropping of window_pane are fixed in next version.