Ore Generation Config Ignored

[LavaMunkee]

General Information

Describe the bug:
Ore generation changes made in the server config file are ignored

To Reproduce:

1. Set the ore generation in the server config file to false, place in the defaultconfigs folder
2. Create a new world
3. Observe the ores still being present

Expected behavior:

• Ores will still be generated as normal

Mystic Mods Versions
Druidcraft: 1.16.5-0.4.52

Other Versions:

• Forge: 36.1.24
• Minecraft: 1.16.5

[p3lim]

There are several issues here:

1. the generate_ores config option is never used in the code except for the config file itself:
   • https://github.com/MysticMods/Druidcraft/search?q=generate_ores
   • this can be (temporarily until this is fixed) remedied by setting the weights to 0
2. configuration supplied by $worlddir/serverconfig/druidcraft-server.toml is ignored, Druidcraft only considers $gamedir/config/druidcraft-server.toml
   • not sure if this is Druidcraft's fault, but all other mods I've used has no issue with this
3. FML's defaultconfigs directory doesn't copy over the *-server.toml files do the game config directory, it only copies them to $worlddir/serverconfig/, which makes managing Druidcraft config files in mod packs cumbersome.
   • the config directory also contain client configurations, which would be overridden when updating modpacks, which is why the defaultconfigs exist, and should be used, for mod packs

[noobanidus]

Yes, the generate_ores option somehow got lost in the 1.16.1 -> 1.16.2 transition (or earlier).

There are several issues here:

1. the generate_ores config option is never used in the code except for the config file itself:

   • https://github.com/MysticMods/Druidcraft/search?q=generate_ores
   • this can be (temporarily until this is fixed) remedied by setting the weights to 0

This is properly a hold-over from the port from 1.16.1 to 1.16.2 when feature generation changed dramatically. I hope to have some time to work on this and get a bug fix out.

As mentioned, you can set the weights to 0 to prevent them from generating. This is usually my preferred method as "all or nothing" disabling of ores isn't necessarily worthwhile. It might be a little extra work, but it does allow you to decide which ores you want to disable.

2. configuration supplied by $worlddir/serverconfig/druidcraft-server.toml is ignored, Druidcraft only considers $gamedir/config/druidcraft-server.toml
   • not sure if this is Druidcraft's fault, but all other mods I've used has no issue with this

This is just a filename issue. It should be "druidcraft-common.toml". Likewise the server configuration shouldn't be created but I believe that is also a hold-over; server configuration isn't loaded by the time features are being created in biomes, etc, so it's not actually possible to put these values in the server config.

3. FML's defaultconfigs directory doesn't copy over the *-server.toml files do the game config directory, it only copies them to $worlddir/serverconfig/, which makes managing Druidcraft config files in mod packs cumbersome.
   • the config directory also contain client configurations, which would be overridden when updating modpacks, which is why the defaultconfigs exist, and should be used, for mod packs

I've no idea what you're saying here, and I'm not sure you do either.

Configurations are synchronised from the server to the client as of 1.14.4 (or possibly earlier), especially for the -common configuration. Client configurations usually take place in the -client file. The latter aren't synchronised, for obvious reasons, as the server doesn't generally read them.

EDIT: If people are putting client configurations in -common.toml, they really shouldn't.

As I mentioned earlier, there's no possible way to use the server configuration (which is an invention of forge in order for people to theoretically use the same modpack with different server configurations) in world generation as it simply hasn't been loaded yet.

Thus, there's no way to take advantage of the defaultconfigs folder. Likewise, the defaultconfigs folder fails to refresh actual world instance configurations when update.

As an aside, the whole configuration system for 1.13+ was badly designed and ill-thought out. The switch to toml is fine, but the server/common segregation is unclear and mostly impossible to take advantage of as it isn't loaded when it's actually needed. Hell, it was only as of 1.16.5 (I believe) that configuration values became internally cached, meaning you previously had to cache all config values.

(This was very evident in a 1.14.4 version of RefinedStorage which clobbered system TPS by constantly treading through the Nightconfig path multiple times a tick in order to determine the maximum size of a network graph.1)

[p3lim]

I've no idea what you're saying here, and I'm not sure you do either.

Configurations are synchronised from the server to the client as of 1.14.4 (or possibly earlier), especially for the -common configuration. Client configurations usually take place in the -client file. The latter aren't synchronised, for obvious reasons, as the server doesn't generally read them.

My problem was that I set the worldgen options in defaultconfigs/druidcraft-server.toml, which never gets copied to config/ by FML, thus I have to distribute config/ as well as defaultconfigs/, which means (depending on how the client installing the modpack handles it) config/ usually gets wiped (along with the players' client configurations) in the process. This part is very bad when updating modpacks.

I assume this would be alleviated with a change to common config instead of server.