Minecraftforge: [1.14.3] Configs loaded so late, cannot be used to control features (item creation)

[Wabbit0101]

Minecraft: 1.14.3
Forge: forge-1.14.3-27.0.50-mdk

Description: The current Forge ModConfig based loading (for COMMON) occurs very late -- after block & item registration. This makes it impossible to use configuration to control what items/blocks/oregen/etc gets created. For mods that previously allowed players or mod-packs to remove featuresets (and not include the overhead of those items/blocks/events/etc including JEI masking) with config options, this is no longer possible in 1.14 with the forge config setup. The config load events are just too late.

Perhaps I'm mis-understanding how 1.14 configs should work and this is not something that is supported (i.e. write your own config if you need config loaded prior to item creation).

[DaemonUmbra]

You should not be using Configs to control item generation/registration

[Tfarcenim]

welcome to 1.14, either use a custom config or register everything.

[KnightMiner]

What I have done before is used the getSubItems method to hide it the items from creative/JEI if disabled, and also set the recipes to depend on the config property. Blocks and items are supposed to be loaded unconditionally to allow things such as the server syncing configs to the client, so writing your own config parser that loads earlier would just break that compatibility.

[Alpvax]

I'm assuming that with the flattening, there is no more getSubItems method. The recommended approach is to register everything, but just have them be impossible to obtain

[KnightMiner]

getSubItems still exists, its just called fillItemGroup now, still used to control creative tabs and for NBT item mapping. So its still a valid approach for hiding items that are unobtainable.

[Wabbit0101]

So now in 1.14 I now have to create custom conditions for recipes, loot tables, etc. that all say "only if this item is really usable" do these things (the builtin conditions check if the item exists and are config-agnostic). Also things like loot table alteration, ore generation, @ObjectHolder, etc. are also going to requires custom code to really check if an item should be used. I'm curious will mods like Quark and Cyclic Magic be forced to create everything and just not show the items?

[Alpvax]

I guess you could check that mods are loaded inside your registry events (e.g. a mod I was thinking of writing would have block which extended from another mod's class if that mod is present). I'm not 100% sure what Lex's "register everything" stance is for these scenarios.

[LexManos]

Always register everything. And let the server admin change the recipes/advancements.
If you want then you can provide a 'ModeX' data pack alongside your mod that includes the modified recipes when a item is 'disabled'.

Anyways the point is to register everything every time because it allows for the server to determine/control things better. We can easily tell if the client has the right data to connect to the server by using the registries. Client has items "A,B,C,D,E,F,G" Server A says "My World needs Items A,B,F". Client rebuilds its temporary registry and login continues. Client disconnects. Server B says "My world needs items C,D,G" Client rebuilds its temporary registry and login continue... Repeat ad infinitum

However, with the way you're proposing the Client has items "A,C,D,F", Server says "I need "A,B,F", Client explodes because it doesn't have "B".

Recipes, advancements, tags, etc.. Are all data. That can be synced from the Server to the client. Registry entry instances can not.

So, closing this as working as intended.

[Alpvax]

I understand that Lex, it has actually been what I've been saying. But what about my example of optional mod support which extends classes from another mod? What should the approach be? Have an optional compatibility mod to download instead of built in support? It isn't a registry issue, as the classes aren't there, so the client and server would actually be incompatible