I am the developer of Extended Mushrooms mod and I really like your mod!
With the upcoming 1.19 update, I would like to recommend your mod to be compatible with other wood mods.
However, in my mod I have special wood types that are not fully compatible with your mod. There are three issues, I have encountered:

The first one is, that the IDs of my wooden blocks are not following the standard your mod is relying on. This could be fixed by renaming the ids and is not such a big issue. (see also #25)

The second issue is, that I extend the vanilla mushroom stem block to be part of a wood type. That does not match your wood detection, because it only searches for the same mod id in the registry.

The third problem is, that all my stem blocks are log bocks as well as wood blocks, because of the special behaviour that the inside of mushroom blocks is only visible when a connected mushroom block is removed. But in your mod it is only detected as log block and all wood block recipes (example: Posts of Quark mod) are missing.

All these issues could be fixed, if there could be a possibility to register a custom wood type for this mod, where I can submit all my block ids of a wood type.
Maybe through an interface or InterModComms messages or something like that. I would love to see such a feature. :)

Thanks for your time! :)

Hi. So the mod does it's best to dynamically detect whatever wood type is installed. This works wonderfully for standard wood types but unfortunately issue arise for more different and unique ones like indeed that one. I'll add a built-in definition of it like I have with a very few selected others that don't follow conventions

Oh also there totally is a way to register custom wood types or override existing ones. If you are interested in having direct control over that you can use moonlight library BlockSetaAPI.addBlockTypeFinder. also refer to CompatWoodType class. You can also use Every Compst API to register your own block types to be registered in all wood types with EveryCompatAPI class

Thanks for your hints! :) I will look into that possibility to register/change the woodtype by using The API class or the Moonlight library :)
I will inform you here about my progress :D

Hey @MehVahdJukaar

I tested the wood type registration through Moonlight library and it works really good.

One issue is remaining, where you maybe could help me. :)
I don't want to use the library as a required dependency, because the wood type registration is only for compatibility purposes. I added the library only for compilation, but when the game starts without it, it crashes at startup, because the class loader try to find the inner class net/mehvahdjukaar/moonlight/api/set/BlockType$SetFinder

[02Sept.2022 12:03:18.422] [modloading-worker-0/ERROR] [net.minecraftforge.fml.javafmlmod.FMLModContainer/LOADING]: Failed to create mod instance. ModID: extendedmushrooms, class cech12.extendedmushrooms.ExtendedMushrooms
java.lang.NoClassDefFoundError: net/mehvahdjukaar/moonlight/api/set/BlockType$SetFinder
	at java.lang.Class.getDeclaredConstructors0(Native Method) ~[?:?]
	at java.lang.Class.privateGetDeclaredConstructors(Class.java:3373) ~[?:?]
	at java.lang.Class.getConstructor0(Class.java:3578) ~[?:?]
	at java.lang.Class.getDeclaredConstructor(Class.java:2754) ~[?:?]
	at net.minecraftforge.fml.javafmlmod.FMLModContainer.constructMod(FMLModContainer.java:68) ~[javafmllanguage-1.19.2-43.1.3.jar%23184!/:?]
	at net.minecraftforge.fml.ModContainer.lambda$buildTransitionHandler$10(ModContainer.java:121) ~[fmlcore-1.19.2-43.1.3.jar%23187!/:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) [?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1796) [?:?]
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) [?:?]
	at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) [?:?]
	at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) [?:?]
	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) [?:?]
	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) [?:?]
Caused by: java.lang.ClassNotFoundException: net.mehvahdjukaar.moonlight.api.set.BlockType$SetFinder
	at jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641) ~[?:?]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:520) ~[?:?]
	at cpw.mods.cl.ModuleClassLoader.loadClass(ModuleClassLoader.java:137) ~[securejarhandler-2.1.4.jar:?]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:520) ~[?:?]
	at cpw.mods.cl.ModuleClassLoader.loadClass(ModuleClassLoader.java:137) ~[securejarhandler-2.1.4.jar:?]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:520) ~[?:?]
	... 13 more

The classes are only used on runtime when Moonlight is loaded. I don't know why the classloader try to find this class. Maybe because it is an inner class of the superclass of Moonlight's WoodType?

Here is my code: cech12/ExtendedMushrooms@745ef49#diff-e5e11a1038ec149d92f3b47b7d773322bef4dfe5e95cf8888352c4b0b23e6ea4

When I call BlockSetAPI.addBlockTypeFinder(net.mehvahdjukaar.moonlight.api.set.wood.WoodType.class, null); the game starts without errors. But when I use it with the created finder, the crash happens. :/

Ahhh, nice trick! ^^ I will try it :)

Oh awesome. So to add optional dependencies all you need to do is put that code you have in one of your own class and then class load that class only if the mod is installed so use ModList.get().isLoaded

That worked! :) Thanks for your help and time!
I released my 1.19 update and I will recommend your mod for wood type compatibility!