StarRupture Large Base Build & Deconstruct Lag - Grid Split Guide

Eliminating StarRupture Build & Deconstruct Lag

Once a StarRupture factory gets past a few hundred connected tiles, every single build or deconstruct action triggers a lag spike that freezes the game for a fraction of a second. On big bases that spike turns into a full multi-second freeze, and on dedicated multiplayer servers every connected client stutters at the same moment. This article explains why the lag happens, what the thresholds actually are, and how to refactor your base so the problem disappears without tearing everything down.

Why Build and Deconstruct Freeze on Big Bases

Every production platform in StarRupture participates in two expensive graphs: the integrity graph, which determines whether a given tile is allowed to exist given its neighbours, and the power/logistics graph, which determines how resources flow through connected belts and pipes. When you place a tile, both graphs must re-solve for the region around the new tile. When you deconstruct a tile, both graphs re-solve for an even bigger region because the solver has to confirm that everything downstream of the removed tile is still reachable.

On small factories this happens in one frame and you never notice. But the graph solver is single-threaded, and the cost grows roughly linearly with the number of connected tiles. Community timings on Update 1 (April 9, 2026) builds show a clean elbow around 400-600 tiles, beyond which every action carries a noticeable freeze. By the time a base is at 1500+ connected tiles, build/deconstruct freezes are long enough to break immersion and can time out some client RPC calls entirely.

The key word is connected. Two factories of 800 tiles each behave completely differently depending on whether they share a single tile: if they are bridged, the solver treats them as one 1600-tile graph and every build action is slow; if they are bridged only by extendable walkways (which do not participate in the solver), each factory's solver runs independently and stays fast.

Symptom Fingerprint

• Placing or removing a tile causes a 0.5 to 4 second screen freeze.
• Freezes get longer as the base grows.
• Save operations freeze the game for several seconds.
• On a dedicated server, every connected client stutters at the same moment as the host or building player.
• RCON or admin console commands that build tiles are slower on big bases than on fresh saves.
• Frame times recover instantly after the build action completes.

Measuring Your Grid Size

Before you redesign anything, measure. Run the console command stat game on a client attached to the server, then build or deconstruct a single tile somewhere in the factory. The spike you see in the Frame counter is the solver cost, and the GameThread row will show which subsystem paid for it. If the spike is dominated by BuildSystem_Rebuild or IntegrityGraph, the solver is your bottleneck; if it is dominated by NetDriver, you are seeing replication cost, and the fix is different.

Admins with access to the dedicated server log can search for LogBuildSystem: Solve duration= lines, which are printed after each build action. Values under 50 ms are harmless; values above 200 ms start producing client stutter; values above 1000 ms are the ones that freeze connected clients long enough to trigger heartbeat timeouts.

Fix 1: Split Into Independent Grids

The single biggest win is splitting one giant factory into several smaller ones connected by walkways. Walkways do not participate in the integrity or logistics solver, so they let you physically walk and transport items between two base sections while keeping those sections as independent graphs. Two 500-tile factories joined by a walkway are much faster than one 1000-tile factory, and the player experience is almost identical.

Practical approach:

1. Identify natural break points in your factory: the boundary between smelting and assembly, the boundary between raw-resource storage and finished-goods storage, or anywhere a belt could be replaced by a short walkway trip.
2. Replace the single tile that connects the two sections with a walkway.
3. Where belts cross the break, use a drop-off chest on each side connected by short belts to the break tile. Items cross the gap in a chest-to-chest hand-off.
4. Verify that each section is independent by opening the power overlay: the two sides should show separate power graphs.

This is not a full factory rebuild - you are changing maybe five to ten tiles. The reward is that every build action in either section now runs at the speed it would if the other section did not exist.

Fix 2: Trim Empty Filler Platforms

The community has repeatedly found that empty platforms are the biggest contributor to the tile count. Players use them as floor fillers or as aesthetic paving, but they count toward the solver the same as a machine platform. Every empty tile you remove shortens the solve time for every build action in the same grid.

Fast wins:

• Replace purely decorative floor fillers with extendable walkways. You keep the visual continuity and the ability to walk through the area, but walkways are outside the integrity/logistics solver entirely.
• Remove unused "spare capacity" tiles at the edge of the factory. If you paved a 10x10 region but only used half of it, the other half is still in the solver.
• Consolidate scattered storage into a single storage cluster. Ten small storage tiles in ten places add more solver work than one larger consolidated storage.

A good rule of thumb is that your tile count should be close to machines + inserter nodes + required conveyor tiles, with very few additional filler tiles. Every tile above that count is pure tax on every build action.

Fix 3: Rail and Zipline Transport

Update 1 introduced zipline poles, which are an excellent way to move players and items between remote grids without paving the entire path. A zipline pole is a small node that does not contribute to the integrity solver of either endpoint; the ziplines themselves are lightweight. Combined with walkways, ziplines let you build regional specialisation - a dedicated smelting valley, a dedicated research mesa, a shipping port - without ever connecting them into one giant grid.

Rails behave similarly for items: they move large batches between grids with much less solver tax than conveyors, because rail posts do not tightly couple the two endpoints into the same integrity graph. If your factory has a long belt feeding a remote processor, replacing that belt with a short rail will both reduce solver cost and scale better with content size.

Multiplayer Impact on Dedicated Servers

On a dedicated server, the integrity solve is authoritative on the host. When a client builds or deconstructs a tile, the host runs the solver, then replicates the result to every client. If the solve takes 1500 ms, every client sees a 1500 ms freeze. That is why you occasionally see the whole crew stutter at the same moment when one player is adding to a big base.

Worse, long solves can trigger client-side heartbeat timeouts on less-forgiving connections. A player with 150 ms ping who loses four seconds to a build freeze has a real chance of dropping out of the session with an EOS session timeout. That player then needs to rejoin and may see a stale server record (see the EOS connection guide) if they reconnect too fast.

The fix is the same as the single-player case - split the grid - but the reward is bigger because you are rescuing the whole crew's latency, not just one player's frame times. If you run a Supercraft-hosted server for a crew that spends most of their session on base-building, the integrity solver is the single biggest performance factor, far ahead of CPU clock speed or RAM.

Fix 4: Batch Deconstruction Strategically

Deconstruction is more expensive than construction. When you remove a tile the solver has to confirm that every downstream node is still connected through an alternative path, which is a more expensive traversal than adding a single edge to the graph. If you need to remove a lot of tiles from a big base, doing so during peak play hours guarantees long freezes for everyone.

Two strategies help:

1. Schedule big deconstructions during empty hours. If your crew is EU-primary, run the teardown late at night when only one admin is online. The freeze still happens but it does not disrupt a full squad.
2. Deconstruct from the outside in. Start at the edge of the region you want to remove and work inward. Each removal shrinks the connected graph slightly, so the next removal is marginally cheaper. This compounds for dozens of tiles.

For very large teardowns (clearing an entire obsolete assembly line), the cheapest option is often to save, clear via admin console, save again. The server reload resets the graph to the new state without running the incremental solver for each removed tile.

Decision Table

FAQ

Next Steps

• Factory automation patterns
• Handle "Location is not stable"
• Match hardware to your base size

Sources

• Steam Discussions - Game freeze and FPS drop thread with tile-count analysis
• Steam Discussions - "Fix for build/removal lag spikes planned?"
• SteamDB - UPDATE 1 patch notes April 9, 2026
• Steam Discussions - Performance Optimization Guide (community)