[Incompatibilty] BetterNether wood types not combatible with anything, not even BetterEnd

[Atirtra]

Description

The problem is, BetterX mods aren't compatible with anything in the sense that mods can't easily integrate any of these mods' stuff (primarily wood types) to anything. Funny thing is, that BetterX mods aren't even compatible with each other here. For example, BetterEnd wood types can't be used for BetterNether stools and chairs, which is a huge shame.

Every Compat is a mod that counters such problems if any other mod isn't giving compatibility to another. Its author told me how there is some kind of a dynamic registration thing with BetterX here, which is why he can't implement Every Compat to these.

How important is your block registration system for BetterX functionality? Would it be possible to implement a more practical system for it, the way other mods handle it? So we could enjoy virtually infinite compatibilty with BetterX blocks.

[quiqueck]

Well, BetterNether does not auto generate the furniture items, they are just some regular models that get manually added to the mod. That is also why there weren't any in BetterEnd. So there is no dynamic registration.

The thing is, that these Objects have custom Behaviour (as they need to have in order to work properly). That means, other mods can create objects that look like our furniture, but they would just be static blocks, and not have the correct behaviour.

[Atirtra]

So there is nothing working differently to most other mods? Was EC's author mistaken so he technically could add in the compatibility?

other mods can create objects that look like our furniture, but they would just be static blocks, and not have the correct behaviour.

Though I don't understand this ^. Another Furniture also has custom behavior in it's chairs for example, but Every Compat can create new types of them fine keeping the behavior. Or does "custom behavior" mean something else than just being able to sit in the chairs?

[quiqueck]

I am not sure how they do it. But as you said, our "custom behaviour" is just sitting. So I guess they could add it with their own custom classes that enable sitting.

While our code has some convenience methods that help us to simplify the register/creation process for wood related objects (as well as building matching tags, recipes and other related stuff) it will (in the end) result in just plain old datapack files.

Here is an example for the anchor tree: Recipe, BlockState, Model, Recipe-Achievment