Mod loader

Forge

Minecraft version

1.20.1

Mod version

0.5.4

Modloader version

Forge 47.2.29

Modpack info

No response

If bug:

• Can you reproduce this issue with relevant mods only?

If bug: The latest.log file

https://pastebin.com/MyBhxvCL

Issue description

When loading XK Decor with FramedBlocks, a loading error occurs at the sided_setup phase, causing a failure to load into the game. Reading from the crash some blocks are lacking blockitems which I assume are trying to be called on by FB. I know this mod was just recently ported, if this is something that will be added in an upcoming version I can close this issue.

Alright so looking further into it, when I have FramedBlocks, XK, and Amendments installed it throws up the BlockItem issue. I take out XK and there is no issue, I take out Amendments no issue, I take out FramedBlocks no issue.

Should I close this and raise the issue with one of the other two?

Latest log: https://justpaste.it/eqwd5

thank you for finding it out, now I can reproduce it. I've wasted an hour on it and still don't know what is the cause. maybe you should report it to the author of FramedBlocks

This is an interaction between Kiwi and Moonlight (which Amendments depends on) and a check in FramedBlocks just makes the issue visible: Kiwi creates a MultiPackResourceManager during the RegisterEvent for blocks. This resource manager is marked as "client resources" and contains all client resources bundled in mods due to the call to Forge's ResourcePackLoader.loadResourcePacks() (https://github.com/Snownee/Kiwi/blob/8d4629786f9831eabd6d056603517f095757812b/src/main/java/snownee/kiwi/customization/CustomizationHooks.java#L361-L376). Moonlight has a mixin at the tail of the MultiPackResourceManager constructor which checks for the presence of a marker file and then executes an "early load" callback (https://github.com/MehVahdJukaar/Moonlight/blob/4f4390219b95d5ae257192a884bbeacd3d021014/common/src/main/java/net/mehvahdjukaar/moonlight/core/mixins/MultiPackResourceManagerMixin.java). Due to all mod assets being included in this "custom" resource manager, Moonlight finds that marker file and runs the callback (which it expects to happen far later than the block registry event). This fires an event and ultimately ends up in Amendments' WallLanternResourceManager which iterates the block registry, calls Block#asItem() on all blocks and poisons the partially cached block-to-item conversion by doing so that early (https://github.com/MehVahdJukaar/amendments/blob/847fd7ff34fb0f6082a3dd67cd4053cec948a25d/common/src/main/java/net/mehvahdjukaar/amendments/client/WallLanternModelsManager.java#L93-L100). Later on when I register my "ghost render behaviors" in the client setup event in FramedBlocks, the result of Block#asItem() (which incorrectly returns air now) is caught by a precondition that makes sure only valid blocks are registered (https://github.com/XFactHD/FramedBlocks/blob/220e2e70536c0bd0cee4130732d2e00efd10e8cb/src/main/java/xfacthd/framedblocks/client/render/special/GhostBlockRenderer.java#L261).
The problematic call stack in the debugger:

@XFactHD Thank you so much for pointing it out. I think I have fixed it now by making a copy of the MultiPackResourceManager so that the mixins will not take effect.