Modded stone blocks are removed from config due to loading order #247

New issue

Closed

opened 2020-08-01 14:31:13 +00:00 by import_user_oitsjustjose_95mQ · 5 comments

import_user_oitsjustjose_95mQ commented

2020-08-01 14:31:13 +00:00

(Migrated from git.oitsjustjose.com)

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.

# 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.

import_user_oitsjustjose_95mQ commented

2020-08-01 14:31:13 +00:00

(Migrated from git.oitsjustjose.com)

assigned to @oitsjustjose

assigned to `@oitsjustjose`

import_user_oitsjustjose_95mQ commented

2020-12-12 19:19:49 +00:00

(Migrated from git.oitsjustjose.com)

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 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

import_user_oitsjustjose_95mQ commented

2021-01-04 00:51:37 +00:00

(Migrated from git.oitsjustjose.com)

I am having the same problem with proPickExtras

import_user_oitsjustjose_95mQ commented

2021-03-12 04:52:04 +00:00

(Migrated from git.oitsjustjose.com)

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.

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.

import_user_oitsjustjose_95mQ commented

2021-03-12 23:51:15 +00:00

(Migrated from git.oitsjustjose.com)

Should be fixed in 0e9ff6b

Should be fixed in 0e9ff6b

import_user_oitsjustjose_95mQ (Migrated from git.oitsjustjose.com) closed this issue

2021-03-12 23:51:15 +00:00