A useful troubleshooting process reduces uncertainty. Instead of changing RAM, Java, loader, and half the mod list at the same time, keep most variables fixed and isolate one compatibility layer at a time.
Startup crash before the main menu
Look for the first dependency or class-loading error rather than the final stack trace line. Common patterns include a mod built for another Minecraft version, an unsupported loader, a missing library, or a Java generation outside the loader’s expected range.
The game loads but Avaritia content is missing
Confirm the mod appears in the loaded-mod list and that you installed the correct branch. If items exist but recipes do not, investigate recipe viewers, scripts, datapacks, disabled recipes, and modpack-specific progression gates.
A copied world works but the main world fails
Differences in server config, per-world data, datapacks, chunk content, or removed registry entries can make an established world fail even when a new world starts. Compare the world-specific configuration and restore from backup before repeated launches.
Recipe scripts fail after an update
KubeJS or CraftTweaker APIs can change between project versions. Treat scripts as code: version-control them, test after upgrades, and read the script engine’s first error rather than assuming the underlying mod is broken.
Conflicts only appear in the full modpack
Use a binary-search mindset. Add half of the remaining mods, test, then keep the failing half. A few rounds can reduce hundreds of mods to a small conflict set much faster than removing them one at a time.
When to stop troubleshooting and restore
If a world upgrade changes registries, deletes content, or produces repeated chunk errors, do not keep opening the only copy. Restore the known-good backup and continue experiments on duplicates.
Related guides
Continue with another focused guide from the Avaritia resource library.