New generated ore/wood config files cause crash on startup after being generated.
AnotherVagabond opened this issue ยท 18 comments
Issue Description
Crash on startup after the auto-generation of new wood/ore config files.
What Happens
After starting a new world, I got the message to restart after the generation of the new automatic wood and ore compatibility files. After restarting, the game crashes with a "The game crashed whilst initializing game. Error: java.lang.RuntimeException: One of more entry values did not copy to the correct id." message.
After deleting ".core.compat.Ore-custom", ".core.compat.Ore-generated", ".core.compat.Wood-custom" and ".core.compat.Wood-generated" files, the game starts up like normal, generates new files again as soon as I start the world, and then seems to run just fine until I exit the game and try to load it up again.
What You Expect to Happen
The game to not crash.
Script
N/A
Crash Log
Affected Versions
Do not use latest
; please supply accurate version numbers.
- Minecraft: 1.12.2
- Forge: 14.23.5.2838
- CraftTweaker: N/A
- Dropt: 1.12.2-1.14.0
- Pyrotech: 1.12.2-1.1.0
- Athenaeum: 1.12.2-1.17.1
Same issue here.
Small difference in Forge version, i use: 14.23.5.2836.
Happens with other mods and without other mods.
EDIT:
After some more cleaner testing, i can see that a full clean install with a restart after generating does not crash, there is some issue with mods going on.
Earlier i tested by removing all the other mods after it generated the config files.
More testing is being done.
Edit2: First tests by taking only the mods his crash and my crashed pack have in common does not cause a crash. Seems more situational. More tests going on.
Fixed it by deleting the entire pyrotech folder in the config folder.
Seems like the issue was with older config files lingering about and interfering with the new generated recipes.
Upon deletion of the old config files i did get a warning on my save that it missed some entries related to slag recipes and more.
Differences i have seen in the config files that got removed as indicated in the original issue, include:
- Iron and gold in the Bloomery.Slag-Custom json file in the broken file.
- Generated Wood json not taking modded planks in broken file, they do exist in the custom file
- Same for the Generated and Custom ores, in the broken files it did not generate them, but it did put them in the custom json file.
config.zip
Here is a zip containing both pyrotech folders, one being marked as broken and one as fixed.
The fixed one is when i completely removed the pyrotech folder to regenerate every pyrotech config file.
@AnotherVagabond Can you please post a link to the full log file?
@codetaylor Much obliged: https://pastebin.com/GQnw0J4T
@Roonas Please post a link to the FULL log file. Is this a new world? Did you delete the proper configs?
A lot has changed in 1.1.0, hence the minor version bump.
@Roonas Also, if you could please post links to your config/pyrotech/.core.compat.Ore-Generated.json
and config/pyrotech/.core.compat.Wood-Generated.json
file.
That is the full stack trace unless you want the additional fluff with it. I however crash immediately upon the client wrapping up loading processes.
configs.zip
The stack trace doesn't provide any useful information. I would like to see the FULL log file, probably located in latest.log
, not just the crash log.
ALSO: Is this a new world or an existing world that you're loading? If it is an existing world, then I would expect this crash. If it is a new world, I would not expect it.
Ah my apologies. This is a new world from a fresh install to the client. Configs were wiped as well, and should have been generated cleanly.
latest.log
The current system for wood compat leaves no room for something like ModA's input, ModB's output...
Both the input and output have to be from the same mod... which is a design oversight.
This is suspect:
[09:21:39] [Client thread/WARN] [FML]: Registry Block: Override did not have an associated owner object. Name: pyrotech:generated_pile_slag_iron Value: Block{minecraft:air}
[09:21:39] [Client thread/WARN] [FML]: Registry Block: Override did not have an associated owner object. Name: pyrotech:generated_pile_slag_gold Value: Block{minecraft:air}
That would be referring to minecraft:planks:3, as blood wood does not have it's own custom plank. Which I've just now confirmed in game. @codetaylor
Unfortunately, that is a design flaw, but not the cause of the crash. The mod would simply skip registration of that item recipe when it can't find betterwithmods:planks:3
.
The pyrotech:generated_pile_slag_iron
and pyrotech:generated_pile_slag_gold
are remnants of a previous version and I don't yet know why they're showing up in the log file.
I was mistaken. The pyrotech:generated_pile_slag_iron
and pyrotech:generated_pile_slag_gold
are not remnants.
Ok, I was just now able to reproduce this.
First I tried loading an instance over and over, adding mods indicated in the report and regenerating the configs each time, then loading with each genned config. I was not able to reproduce the problem using any combination of mods indicated in the reports.
I then tried adding back the OLD (1.0.9
and older) entries in the config/pyrotech/module.tech.Bloomery.Slag-Custom.json
which look like this:
"list": [
{
"registryName": "iron",
"langKey": "tile.oreIron",
"color": "d8af93"
},
{
"registryName": "gold",
"langKey": "tile.oreGold",
"color": "fcee4b"
}
]
This is WRONG and OLD.
The new 1.1.0
config/pyrotech/module.tech.Bloomery.Slag-Generated.json
file will show the new default values, which are:
"list": []
The 1.1.0
config/pyrotech/module.tech.Bloomery.Slag-Custom.json
file should match:
"list": []
Having entries in the slag file that are duplicates of the compat data will cause this crash.
Potential fix:
- delete
config/pyrotech/module.tech.Bloomery.Slag-Custom.json
- delete
config/pyrotech/module.tech.Bloomery.Slag-Generated.json
@AnotherVagabond @Lordician @Roonas Can anyone confirm that this solution works for them?
I fixed my issue by removing all old configs from pyrotech, so technically, i did that indeed.
I mentioned that difference in config files as well, so i am confident that the solution works.
Sorry I didn't get your message about the full log, I was out for a while. I didn't even realize there were logs in a different place, I figured the crash logs folder would have everything. I'm glad the others got here though.
Anyway, deleting the slag custom and generated worked. I hadn't deleted the other config files this time, and it started up the first time I tried. Then after generating new slag config files, it still started up afterward. Thanks so much!