Description

For the looks of it the mod does not have jsons models for its blocks, not statically at least. Every Compat relies on this. Any idea how I can make it compatible with it? Also if I might ask why arent those models there in the first place? the mod doesnt have any dynamically registered blocks as far as I remember

doesnt have any dynamically registered blocks as far as I remember

All wood, planks, stones, variants, toolsets, pots, pedestals and other things are dynamically registered. The answer on question "Why BetterEnd use dynamic models" is mineralization of assets amount. If block/item has simple model it will not have static json. However all models are accessible with game resource manager after resources are loaded

Ah I see so you have blocks being dynamically registered too? If that's the case then it's even lucky those are detected by every compat as if there were registered after it they wouldn't have been counted at all. So I'm not that familiar with the mod so on what does that dynamic registration depend on? Kind of important to know as two dtanmicly registered blocks that depend on eachother sounds like a terrible issue. Also how could I access those? I'm using the resource manager on resource reload to grab those models assuming they are in their default path but that doesn't seem to work

Ah I see so you have blocks being dynamically registered too? If that's the case then it's even lucky those are detected by every compat as if there were registered after it they wouldn't have been counted at all

All blocks are registered similar to other mods: into block registry in the main entry point. Dynamic part is that there are sets of blocks, for example set of all variants for certain wood type: blocks, slabs, doors, buttons, etc. These blocks have different material and properties, but they get procedural models and all stuff like tags and recipes automatically. However, all blocks are accessible with block registry and they have identifiers like all other blocks. If another mod is loaded after BetterEnd and request its block from registry - it will get it. BetterEnd also has a config that allows disabling registration of any block.

Some blocks like pots have dynamic blockstates as there are thousands variants of pots with different soil and plants for each stone type. Some others are just almost identical (like pedestals) and have same model patterns and recipes.

Also how could I access those?

If you mean block itself - you can use block registry as usual. If about block models - you can use this thing (mojmap):

Minecraft.getInstance().getBlockRenderer().getBlockModel(state);

It will return model for current block (blockstate), and you can get anything that you need from model. For example you can get particle texture (which will be the main texture of the block if it is something like planks). Usage example. It allows to get textures/models for any block even if it was created procedurally (for example with Fabric API, BCLib uses Fabric API to add block models). Here is a result of that example - each block has correct light calculated from its texture, and all these blocks are from BE (so they don't have any jsons):

Ok so the way every compat works is that it first scans all registered blocks and identifies all installed wood type. For this to happen there only really needs to be a plank block and a log block with a certain name and the wood type will be detected. This part already works as this step happens right after all other fabric main entry points have run.
What does not work however is the step where I dynamically generate textures for those blocks. This is done in a reload listener and to do so I'm opening and manually parsing the jsons for item models and blockstates which always are in the same location for a given block id. I use this to generate other block jsons based off that and to identify what textures the plank and log block use. That last step is the main thing that I can't do here since better end (I'm assuming) also generated those jsons dynamically so by the time I check they arent there. Now I can't just access BakedModels like you suggest while I'm generating the baked models jsons themselves as that happens of course before those models are baked.
Now unless I'm missing something there wouldnt be any solution for this apart for some direct integration code that hardcodes all those jsons.
From your end however all it would take would be to add those jsons for those blocks (planks and logs) from your own wood type. If I understood that correctly those are just dynamically registered but arent really dynamic at all meaning you always know that when you boot up your game you will have all your planks and logs from the wood types that this mod adds as the mod does not need to generated other planks and logs in other mods wood types, just its owns. This does not take into account that option you have to disable registration of them but the game does not care if you have extra models in the models directory. Also speaking of that out of curiosity how do you do that? I mean I know how to make registration depend on configs but I was told that it was a terrible idea as it would mean that a client and a server with the same exact mods installed might not be able to connect to eachother as their registry data would be different

so if all use the format you just posted for planks and logs that's all I need. I'll add a special case for it and hope it will work in most cases

Now I can't just access BakedModels like you suggest while I'm generating the baked models jsons themselves as that happens of course before those models are baked.

In example above color is generated from model inside ReloadListener, so you have access to models at that step. However, if it is not possible to implement there is another solution below:

Now unless I'm missing something there wouldnt be any solution for this apart for some direct integration code that hardcodes all those jsons.

Plank textures in BetterEnd have same name pattern, it will be always <block_name>_planks.png (in BetterNether too), so there can be simple algorithm that checks the texture directly:

1. Look for the json file, if json exists -> use json
2. Look for the texture file /<mod_id>/textures/block/<block_id>_planks.png (or <block_id>_log_side.png for logs), if it exists -> use that
3. If there are no any files with such names -> use default oak
   Logs in BetterEnd that uses complex textures have jsons, so there will be no problems with trees that have complex textures

This can also work for other mods that uses same system as BetterEnd, for example for EdenRing and BetterNether. This will probably also work for other mods as most mods use same scheme for names

Also speaking of that out of curiosity how do you do that? I mean I know how to make registration depend on configs but I was told that it was a terrible idea as it would mean that a client and a server with the same exact mods installed might not be able to connect to eachother as their registry data would be different

Yes, configs on server and client can be different, to solve that BCLib have config and mod synchronization feature (configurable), so it will warn user that configs are not identical and it can download server config version.

Most modern mods don't have configs for blocks, but we are still following old mods style where player can configure all mod content how he like, which is also very helpful for modpack developers. Some modding platforms like Forge have config sync (or at least had such feature in the past), so we created our own as a part of BClib

Thanks for building a special case for us. I will close this issue for now. If there is anything we can do, just let us know. :)