[1.20.1] Modernfix makes zeta's defective config system not work completely

[qznfbnj]

Background: Zeta's configuration system seems to be imperfect. When editing Quark configuration through the q button in the game, it will take effect immediately, but an error will appear in the log. For information about the error, refer to #3)

I found that when using the latest Modernfix, the in-game Quark configuration changes are invalid. Of course, the error in the log also disappears.
Modernfix-5.5.0: Quark configuration can be reloaded
Modernfix-5.6.0-5.14.0: Quark configuration can still be reloaded by executing /mf(s)rc manually
Modernfix-5.15.0-5.17.0: Quark configuration cannot be reloaded even with /mf(s)rc (even if all features of Modernfix are disabled)

Then I asked in TauMC discord server and get response:

That sounds like Zeta is relying on saving the config file and then hoping it automatically reloads, rather than actually changing the config values in memory

ModernFix only controls watching the config file on disk, it shouldn't break any attempts to modify the config from the game itself, unless mods are doing weird things

Then I attach these information to #3 mentioned above, and get response:

That seems like a different problem btw

[quat1024]

Could maybe be related to this crummy hack in the code that listens to ConfigChangedEvent?

Zeta/src/main/java/org/violetmoon/zetaimplforge/config/ConfigEventDispatcher.java

Lines 9 to 22 in d28024d

	public static void configChanged(ModConfigEvent event) {
	for(Zeta z : ZetaList.INSTANCE.getZetas()) {
	String modid = z.modid;
	if(!event.getConfig().getModId().equals(modid) || z.configInternals == null)
	continue;
	// https://github.com/VazkiiMods/Quark/commit/b0e00864f74539d8650cb349e88d0302a0fda8e4
	// "The Forge config api writes to the config file on every single change
	// to the config, which would cause the file watcher to trigger
	// a config reload while the config gui is committing changes."
	if(System.currentTimeMillis() - z.configInternals.debounceTime() > 20)
	handleConfigChange(z);
	}
	}

When you close the config GUI we call ForgeConfigSpec.ConfigValue.set a bunch of times in a row to commit all the changes, and I guess we wanted to ignore the event if it got fired midway through commiting those changes. Surely there is a more elegant way.