Ostranauts Systems

Ostranauts systems are best understood as connected status questions. The Steam description names fuel, air, food, crew AI needs, careers, skills, ship construction, debt, and modding data files. None of those systems lives alone: a ship decision changes a crew routine, a job changes travel and fuel, and a branch choice can change which save or mod state is safe to load. This hub gives each system a place in that chain while keeping exact thresholds and values open for current-build checks.

Survival status comes before optimization

When a run is in trouble, inspect whether the ship can keep air, pressure, power, food, and water within a usable state before chasing a better payout. The official page explicitly mentions air and food, and it describes crew AI needs including food, oxygen, water, intimacy, and security. Those categories justify a checklist of observations. They do not justify a universal number copied from an Early Access post.

Use the current interface to identify the warning, the affected crew member, the room or part involved, and the action that changes the state. If a guide says “this is safe,” it should explain what was observed and under which version. A new save, a damaged derelict, and a modded ship may produce different situations even when the same label appears.

Career and skills are planning tools

The store page describes character backgrounds, traits, and skills through a Career Kiosk. That makes the system relevant before a job begins: a crew member’s background may change which work is comfortable or risky, while a skill may matter only when a particular task calls for it. The safe article pattern is to identify the menu, explain what the screen shows, and separate the reader’s choice from any exact effect that still needs testing.

Do not turn a trait name into a tier list without knowing its current meaning. A useful comparison records the job, the crew state, the ship condition, and the reason one candidate fits the plan. This keeps the guide useful if balance changes and avoids telling a reader to chase a supposedly universal “best” background.

Money and debt are system constraints

Debt, fuel, repairs, and work form an economy of time and risk. A large payment can be less useful than a smaller job that returns the ship safely and leaves enough fuel for the next action. The official description confirms debt and fuel as part of the hard-edged space-sim premise, but it does not publish a stable table of costs or payouts. Treat those values as live observations.

Before spending, state what the expense changes. A repair may restore access to a job; a fuel purchase may enable a route; a crew expense may prevent a need from becoming a failure. If you cannot name the protected outcome, delay the purchase and inspect the current status again. That habit is more robust than a fixed budget formula.

Save hygiene matters after 1.0

The 1.0 release announcement and the later v1.0.0.9 notice are the right starting points for a version timeline. The latest notice also mentions a last_stable branch for mod compatibility. A branch is a scope boundary, not a promise that every save will load without change. Keep one clean, dated save before trying a branch, a Workshop item, or a data edit. Never use a single save as both your experiment and your only recovery point.

When a load result is surprising, record the old branch, new branch, mod state, and save date. Reproduce the smallest change possible. A report that says “this save broke” is hard to maintain; a report that names one branch switch and one mod is actionable. Until a controlled test exists, the wiki should call compatibility verification required.

Mods are also system inputs

Steam Workshop and plain-text data files are official features named in the 1.0 store and announcement material. That makes Modding a first-class topic, but it does not make every mod safe. A change can affect part names, behavior, saves, or the assumptions used by a guide. Read the Workshop description, identify the version or branch it expects, and keep a clean vanilla state before installing it.

Use the Modding pages after learning the vanilla system they change. If you cannot explain what a mod alters, you cannot tell whether a new result is an intended feature or a compatibility issue. Keep exact installation commands and file paths dated and source-backed; do not invent them from a generic modding pattern.

What needs live verification

The official material does not establish exact pressure thresholds, crew need decay, trait effects, debt schedules, control keys, branch save compatibility, or the outcome of every system warning. Those pages can be built later from a controlled test or a current same-game guide, but each result must carry the build, platform, and method. Until then, use the headings in this hub as questions to ask of the game rather than as hidden claims.

A useful systems notebook

Use one short row for each experiment: starting state, intended action, observed change, and recovery result. Add the branch and whether a Workshop item was active. This is especially helpful when a status changes after a repair, a crew member completes a job, or a save is opened on another branch. The row does not need to be a public database; it is a way to keep a guide revision tied to an actual observation.

Separate identity facts from behavior facts. AppID, developer, publisher, release label, and official announcement titles come from Steam. A claim about a part, crew reaction, or save is a behavior claim and needs a current screenshot, data file, or controlled run. Keeping those evidence types separate prevents a strong store-page source from accidentally lending certainty to an untested mechanic.

Sources

Official Steam Store page: https://store.steampowered.com/app/1022980/Ostranauts/ . Official 1.0 announcement: https://store.steampowered.com/news/app/1022980/view/507098342507576552 . Official v1.0.0.9 announcement: https://store.steampowered.com/news/app/1022980/view/507098342507576554 . Checked 2026-08-11 UTC.