Fixing StarRupture "Location Is Not Stable" - Foundation Workaround Guide

Fixing StarRupture "Location Is Not Stable"

The red "Location is not stable" error is the single most complained-about building bug in StarRupture Early Access. It blocks placement of production platforms and machines even on ground that looks completely flat. Creepy Jar has rebalanced several pieces of the stability system in Update 1 (April 9, 2026), but the error is still live today and players keep running into it when they try to seed a new factory or extend an old one on anything that isn't perfectly paved.

Why the Error Fires Even on Flat Ground

StarRupture's base-building system runs an integrity pass every time you hover a building ghost. The pass walks outwards from the ghost tile and samples terrain height at each neighbour slot. If the variance between those samples goes above a threshold, the ghost turns red and the game refuses to place the structure. On paper that threshold is generous; in practice the terrain mesh on Arcadia-7 has lots of sub-metre bumps that are invisible to the eye but large enough to push the variance above the limit.

The most frustrating symptom is that the error can fire on ground you just walked over without stumbling. That happens because the stability pass does not care about slope alone - it cares about the difference between the maximum and minimum sampled height. Two tiny divots on opposite sides of the ghost are enough to produce a false-positive even when the rest of the footprint is pancake-flat. Players with 50+ hours report that roughly one in five attempted placements hits this edge case on undisturbed Arcadia-7 terrain.

On dedicated servers the check is authoritative on the host, which means two players placing the same structure at the same time will both see the same reject. A common misconception is that the issue is client-side latency; it is not. The client draws the red ghost based on a local calculation and then the server rejects the RPC for the same reason. Rebooting the server, switching peers, or flipping the host via SaveSync will not change the result.

Symptom Fingerprint

• Red ghost with the text "Location is not stable" in the centre-bottom prompt area.
• Error fires on seemingly flat savannah, dry lakebed, or pre-flattened dig sites.
• Placement succeeds one tile over, fails again one more tile over, in a chequerboard pattern.
• Error persists after mining, walking over, or jumping on the tile.
• Error disappears the moment you drop a foundation tile first.
• In multiplayer, both host and client see the same reject on the same tile.

Workaround 1: Foundation-First Building

The canonical workaround from the StarRupture community is to always place a foundation tile before placing the machine you actually want. Foundations have a much looser tolerance than production buildings because they are specifically meant to normalise uneven ground. Once a foundation is down, the follow-up machine inherits its height reference and the stability pass compares only to the foundation neighbours, not to the raw terrain mesh underneath.

This costs more resources - a foundation tile is not free - but it turns the build from a frustrating gamble into a reliable two-click operation. For production lines that must be perfectly aligned you can stamp a foundation rug under the entire line first, then place every machine on top in a second pass. On server worlds where resources are tight, pick the single-foundation approach for isolated machines and the rug approach for long lines where alignment matters more than material cost.

If you are building on a hill, drop a chain of foundations that step down the slope in single tile increments. The foundation itself can tolerate one tile of height difference to its neighbour, which means you can climb a gentle slope by stacking offset foundations in a staircase pattern. This is not just an aesthetic choice; it keeps every follow-up machine on a flat foundation-top reference surface, which is what the integrity pass actually checks.

Workaround 2: Extendable Walkways

Extendable walkways are the other pillar of the workaround set. Unlike production platforms, walkways are not counted in the integrity calculation. That means you can run a walkway across uneven terrain, across a gully, or between two elevated factories without the integrity pass ever firing. On the other side of the walkway you can start a new base grid that has its own independent stability check.

Two practical uses for this trick:

• Bridging two grids: If you have a smelter cluster on one hilltop and a refinery cluster on another, a walkway avoids dragging one giant grid across the valley between them. This is also a major performance optimisation - see our build/deconstruct lag guide - because the two grids stay independent for integrity and game logic.
• Approaching a problem tile: If the tile you want to build on keeps flashing red, extend a walkway onto it and then place a foundation next to the walkway. The walkway provides a height reference that neighbours the problem tile and often nudges the variance calculation back under the threshold.

Walkways also help when you are running a long conveyor line across rough ground. Instead of paving the entire length with foundations, pave the endpoints and the inserter nodes, and let walkways span the boring middle sections. Your belts are still fully functional, your integrity budget is only spent on the parts that actually need it, and you save a surprising amount of metal.

Workaround 3: Terrain Flattening Radius

Players often flatten the single tile they want to build on, then hit "Location is not stable" anyway. The reason is the radius: the integrity pass samples neighbours, not just the centre. If you are placing a 2x2 production platform, you need to flatten at least a 4x4 footprint, not a 2x2. Rule of thumb: flatten a border equal to one tile on each side of the structure.

Flattening tools on Arcadia-7 are not perfectly precise. The terrain deformation mesh resolves at roughly 0.5 m increments, and the stability check reads at similar resolution, which is why you can flatten a tile and still have sub-tile bumps that trip the check. Two fixes:

1. Flatten, then foundation, then machine. Even if the flattening left tiny bumps, a foundation will snap to a single clean height and erase the bumps from the variance calculation.
2. Flatten in strips. Instead of making one big depression, flatten parallel strips that each cover one line of your intended factory. Strips allow the integrity check to see a clean height transition from strip to strip instead of noisy terrain.

What Changed in Update 1

The Update 1 patch notes (April 9, 2026) do not list "Location is not stable" as a fixed bug. What Creepy Jar did address was the crash that sometimes followed a failed placement - specifically the rail junction deconstruction crash - and the main menu stability issues. The placement error itself survived Update 1 intact. Treat it as a "live bug with community workarounds" for now, and watch the next patch notes for the string "integrity" or "stability" to know when it has actually been tuned.

Update 1 did add new zipline poles and new buildable zones, and both interact with the stability system in interesting ways. Zipline poles have their own looser stability tolerance, similar to walkways, which makes them a useful way to extend infrastructure across terrain that refuses production platforms. The new late-game zones beyond the Forgotten Engine mission are hand-built with flatter terrain in mind, so players report fewer false-positive rejects there than in the starter biomes.

Decision Table

Use this table when you hit "Location is not stable" and want to pick a response without trial and error.

Multiplayer Considerations

On a shared dedicated server, stability reject reasons are logged host-side. If your crew keeps hitting "Location is not stable" in the same region, check the server log for repeated LogBuildSystem: Reject reason=UnstableLocation lines. They include tile coordinates, which you can feed back to the player so they know exactly which cell to pave. This is much faster than walking the player through "try moving one tile that way" over voice chat.

SaveSync migrations do not affect the stability state - the tile heights are stored in the save file itself - so transferring the host will not rescue a factory that refuses to grow. If you have a region of your world that consistently rejects placement, the right long-term fix is to pave the whole region with foundations once and build the future factory on top of that pre-paved footprint.

Community Discord channels and the Steam discussion threads both contain player-shared save files that demonstrate pre-paved factory templates. Loading one of those saves into a test server is a fast way to see what a "stability-safe" layout looks like before you commit to one on your main world.

FAQ

Next Steps

• Plan your factory layout
• Avoid build/deconstruct lag on big bases
• Server configuration reference

Sources

• Steam Discussions - "Please, I'm begging you to fix this already !!!!!" (Location is not stable thread)
• SteamDB - StarRupture UPDATE 1 patch notes (April 9, 2026)
• Steam Discussions - Game freeze and FPS drop report with workaround details