Reference

Common Errors & Debugging

The common early mistakes in Code: Terraform: indentation, undefined names, wrong transmit keys, None states, and power-related false negatives.

Updated 2026-10-28

Guide artwork of environmental monitoring consoles used for debugging reference
Guide artwork — not an in-game screenshot.
Advertisement

Quick answer

The earliest Code: Terraform errors are usually small and fixable: wrong component names, missing indentation after if/else or while, using a non-string transmit key, reading recipe data before analyze() has produced it, or blaming the code when the machine actually lost power. If you debug in that order, you usually find the problem fast.

A repaired Library should resume its scripts

In 0.1.36, apply the corrected Library and check the returned list of restarted scripts. Patch notes.

Before debugging an old-build failure

Update the default branch before diagnosing save failures or editor warnings from launch videos — current updates run past 0.1.28 (0.1.36, including the mid-October engine changes). Builds since 0.1.28 fix saves blocked across all routes, incorrect inherited-method diagnostics, outside edits replacing unsaved in-game work, and the wildlife reading dropping to zero after undeploying a Habitat. A corrected warning does not require changing otherwise working code.

For a missing detached editor, console or DOCS window, use Settings → Window Recovery → Reset Window Layout. For an external editor, check that external script editing is enabled; the default branch supports VS Code, PyCharm and Zed and warns about generated editor files older than the game build. Back up the colony with Export Save before changing branches.

Since 0.1.32, slots_full is on the live branch: it means every cargo slot is holding another item. Inspect those slots before treating it as target_full. Also distinguish an Automations Computer script from a machine script: an Automations script belongs to no machine and keeps running whatever the power. See patch notes for build details.

Sources: official 0.1.28, experimental 0.1.29, 0.1.32 and mid-October engine update notes, checked October 16, 2026.

Quick triage order

  1. Check that the machine is powered and you are editing the intended script slot.
  2. Check component names and target strings exactly.
  3. Check indentation under if, else, and while.
  4. Check current machine state before reading deeper properties such as self.input.recipe.
  5. Only then question the math or contract algorithm.

Every error in the table below appeared on camera in a recorded playthrough, with the cause identified in the same recording.

Errors with recorded messages

Error patternUsually meansFirst fix
expected indent at start of blockA child line under if, else, or while is not indentedFix block indentation
self is not definedself was used outside a machine script — for example in the main terminal consoleRun the line inside the machine’s own script slot
I expected string for keyThe first transmit() argument is not a stringPass a quoted key / contract ID string
cannot access recipe on noneThe lab has no specimen yet — self.input is emptyself.take_from(collector) first, then analyze
list index must be an integerA list was indexed with a non-integerIndex with 0, 1, … or loop with for site in sites
contract is not definedA variable name was used before assignmentCreate/assign it before use
requires at least one argumentA method that needs input was called bare — recorded with self.collect()Pass the argument, e.g. self.collect(target.coords)
sleep error with no numbersleep() was called without its durationPass seconds: sleep(5)
cannot compare table and numberA list/dict was compared against a numberCompare a single element, not the whole collection
unexpected character / missing parenthesisTypo or unbalanced brackets in the lineRecheck the exact line; one misplaced parenthesis broke a recorded pressure script

Power problems that look like code problems

The most misleading early-game failures are not syntax errors at all:

  • The grid drops and scripts stop. If the power system goes offline, running scripts stop making progress — one recorded session lost power mid-biology-loop and had to bring the grid back before anything resumed. A correct-looking while True script that “stopped working” may simply have no power.
  • Machines boot up offline. A recorded bio collector refused to scan with “bio collector is offline. Power it on first.” Newly deployed machines need their power/system activation before their scripts do anything.
  • Battery runs dry overnight. Solar produces nothing at night in the recorded runs; a small battery fills over roughly 16 in-game hours, and a growing base needed a second panel before recorded-session brownouts stopped.

If your code looks right, check the power tab before rewriting anything.

Silent failures: no error, no progress

Some mistakes produce no message at all:

  • Wrong component name in a repair script. Calling calibrate() logic against pressure sensor while editing the oxygen sensor’s script did nothing in one recording. Match the exact ID from the machine’s info card.
  • Script restart resets your loop. Stopping a script starts it from the top — a recorded collector loop began again at list index 0 after every stop. Plan for re-runs instead of assuming the loop resumes.
  • The machine is busy with its own script. While a machine’s script is running, manual button actions on it are blocked in the recording; stop the script if you need hands-on control.
  • Extraction with the wrong reagents loses them. The recorded lab guidance says if extraction runs with missing, extra, or wrong ingredients, they are lost and the specimen stays in the lab.

Editor facts worth knowing

  • Tab autocompletes component and method names; Shift+Enter runs the current script or console line.
  • Comments start with # — recorded sessions confirm commented lines do not affect values.
  • print with multiple values joins them with spaces; f-style strings (f"...{value}...") also work.
  • The interpreter yields time to other scripts automatically, so sleep() is optional pacing, not a required loop component.

Low-friction debugging habits

  • Keep intermediate values in named variables while learning the system.
  • Print a temporary value or branch result when you need to prove what the code is doing.
  • Split contract answer computation from transmitter delivery.
  • Read state before issuing a hardware action. This is especially important in the biology loop.

Patch note: build 0.1.22 (September 13, 2026)

The first post-launch patch reworked the console itself: the developer’s notes say console errors were made clearer, script filtering and boot-script output were fixed, and larger script operations plus generator handling were repaired. Practical effect for debugging:

  • Exact error strings you see now may be worded better than the pre-launch messages in the table above — match the pattern, not the literal string.
  • If a script silently produced nothing, re-test on 0.1.22 before assuming your code is wrong: boot-script output and filtering bugs were fixed in this build.
  • Editor-side quality-of-life landed too — better type analysis, autocomplete and performance, plus VS Code integration and other external editors with script controls and debugging.

Evidence and version notes

Every message above was observed in a recorded playthrough (closed testing and public demo builds, September 2026). Exact wording can vary between builds — the Early Access build launched September 9, 2026, and build 0.1.22 shipped September 13, 2026 with clearer console errors — so treat the pattern as the reliable part, and your build’s message as the authority. Related pages: scripts syntax reference, oxygen sensor calibration, and pressure sensor solution.