New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[1.14.3] Configs loaded so late, cannot be used to control features (item creation) #5928
Comments
You should not be using Configs to control item generation/registration |
welcome to 1.14, either use a custom config or register everything. |
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. |
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 |
|
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? |
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. |
Always register everything. And let the server admin change the recipes/advancements. 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. |
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 |
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).
The text was updated successfully, but these errors were encountered: