Quick answer
To repair the pressure sensor, read its live value and test whether it is even. If the reading is already even, keep it. If it is odd, add one. After that, call stabilize() with the corrected number. The cleanest starter check uses modulo 2 in an if/else block.
Working script
p_sensor = get_component("pressure sensor")
p = p_sensor.get_value()
if p % 2 == 0:
fixed = p
else:
fixed = p + 1
p_sensor.stabilize(fixed)
How the odd/even check works
The starter objective states the rule directly: corrupted readings are odd numbers, valid readings are even. Its own example is 17 → odd → add one to correct it.
p % 2 gives the remainder after dividing by two. An even number leaves remainder 0; an odd number leaves remainder 1, and that is why the check only needs two branches. Recorded raw readings were small whole numbers — 31 in one session and 11 in another — both odd, both fixed by adding one.
Unlike the oxygen repair, there is no scaling step here: you test the raw value as-is, and the final method is stabilize(), not calibrate().
The game checks your work
One recorded session shows what stabilize() actually does when it runs: the console prints a run of test readings with their verdicts — 16 even, 29 odd, 47 odd, 44 even — and then reports the sensor online when the logic handles all of them. That validation pass makes the pressure repair a good place to learn if/else: a wrong branch shows up immediately in the test output.
A compact one-line variant
The interpreter accepts conditional expressions, and one recorded session completed the repair with the whole decision on a single line:
p_sensor.stabilize(p if p % 2 == 0 else p + 1)
That recording also shows the risk of one-liners: the whole repair failed over a single misplaced parenthesis until it was fixed. If you use the compact form, build it from the multi-line version first and collapse it only once the long version works.
The reading changes between sessions
Recorded raw values differ from player to player — one base read 31, another read 11 — which is the same anti-hardcoding lesson the oxygen objective teaches. Read the live value with get_value() every run; do not stabilize a number copied from someone else’s console. If you want to see what your sensor reports before writing the logic, print it:
print(p_sensor.get_value())
Run it a few times and note the values, then write the if/else against real numbers — exactly the prove-it-first sequence recorded sessions used before committing to the final stabilize() call.
Debug it before you stabilize
If you are still learning conditions, temporarily print the current reading and your branch result. That lets you prove the if/else logic before the objective clears and moves on — exactly what the recorded sessions did before committing to the final call.
Most common mistakes
- Using
=where the condition needs==. One recorded session hit exactly this and corrected it on the spot. - Forgetting indentation under
iforelse— the recorded error message isexpected indent at start of block. - Using normal division instead of modulo to test odd/even state. Division can return many values; modulo returns only
0or1, which is what makes the two-branch check valid. - Calling the wrong final method. The pressure repair uses
stabilize(). - Aiming the script at the wrong sensor card (pressure vs oxygen names are easy to swap when repairing both in a row).
Evidence and version notes
The odd/even rule, the +1 correction, the modulo check, the one-line variant, and the validation output above are all taken from recorded playthroughs (closed testing and public demo builds, September 2026). The Early Access build launched September 9, 2026; if your build’s objective text differs, your build’s docs win. Related pages: common errors reference, beginner guide, and the component reference for the pressure sensor row. Once the opening repairs are done, the contract puzzles start with the Orbital Relay Hack - same prove-it-first habit, applied to a lock.