■ Your Discord ID or other contacts

MozarteanChaos (discord username)

■ Dragon Survival version and Modpack version (if have)

DragonSurvival-1.19.2-1.5.57

■ Single game or server?

Single (Default)

■ Do you delete old configs before writing a bug report?

I always delete configs

■ Bug Description and Reproduce

Description: Every time a world is opened, the mod corrects that world's server config, even if nothing in that config has been changed. This sometimes causes the game to crash, although it's pretty inconsistent.
The game also fails to close when crashing this way, requiring the user to close it manually.
This first happened in my larger modpack, but the files attached are from when I tested it with only Dragon Survival and GeckoLib.
I think this may be related to the problems I keep having with changing what each type of dragon can eat, since that's controlled by the server config, but I don't have enough technical knowledge to test that...

Steps to reproduce: Create a new world, or open one you've already made.
Possibly observe Minecraft crashing while trying to open the world.
Check the latest log file for the mod correcting the server config.

■ Expected behavior

I expect the mod to leave its server config files alone if there's nothing wrong with them, and to not crash the game when it tries to correct problems with them.

■ Crash Report File and Logs

latest.log
crash-2023-08-10_23.08.55-server.txt

Update:
ed28158 seems to have stopped this from happening when loading a world that already exists, but not when making a new one. I think this implies some kind of issue with the process of automatically editing the config, but I don't know enough about how that works to provide any useful information, aside from some more logs.

I'm glad to see the issue's closer to being fixed, though! The update also fixed the problems I kept having with my edits to the server config file not being applied properly, so that's a nice bonus.

Here's the new log:
2023-08-22-1.log

Edit: I'm very sure the issue still exists, I experienced on an up-to-date version, but I've spent over an hour so far trying to make it happen in a controlled environment and it's not cooperating. I'll keep trying, but if anyone's wondering why it's taking me a while to get new logs... that's why.

Edit 2: I've been here for almost two hours. I might try again later, but for now, I'm just going to post the log file generated when the bug happened in my main modpack. Sorry, I know it's far from ideal, but I'm way too tired to keep going right now.
Unfortunately, despite what the log claims, a crash report was not generated when this happened, so I don't have one this time.

The general correcting is something that comes from forge itself since the config file gets created when you create a new world
(unless you placed the server config in the defaultconfig directory)

the problem is a second correcting from a different thread due to an incorrect config value, see ca17cc9

undergarden:ditchbulb:5,6 -> undergarden:ditchbulb:5:6

The general correcting is something that comes from forge itself since the config file gets created when you create a new world (unless you placed the server config in the defaultconfig directory)

the problem is a second correcting from a different thread due to an incorrect config value, see ca17cc9

undergarden:ditchbulb:5,6 -> undergarden:ditchbulb:5:6

Huh, good to know.
I do wonder why it so inconsistently caused a crash, but I guess some things just work strangely. Computers are weird, I dunno.

Anyway, if that ends up fixing the issue (as far as you can tell, at least; with how inconsistent the crash is, I can't really expect anyone to sit there testing for hours just in case) then I'm cool with this issue being closed 👍

I take it it was the forge itself that broke something? Because this config with this erroneous value has existed since February of this year. f8db348

Is this line necessary? The unnecessary crashes on something that works is not something that I and other users would be happy to see

previously there was no real check whether a config entry is valid or not
(and the check was skipped for certain entries like dragon food)

that changed with ed28158 (it still uses the forge way of validating configs)

forge probably does not expect invalid config entries within the default config which is why this problem can happen

yes

you dont want random gibberish in a config (this could lead to other issues) and if they edit it through any ingame config editor they will not be able to input wrong values anyway (only if they edit the file directly)

this is a problem of broken configs (and the default shipped configs will be fixed with ca17cc9)

to add on to this:
you will have to either check the values of the config everytime you use them or blindly trust it (which would lead to a crash if there is some wrongly formatted entry) (meaning you either always crash or you have a check anyway)

using the forge supplied way of checking whether a config is correct or not is the best way to do it as you can leave it to forge on what to do (i.e. correct the config, aka remove problematic entries)

If I remember correctly, this problem has been resolved. Will reopen if not fixed