Tick Weave

TickWeave builds on HariMultiThread and Async to spread more Minecraft server entity work across CPU cores. It targets server tick stalls in mob-heavy worlds, multiplayer combat and new-chunk exploration. When entity work is the bottleneck, workers can take some load off the server thread. TickWeave does not accelerate GPU rendering or promise a fixed TPS or FPS gain; results depend on the CPU, modpack, entity population and world.

Unlike its upstream projects, TickWeave schedules every entity type for worker processing instead of admitting only entities marked as async-compatible. It also brings connected players' connection ticks into the same ownership scheme. Passengers and vehicles, owner-linked entities, and detected users of shared mutable data are coordinated so they are less likely to interfere with one another. This lets more work use multiple cores in busy servers, although related entities may still run together rather than all at once.

TickWeave also coordinates chunk requests between workers and the server thread, protects selected shared collections and cross-entity calls, and keeps world registration and POI storage on the server thread. When a task fails, it records diagnostics instead of silently replaying the failed entity tick. Admins can run /tickweave stats to inspect tick and worker activity, or /tickweave stats entity 10 100 to sample 100 ticks and identify costly entity types. These tools help confirm that workers are active and narrow down lag or compatibility reports.

This extends the upstream multithreading approach without guaranteeing compatibility with every mod. Parallel work can change the order in which entities run, and another mod's unprotected global state or unusual callbacks can still fail. Try TickWeave on a copy of your modpack and world, then watch actual gameplay, logs and server tick times.

What it does

• Entities and multiplayer combat: Schedules every entity type and connected-player work. Vehicles and passengers, owner-linked mobs, and detected sharers of mutable data are coordinated. General batches adjust their size using measured work cost.
• Exploration and chunks: Reuses worker-local chunk lookups and combines identical pending requests, while sending required chunk work back to the server thread. Entity-section and chunk-holder snapshots avoid repeating unchanged traversal work.
• World generation: Computes part of terrain-noise interpolation on demand without changing floating-point operation order. This path yields to C2ME, Noisium or HariChunk when installed; that does not imply universal compatibility with those mods.
• Collisions and spawning: Reduces repeated type checks only in native collision queries where the exclusion is proven safe; custom mod collision behavior keeps its normal checks. Natural spawning can run in parallel. Experimental random-tick batching is off by default, and block/fluid callbacks remain on the server thread.
• Compatibility and diagnostics: Coordinates recognized shared collections, cross-entity calls and chunk requests. World registration and POI storage stay on the server thread. Slow batches and failed tasks produce diagnostics, and /tickweave stats shows actual worker activity.

Test data: The historical Spark rows come from four real players on a Minecraft 1.20.1 / Forge 47.4.16 server. TickWeave was not installed; upstream HariMultiThread 2.0 was installed, but the server owner reported that it did not resolve the lag, which motivated TickWeave. The last two rows are local engineering tests of TickWeave's 2.1.11 CPU implementation on Java 17: four simulated players, a 180-second warm-up, then 300 seconds of mixed combat and exploration. Forge used the full test modpack; Fabric used a separate compatible workload.

In the roughly 29-minute historical Spark capture, LivingTick plus other entity ticks accounted for 65.46% of recent server-thread samples and chunk work for another 9.69%. Those shares locate work; they are not predicted speedups. Neither local TickWeave run recorded an async failure, and both saved and exited normally. The longest single tick was 397.14 ms on Forge and 339.12 ms on Fabric; connected-player worker ticks were 36,804 / 36,804 and 38,236 / 38,236 respectively. Forge's P95 was close to 50 ms, so this is not a claim of stall-free play.

Having upstream HariMultiThread installed did not solve that server's reported lag, but the surviving evidence does not show that it performed no work at all. The historical capture is therefore not a server without any entity-threading mod. Real versus simulated players, worlds, mod versions, entity counts and measurement methods also differ. These are separate observations, not a matched A/B test; do not calculate a TickWeave speedup percentage from them. The 2.1.12 release carries the same CPU implementation, but its two exact release JARs were not independently rerun through the full mixed load. The owner reported that the 2.1.12 Forge file worked on a live server; no comparable live performance figures were collected.

TickWeave supports Minecraft 1.20.1 and Java 17. Choose the file for your Forge or Fabric loader. Dedicated servers install it on the server only; single-player worlds install it on the client. Do not run it alongside Async, HariMultiThread or Moonrise, and back up your world before changing entity-ticking mods.

Warning: TickWeave is still in testing. Many modpack incompatibilities may remain, and crashes or incorrect world behavior are possible. Try it on a copy of your world first. Report problems through GitHub Issues with your loader, mod versions, reproduction steps and latest.log or crash report.

Credits: Thanks to HariMT, Axalotl, Alchemy, Bliss, FurryMileon, Grider, jediminer543 and other upstream contributors. TickWeave builds on HariMultiThread and Async; see the third-party notices for source lineage, bundled libraries and licenses.