We're seeing a CME crash on load happening to many of our users in the new Dw20 1.19.2 pack. It's intermitten in nature but it's happened to Direwolf20 himself now on more than one occasion. Here is a debug log provided and if I can provide any additional information let me know. Thanks!
https://mclo.gs/8NGgxSB

Ok ive pushed a fix that I think will fix it if you can tell me if happens again that will be greatly appreciated

Also this crash really shouldn't happen unless another mod is modifying other mods configs as config events which this crash happened in is per mod only and not loader wide, so if you have any idea or speculation on a mod that may be editing configs let me know

Getting this problem with Resourceful Config 1.0.17 (and Ad Astra 1.12.1) in the latest ATM8 modpack version 1.0.8. When it happens on a server it causes it to hang.

• https://mclo.gs/Bo27E24

After some testing I've narrowed down the conditions to recreate it. This isn't a guaranteed failure, there is a chance that it will start up:

• The ad_astra.toml config file has not yet been created
  AND
• There are multiple other mod configs that have not been created yet

Current workarounds:

• Adding the default ad_astra.toml will prevent the problem happening
  OR
• Adding all the other missing configs will prevent the problem happening

The ad_astra.toml config is added on the failed start so subsequent starts haven't yet had this error.

Ok is it possible that you can test something for me as I am not able to reproduce it myself, can you try this version I think this one should fix it with a downside being its not very efficient https://cdn.discordapp.com/attachments/740089919338446918/1062298165434392607/resourcefulconfig-1.0.18.jar

Final tally:

1.0.18 : 0/30 failures
1.0.17 : 4/12 failures

I finally got a few fails when I went back to try 1.0.17. So yeah, seems stable now.

I gave it a go with ATM8 1.0.8 and after about 10 starts it hasn't errored yet.

I made sure to reset the configs to the modpack's base state each time. I even removed all the configs to give the error the best chance to occur.

Edit:

I have reverted to version 1.0.17 just to confirm that it still happens on the system I am testing on.

I have only had 1 failure in 8 tries. It was happening almost every time the other day on this same machine.

I think I'm going to need more than 10 successful starts with 1.0.18 to be sure it's made an improvement.

wait so I just want to make sure it hasn't happened once with 1.0.18 yet?

Perfect later today ill upload this jar officially and in the future ill see about an even more stable system