RaidBench / Once Human guides

Source-checked Once Human decision guide

Once Human First Base Checklist: Keep, Expand, or Relocate?

Use a source-bounded checklist to decide whether to keep, expand, or relocate a first Once Human base without assuming unsupported console mechanics.

Reviewed 2026-09-06Evidence-bounded Once Human guide; recheck after relevant patch changesEditorial standards

Treat your first base as a working draft: define its next job, measure the inconvenience, and commit more building effort only when the evidence points one way.

Short answer

For a first console base, keep the setup limited to the job it already performs until you can name a recurring problem or a new requirement. Compare keeping, expanding, and relocating using evidence from your own play: repeated trips, access to activities you use, space for the intended workflow, and the effort required to reproduce the setup. Expand when the current site supports the next defined need but the setup does not. Consider relocating when the location itself causes a repeated problem that outweighs the disruption under the rules shown in your current version. The supplied official evidence does not establish relocation costs, limits, or preferred locations, so confirm those details before committing.

Define the base's next job

Replace vague dissatisfaction with a concrete near-term requirement.

  • Name the activity or output the base must support next.
  • List only the facilities, storage, access, and player attention that requirement depends on.
  • Separate a current need from features that might become useful later.

Identify the repeated inconvenience

Determine whether the problem comes from the location, the setup, or an undefined goal.

  • Record the trips, access delays, layout conflicts, or repeated manual work that interrupt the intended routine.
  • Note when and where each problem occurs instead of relying on a general impression.
  • Treat an inconvenience as meaningful when it repeats under comparable conditions.

Compare keeping, expanding, and relocating

Give each option a clear decision condition without claiming a universal location.

  • Keep the base when it supports the next goal and no repeated location problem is established.
  • Test a limited expansion or layout change when the site works but the current setup does not.
  • Keep relocation as a candidate when the location itself creates the verified problem.

Check the commitment before acting

Prevent unsupported assumptions about current console rules from driving the decision.

  • Review the relocation, placement, and rebuilding information displayed in the current game version.
  • Check current official notices when the decision depends on a rule that may have changed.
  • Delay a large commitment when costs, limits, or retained structures remain unclear.

Run a limited test

Learn whether a smaller adjustment resolves the problem before changing the whole base.

  • Change the smallest area connected to the documented inconvenience.
  • Repeat the same routine under comparable conditions.
  • Keep the change only when it improves the intended workflow without creating a larger problem elsewhere.

Separate placement from production troubleshooting

Differentiate this guide from the existing production-bottleneck page.

  • Use this checklist to decide whether the site's role or location warrants a larger commitment.
  • Use the production-bottleneck guide when an established production loop underperforms.
  • Do not treat low output by itself as proof that relocation is necessary.

Decision checklist

  • Write down the base's next concrete job.
  • List the activities and routes used repeatedly.
  • Record the inconvenience that currently repeats.
  • Classify the problem as goal, setup, or location related.
  • Compare keep, limited expansion, and relocation using the same criteria.
  • Confirm current relocation rules, limits, and displayed costs before committing.
  • Test the smallest relevant change first.
  • Reassess after repeating the intended routine.

Worked example

A console beginner has a compact setup that covers current needs but dislikes the location after several sessions. Instead of moving on instinct, they name the next goal, record which trips or access problems actually repeat, and compare the current site with a candidate using the same criteria. The review shows that the location still supports the near-term goal and that the main problem is an untidy layout. They reorganize only the affected area, keep the rest unchanged, and revisit relocation after checking the current rules. If the repeated problem had been tied to the location itself, a move would remain a candidate rather than an automatic answer.

Common mistakes

  • Expanding before defining what the added space must support.
  • Treating an untidy layout as proof that the location is wrong.
  • Moving because of a single inconvenient trip.
  • Comparing locations with different criteria.
  • Assuming relocation rules or costs from an older version.
  • Changing the location and production setup at the same time.

Frequently asked questions

Should I relocate my first Once Human base immediately?

Relocate only after identifying a repeated location problem and confirming the current rules shown for your platform and version. If the existing site supports the next goal, keeping it compact preserves flexibility while you gather better evidence.

What if the base feels too small?

First decide whether the constraint is the site's location or the current layout. If the location supports the intended activities, test a limited layout change or expansion under the rules available in your game before considering a move.

How can I compare candidate locations without an exact ranking?

Use criteria you can verify in your own play, such as repeated access needs, the intended base role, observed interruptions, and the effort required to reproduce the necessary setup. Apply the same criteria to every candidate.

Does version 3.0.5 change base placement or relocation?

The supplied version 3.0.5 evidence records update and bug-fix activity but does not establish a change to base placement, expansion, relocation, costs, or limits. Check the current official notice and in-game information before relying on a version-specific rule.

When should I use the base production bottleneck guide instead?

Use it when the location decision is settled but an established production loop produces less than expected. This first-base checklist addresses commitment, placement, and expansion timing rather than diagnosing throughput.

Sources and review notes

E-01 establishes the beginner console placement question as demand context only. E-02 supports the bounded patch note but not base mechanics. Existing inventory excerpts were used solely to distinguish this first-base commitment checklist from the published production-bottleneck guide.

Prepared with an automated research workflow and published only after evidence and policy checks.