Chapter I, “Out of the Breach”, arrived on October 12, 2026 with Update 7, and plenty of server owners hit the same wall on restart: a server that won't boot, or mods that no longer load. This guide doesn't cover installing mods. It gives you a full troubleshooting method, from the first error message to the fix, while keeping your world safe at every step.
Why Chapter I breaks some mods
Update 7 is more than a content drop. It changes three layers that mods rely on:
- The network protocol has a new version. Client and server must match: a server still on Update 6 rejects updated players, and the other way round. No mod gets around this.
- The server API has been heavily reworked. The developer notes mention, for example,
TickProcedure.onTick, whose signature changed,WorldChunk, which no longer holds aWorld, andDurabilityOperator, now calledComparisonOperator. A Java mod (a.jarfile) built for Update 6 that uses any of these may refuse to load or crash mid-game. - Game assets changed too. The Update 7 pre-release notes list renamed keys (
ChargeAccelerationbecameChargeAccelerationDistance), glider fields moved toTemplate_Glider, IDs that no longer resolve (Spectre_Void) and even renamed PNG files, such asSpiwer_Web_Full.png, nowSpider_Web_Full.png. A pack pointing at something that no longer exists can fail validation.
One more thing: the save format changed. A world is upgraded automatically the first time a Chapter I server loads it, and an upgraded world can no longer be opened by an older version. It's a one-way trip.
Before you touch anything: back up
Stop the server and copy at least:
- the
universe/folder (your worlds); - the whole
mods/folder, including the mods' config folders; - the
config.json,permissions.json,whitelist.jsonandbans.jsonfiles.
Also write down the exact list of your mods and their versions; you'll compare it with the authors' pages. If you've already started on Chapter I, still keep a copy of the current state before changing anything, and don't keep restarting the server hoping the error goes away.
Step 1: read the logs in the right place
The console and logs almost always name the mod that's failing, as long as you look in the right place:
| Setup | Where to look |
|---|---|
| Dedicated or hosted server | The panel console, then the server's logs/ folder (one file per start, named by date and time) |
| Singleplayer world or world shared from the game | UserData/Saves/<world>/logs |
| Client-side (game) problem | UserData/logs |
Open the log from the latest start and scroll up to the first error; the ones after it are often just side effects. Search for Error, Exception and Failed, plus the name of each of your mods. On Linux, one command does the filtering:
grep -inE "error|exception|failed" logs/*.log | head -n 40On Windows, PowerShell does the same:
Select-String -Path .\logs\*.log -Pattern "error","exception","failed" | Select-Object -First 40A message like Failed to load manifest file! points to a mod whose manifest.json is missing, misplaced or unreadable. A Java stack trace mentioning a class or method that can't be found (for example NoSuchMethodError) almost always means a Java mod built against the old API.
Step 2: sort the error type
Once you've found the culprit line, classify it. The fix depends on the category.
| Symptom | Likely cause | What to do |
|---|---|---|
| Server stops on boot and names a mod | Java mod incompatible with the new API | Install the mod's Chapter I build, or remove it for now |
| Asset validation error (unknown key, ID not found) | Pack referencing something renamed or removed | Wait for, or install, the pack update |
| Mod loads but an effect no longer works | Renamed key that only triggers a warning | Report it to the author, check the log warnings |
| Mod skipped because of a dependency | Dependency missing or too old | Install or update the dependency |
| Odd behaviour, duplicated items | Two versions of the same mod in mods/ | Keep a single file |
| Players can't connect | Client and server versions differ | Match the version and the patchline |
Step 3: remove duplicates
It's the dullest cause and the one people miss most. When updating a mod, the new file gets uploaded without deleting the old one, and mods/ ends up with two versions of the same mod. List the folder and look for similar names:
ls -1 mods/ | sortIf you see, say, MyMod-1.4.2.jar and MyMod-1.5.0.jar, keep only the Chapter I build. Watch out as well for mods present both as a .zip pack and as an unpacked folder: only one should stay.
Step 4: check dependencies
Every mod declares what it needs in its manifest.json, at the root of the .jar, the .zip or the pack folder. Two fields matter here:
Dependencies: required mods, written asGroup:Namewith a version range. If one is missing or out of range, the mod won't load.OptionalDependencies: optional mods. If they're missing, the mod still loads.
{
"Group": "Example",
"Name": "MyMod",
"Version": "1.5.0",
"ServerVersion": "...",
"Dependencies": {
"Example:SharedLib": ">=2.0.0"
},
"OptionalDependencies": {}
}The classic trap after a big update: the main mod has its Chapter I build, but its library doesn't yet. In that case the main mod is useless until the dependency catches up. On download pages, the relations tab shows which dependencies are required. The ServerVersion field, when filled in, also tells you which server version the mod was released for; compare it with the output of /version.
Step 5: temporarily remove the faulty mod
If no compatible build exists, you have to decide. There are two very different cases:
The mod adds no blocks or items
UI, minimap, admin commands, management tools: you can remove it safely. Stop the server, move the file to a separate folder (for example mods-disabled/) instead of deleting it, then start again. You can also disable it in the Mods section of the server's config.json, again with the server stopped: the server rewrites its config files while running, so edits made live can be lost.
The mod adds blocks, items or creatures
Be careful here. If you remove it, the blocks it placed may show up as unknown or vanish, and the related items can disappear from inventories. Each world also keeps, in its own config, the list of mods it needs: if one is missing, the world may refuse to load. Always test the removal on a copy of the world before touching the main one. Often the best option is to keep the server offline, or open a temporary world, until the mod is updated.
To find the faulty mod quickly in a long list, halving is the fastest method: remove half the mods, start, then repeat with the half that still shows the error. With 30 mods, five restarts are enough to isolate it. Community documentation also mentions a startup option, --ignore-broken-mods, which lets the server boot despite a failing mod so you can identify it; check that your version supports it with --help before relying on it, and never use it on your main world without a backup.
Step 6: wait for (and track) the mod update
For Java mods, the fix nearly always comes from the author, who has to rebuild the mod for the new API. A few habits:
- check each mod's page and look specifically for “Chapter 1” or “Update 7” in the changelog;
- the in-game mod browser shows at a glance which mods in your library have been updated;
- don't download a “fixed build” posted by a stranger: a
.jarfile runs code on your server; - if a mod is abandoned, look for a maintained alternative instead of keeping a broken version.
Compatibility table by mod type
Not every mod carries the same risk after Chapter I. Use this table to decide what to check first:
| Mod type | Risk after Update 7 | What to check |
|---|---|---|
| Visual-only pack (textures, sounds) | Low | Files renamed in the base game |
| Content pack (blocks, items, NPCs, gliders) | Medium | Renamed or removed keys and IDs |
Java server mod (.jar) | High | A build compiled for Chapter I |
| Library shared by other mods | High | Updated before every mod that depends on it |
| Mod that generates structures or worlds | Medium to high | Test on a world copy, compatibility with the new save format |
A bit of good news along the way: with Update 7, a mod can now contain entire worlds, and a world created from a mod survives that mod's removal.
Errors that don't come from mods
Before blaming your mods, rule out these causes, also tied to Chapter I:
- Exit code 11 on a self-hosted server: the server's data sits inside the launcher's install folder. Move the server to its own folder.
MaxViewRadiuswarning: view distance is now capped at 32 chunks. The server still boots, but fix the value inconfig.json.- Players rejected: client and server aren't on the same version or patchline.
Quick checklist
- Stop the server and back up
universe/,mods/and the config files. - Read the first error in the latest log.
- Remove duplicates from
mods/. - Update dependencies before the mods that use them.
- Temporarily remove mods with no Chapter I build, testing first on a copy for those that add blocks.
- Restart, make sure the server reaches the running state, then test with a single player before opening to everyone.
FAQ
Can I go back to Update 6 if my mods stop working?
Only with a backup made before updating. A world opened by a Chapter I server is upgraded and can no longer be read by an older version.
My mod is up to date but the server still won't start. Why?
Check its dependencies and make sure there's no old copy of the same mod left in mods/. A single library still on its Update 6 build is enough to block loading.
Are texture packs affected?
Rarely, but a few base-game files were renamed. If a visual pack replaces a file whose name changed, that replacement will no longer apply.
How long should I wait for a mod update?
It depends entirely on the author, and there's no guaranteed timeline. Follow the mod's page or changelog; if it shows no activity, line up an alternative.