Moonlight Lib

Moonlight Lib

Mods
86M Downloads

[1.20.1][Forge][Question]: Failed to find custom wood type

cech12 opened this issue · 9 comments

commented

BEFORE CONTINUING:

  • Always check you are using the latest version of this mods and it's dependencies

Version-Loader

1.20.1-forge

Moonlight Lib Version

moonlight-1.20-2.8.54-forge

Issue Detail

I am the developer of the ExtendedMushrooms mod and a user opens an issue related to the compatibility between Moonlight and my mod: cech12/ExtendedMushrooms#81

Your Finder::get method produces a warn message for my wood types and does not add compatibility wood blocks (together with Every Compat):
https://github.com/MehVahdJukaar/Moonlight/blob/1.20/common/src/main/java/net/mehvahdjukaar/moonlight/api/set/wood/WoodType.java#L192

      public Optional<WoodType> get() {
            if (PlatHelper.isModLoaded(id.getNamespace())) {
                try {
                    Block plank = planksFinder.get();
                    Block log = logFinder.get();
                    var d = BuiltInRegistries.BLOCK.get(BuiltInRegistries.BLOCK.getDefaultKey());
                    if (plank != d && log != d && plank != null && log != null) {
                        var w = new WoodType(id, plank, log);
                        childNames.forEach((key, value) -> w.addChild(key, (Object) BuiltInRegistries.BLOCK.get(value)));
                        return Optional.of(w);
                    }
                } catch (Exception ignored) {
                }
                Moonlight.LOGGER.warn("Failed to find custom wood type {}", id);
            }
            return Optional.empty();
        }

It seems, that the call of your Finder::get method is running before the registries are finished, because it is only possible to come to this position if the planks or log supplier returns air or null or if an exception is thrown.

Unfortunatly, I cannot debug there but here is some information about my environment:

I am registering my blocks via a deferred registry:

I add a Finder via your BlockSetAPI:

I also tested to create a Finder with the constructor and use the supplier of the deferred registry, but this does not work, too.

What I am doing wrong here?

Thanks for your help! :)

Log Attachment

https://mclo.gs/vvfzeOM

OPTIONAL: To Produce

Install following mods (Forge):

See the warning in the logs and find no furniture of the mushroom wood types.

OPTIONAL: Which mods are affected?

No response

commented

@MehVahdJukaar thanks for your support. Adding a custom Finder fixed the issue! :) The only thing, that was difficult here, was that the constructor of WoodType is protected. So, I needed to use refelctions to call it^^

https://github.com/cech12/ExtendedMushrooms/blob/1.20/src/main/java/cech12/extendedmushrooms/compat/Moonlight.java#L27

commented

Oh darn I didn't realize it wasn't meant to be

commented

Btw you could have also extended the class using new woodtype(){}

commented

No reflections needed

commented

Ahh yes, you are right! It is only protected, not private. ^^

commented

I'll run a test on this.

EDIT:
I can confirm the problem. I can't help wondering if EC is only applied to Wood. Mushroom is not really considered to be a wood? it's "mushroom"? 🤔 My reasons for this are:

  1. it uses a different ID unlike minecraft:oak_log & minecraft:oak_leaves which are detected by EC.
  2. It has planks but no logs, woods, or leaves.
  3. Like (1), it uses ID with "stem" at the end instead of "log".

I haven't checked if the block has a "Bass" sound. This type of sound is detected to be a wood type.

commented

The wood type detection does not work out of the box. Because of that, I add the woodtype to Moonlight myself: https://github.com/cech12/ExtendedMushrooms/blob/1.20/src/main/java/cech12/extendedmushrooms/compat/Moonlight.java#L16

So, I think, here is something wrong, but I don't know what it is. :)

commented

hm that seems off. EC runs after all blocks have been registered and taht code should do the same.
The integration code seems all right

commented

@cech12 That code runs on Init. there no blocks will be registered so you cant access your enum methods as many rely on the blocks being registered. (yeah i could make a register block type event i guess but right now that adds those finder objects whose task is to get a block. Infact registering a generic finder with a lambda implementation will essentially be an event so)
I think you could still do it pretty easily by not using the Simple finders and simly implement a custom one,they have a single function so you can have a lambda.

This is the code that doesnt work as you are calling it too early
public ResourceLocation getStrippedStemBlockId() {
return this.strippedStemBlock.getId();
}