How to Fix an FTB Continuum Server That Keeps Crashing
FTB Continuum is FTB's automation-focused expert pack on Forge 1.12.2, built around a GregTech New Horizons-inspired recipe overhaul — long ore-processing chains, multiblock machines, and logistics networks that get heavier the further players progress. Most crash reports for this pack trace back to one of a few well-known causes rather than a single bug, and most of them are fixable without touching the world save.
See the FTB Continuum pack page for the full RAM and setup breakdown before you chase anything else.
1. Confirm you're running Java 8
FTB Continuum is a Forge 1.12.2 pack, and Forge on 1.12.2 needs Java 8 — this is a universal rule for this version era, not a pack-specific quirk. Running on a newer default JVM (11, 17, or later) is one of the most-reported causes of packs in this bracket crashing on startup or behaving unpredictably mid-session. Check your server's Java version before investigating anything else.
- Run `java -version` in the server's working environment and confirm it reports a Java 8 build
- If your host defaults to a newer Java, pin the server process to a Java 8 runtime explicitly
2. Rule out automation tick-lag as the base scales up
GregTech-style multiblock machines and large pipe or logistics networks are a well-documented tick-lag source once a base's automation scales up — this is consistent with every GregTech-inspired pack, and Continuum's whole design leans into exactly that kind of long processing chain. The symptom usually isn't an instant crash; it's rising tick times and falling TPS as more machines, cables, and item pipes get added, which eventually trips a timeout.
If a crash correlates with a specific player's base getting bigger, or with a chunk loading near a dense automation setup, tick lag from that area is the most likely explanation before anything else.
3. Check for quest-progress corruption after an unclean shutdown
Like other FTB quest-driven packs, an unclean shutdown — a hard kill, an OOM crash, a host outage, or stopping the process mid-autosave — is a reported cause of quest data corruption that only surfaces on the next boot. If the server was crashing or being force-stopped before quest-related errors appeared, that sequence is worth treating as cause and effect rather than two unrelated problems.
4. Rule out a specific mod conflict only after the above
Expert recipe-overhaul packs like Continuum stack a large number of tech and logistics mods, and any one of them can produce a crash log pointing at a specific class. Rather than guessing at a mod name, read the actual crash log's root cause line first — if the above three checks (Java version, tick lag, unclean shutdown) don't explain the crash, the log itself will usually point at the real mod involved far more reliably than a guess would.
5. RAM under the pack's realistic floor
The real floor for FTB Continuum is 8 GB. This accounts for the automation and logistics overhead this pack's recipe chains generate as a base grows — it's not a number you can reliably go below just because the modlist looks moderate on paper. Under-provisioning rarely produces a clean, instant crash; what you'll actually see is cascading lag and GC pauses as available heap tightens, followed eventually by a tick timeout that looks like a random crash but is really a slow memory squeeze.
FAQ
Why does my FTB Continuum server lag hard and then crash once my base gets big?+
This is almost always tick lag from automation scaling past what the server tick can process, not a true crash at first — a GregTech-style pack with long ore-processing chains and multiblock machines will show rising tick times as players add more pipes, cables, and processing lines. Left unchecked, severe tick lag eventually trips a watchdog timeout that looks like a crash. Check your TPS and tick time before assuming it's a corrupted save or a bad mod.
Is Java version actually a real cause of crashes on this pack?+
Yes for any Forge 1.12.2 pack, FTB Continuum included — it needs Java 8. Running it on Java 11+ or a newer default JVM is one of the most-reported causes of packs in this version era failing to start or crashing early, so it's worth confirming as the very first check before digging into mod-specific theories.
My world loaded but my quests are gone or broken — what happened?+
Like other FTB quest-driven packs, an unclean shutdown (a hard kill, a host-side crash, or pulling power/stopping the process mid-save) is a reported cause of quest-progress data corruption showing up on the next boot. Always stop the server cleanly and keep a recent backup before any risky change — if quest data does get corrupted, restoring from the backup taken before the bad shutdown is usually the fastest fix.
How much RAM does FTB Continuum actually need?+
The real floor for a stable FTB Continuum server is 8 GB. That accounts for the automation and logistics overhead this pack's recipe chains generate — going lower tends to produce exactly the gradual GC-pressure-then-tick-timeout pattern described above rather than a clean out-of-memory crash.
Host FTB Continuum on hardware sized for its real floor
FTB Continuum needs 8 GB RAM to handle its automation load without tick lag, and taking a clean backup before any risky change (updates, new mods, big builds) is the single habit that prevents quest-data corruption from ruining a session.
View Minecraft Hosting →