@ValidatedInt.Restrict seems to prevent the config from loading on 1.21.6
MincraftEinstein opened this issue · 7 comments
On NeoForge 1.21.6, @ValidatedInt.Restrict seems to prevent the config from loading outside the dev environment. I have multiple config classes, and only one of them uses @ValidatedInt.Restrict (the one that fails), and commenting out the config entry seems to fix it. I have not tested it with the other number types to see if they also cause this
Yeah, heres the debug log: https://mclo.gs/2g1wi4w, though looking at it, everything looks fine. "subtle_effects:general" is the config class that fails to load, but the log says it's loaded.
Also, "fc.button.notLoaded" isn't translated
Ok, so just as I was about to post this, it started working, so I restarted the game a few times to see if it continued working, and it did for a couple of times and then stopped again. So it seems to only work sometimes, I'm not changing anything between restarts.
fc.button.notLoaded is definitely translated, so some weird stuff may be happening in your production instance... (might want to look into this first; if this is acting strangely, who knows if the config behavior isn't being affected by something too)
If this is the "Not Loaded" you are referring to, this is not necessarily the config class "failing" to load, the Screen Manager for Subtle Effects doesn't see it as registered by the time that it is cached.
Also are you sure this only happens on Neo 1.21.6? I have no idea what changed with 1.21.6 that this would be an issue only now. I haven't changed anything with how Restrict or any registration works between 1.21.5 (and earlier) and .6.
I'm not sure the root cause of this in your case, but may be a race condition with whatever is first prompting Fzzy Config to prepare the screen cache. Could be something as subtle as some concurrency issue on the multimap that stores the scope upon register...
I've prepared a dev jar for neo 1.21.6 with some logging and a presumptive synchronized on the internal registration method to see if that might resolve things. Can you test with this, and
- see if things are magically fixed, and
- provide a log with the added outputs if not?
(it's inside the .zip)
To be clear, the screen cache is supposed to be invalidated when a config it originally can't find is eventually registered after the fact, which is why I suspect something involving concurrency at all.
I have loaded the game with the dev jar about 10 times, and it seems to be fixed now. I also loaded the game about 10 times with the current fabric version for 1.21.6 as well and didn't experience it there either, so it seems only have been a NeoForge issue