Threadcore

Threadcore

Vanilla Minecraft ticks your whole server on one thread. One busy farm, one mob swarm, one player
off exploring, and everything else is lined up behind it waiting its turn. You see it as MSPT
climbing and TPS falling, and usually the only fix anyone can offer you is to ask your players to
build smaller.

Threadcore splits each world into regions and ticks those regions at the same time, on a pool of
worker threads. Entities, block entities and scheduled ticks in different parts of the world stop
waiting on each other.

Minecraft 1.20.1 on Fabric, server side, Java 17.

Installing it

This goes on the server only. Your players install nothing, there is no client mod, and they do not
need to know it is there.

You need two jars, plus Fabric API. Threadcore needs threadcore-api 0.0.2 or later sitting next to
it in your mods folder. If you only install Threadcore then Fabric will not start the server at
all, it just prints requires version 0.0.2 or later of threadcore-api, which is missing! and
stops.

What actually moves off the main thread

Entity ticking, block entity ticking, and scheduled ticks, for the regions that have work in them.
That is the bulk of what a busy survival server spends its tick on.

Things that have to happen on one thread still do. A region thread never writes a block itself,
never spawns or removes an entity itself, and never reaches into another region’s chunks. All of
that gets handed to the main thread, which replays it in order, so the result is the same order of
events you would have had without Threadcore.

How it keeps your world intact

This is where nearly all of the work went, and it is the part I would judge a mod like this on.

Every operation is tagged as main thread, region thread or async, and a guard checks while the
server runs that whatever is executing is allowed to be where it is. In strict mode you hear about a
violation when it happens rather than finding a broken world later. Anything that crosses a region
boundary goes through a queue instead of happening on the spot, which covers block changes, entity
spawning and removal and damage, scheduled ticks, lighting, neighbour updates and path
recalculation. Reads that happen off the main thread see a frozen copy of the world for that tick,
so they cannot catch it halfway through a change.

There is also an audit layer that keeps a ledger of items and XP and reports anything that does not
balance. That is how I find out about a problem, rather than waiting for somebody to notice their
backpack is lighter. An entity type that misbehaves gets demoted and stops being offloaded at all.

Other mods you have installed

Threadcore’s safety comes from intercepting a specific handful of call sites and serving region
threads from those frozen snapshots instead of live shared state. Another mod that redirects the
same call site first defeats that, so Threadcore carries a registry of mods it knows about and tells
you at boot which category each one is in.

If you have another mod that also moves tick work off the main thread, like Async, MCMT or
Dimensional Threading, Threadcore refuses to arm instead of running a combination that neither mod
can make safe. Your server still boots, it just runs the vanilla tick loop until you remove one of
them.

Lithium gets a caution with the actual interaction named, which is that it redirects the entity
cramming query, and that it reads the entity cache directly if you turn its experimental item
merging option on. Keep Lithium’s experimental options off. C2ME and ScalableLux also get cautions
with their reasons spelled out. Sodium, FerriteCore, ModernFix, Krypton, Noisium, ThreadTweak and
Very Many Players are fine and say so.

The registry never guesses. A mod it does not know about is not mentioned, rather than being
vouched for, because working out from a mod id whether something multithreads is exactly the
confidently wrong behaviour this is here to prevent.

Honest status, read this before you install

This is a beta and the version string says so.

The 1.20.1 build has been running a real server of mine since September 16th, 258 mods, and that is
where my confidence in it comes from. Your modpack is not my server though, so back your world up
before you install this. That is not a formality, it moves the tick loop.

It is not a free speedup for everybody either. What you get depends on how much of your tick is
entities and block entities spread across the world. If you are bottlenecked on chunk generation, or
on one enormous farm sitting in a single chunk, or on one mod doing heavy work on the main thread,
there is not much here for you yet.

Modded entity types start out staying on the main thread until they have proven themselves, so a
heavy modpack starts conservative and opens up as types pass. Two things are off on purpose: region
random ticks, which are experimental, and owned chunk tick suppression, which would stop ice and
snow forming and lightning striking in the chunks a region owns. Everything risky has an off switch
and the defaults are the careful ones.

If something goes wrong

Put -Dthreadcore.noOffload=true on the server’s JVM arguments. That turns the parallel tick off
completely and makes Threadcore do nothing at all, so if your problem is still there with that flag
set, Threadcore is not what is causing it. It is the quickest way to find out and it is the first
thing I am going to ask you.

When you report something, include your Minecraft and Fabric Loader versions, the full mod list, and
the server log. If you can reproduce it, say whether it still happens with that flag on.