Modded stone blocks are removed from config due to loading order
Sindarin27 opened this issue ยท 4 comments
Versions
Forge Version: any
Mod Version: 4.0.21
Other Mods
Create, Quark, Mekanism, any other mod that add new blocks
Description
When blocks are added to the defaultReplacementMaterials
list in the config, there is a chance this configuration setting will be reset to the default values. This happens for any and all Create blocks, but none of the blocks added by Quark.
This appears to be a loading order problem: The config is loaded on the mod setup event. This consequentially means that only the mods registered before Geolosys will have their blocks registered, and thus be seen as a valid block for the config. A mod that loads after Geolosys has not had their blocks registered yet, and thus its blocks are not seen as valid entries. This consequentially means the entire list is reset to defaults.
I propose one of the following solutions:
-
Move the reading of the config file to another event, fired after all blocks have been registered. This might however present problems with other config settings that do have to be fired early on.
-
Move the block- and itemlists to a separate config file, that gets read after all necessary entries have been registered.
-
Use Forge block tags to automatically detect blocks. This allows for more configurability using datapacks if done right, but can be harder to configure, often requiring an extra mod to set a default datapack. This does however allow other mod authors to easily include Geolosys integration out of the box, which is a huge upside to this method.
this also applies to proPickExtras = []
everything but minecraft blocks will get removed.
I was trying to add ore veins for 1.16.4 but I got a lot of different stone layers.
One thing I learned was, that there is a special tag for world generation:
forge:wg_stone
This would likely be fixed by moving the validation of those items to when the server starts, instead of during init -- this would mean changing this config would then need a /reload
, but that's not a bad sacrifice for functionality IMO.
Should be fixed in 0e9ff6b