Satisfactory "Preparing a New Game" Explained

Satisfactory "Preparing a New Game" Explained

You start a fresh Satisfactory dedicated server. The client connects, the server shows up, and then the menu sits on "Preparing a new game" for what feels like forever. Most of the time, nothing is wrong. Satisfactory is built on Unreal Engine 5 and the first boot includes shader compilation, level streaming, save bootstrap, and a one-time texture decompression pass. Three to eight minutes on first boot is normal.

This page explains what "preparing" actually does, the log line that means "ready", and the conditions where you should actually intervene.

What "Preparing a new game" is doing

When the server boots a save it has not loaded before (a brand-new save, or a save loaded after an engine update), it walks through this sequence:

1. Engine init (seconds): UE5 modules load, Vulkan/RHI initialises.
2. Shader compile / pipeline cache (often the longest step): the first time a particular GPU vendor pipeline cache is missing, the server compiles a chunk of pipelines synchronously.
3. Sublevel streaming (multiple seconds per sublevel): the world's persistent and streaming sublevels load.
4. Save deserialization: the .sav file is read into memory and reconciled with the loaded world.
5. Subsystem warmup: power circuits, conveyor belts, train networks, and the auto-save subsystem all initialise.
6. "Ready" signal: the server logs the line below and the client UI flips from "Preparing" to in-game.

The log line that means "ready"

You do not have to guess. The dedicated server writes a deterministic log line the moment it considers itself ready for play:

LogServer: Display: Server startup time elapsed and saving/level loading is done,
  auto-pause is allowed to proceed from now on (if enabled in server settings).
  WorldTimeSeconds = 57005.15

Until that line lands, the client UI will say "Preparing a new game". After that line lands, joining should succeed within a second or two. If you are tailing the server log and you see this line, the server is genuinely ready, and any remaining "Preparing" state is a client-side cache the client is clearing on its own.

Where the logs are

On a Supercraft node:

stf/process-control/stdout.log    # main server stdout, grep for LogServer
stf/process-control/stderr.log    # errors, OOM, crash dumps
stf/FactoryGame/Saved/Logs/       # FactoryGame's own log rotation
stf/FactoryGame/Saved/SaveGames/server/   # .sav files

The "ready" line appears in stdout.log. To watch it in real time, follow the file from the panel's console pane.

How long is too long?

When it really is stuck

Signs that "Preparing a new game" is no longer normal first-boot waiting:

• stderr.log contains LogCore: Error or Fatal error.
• The supervisor records a non-zero exit (run_watch.stderr.log shows process exited with code...).
• System RAM is fully consumed and the kernel is paging hard (the server can technically be running but making no progress).
• The save file is partially written or zero-length (a previous crash mid-save).

If any of these match, stop the deployment and re-read Reading stderr.log when stdout is silent. For corrupted save files, restore the most recent .sav from backup.

Speeding up first boot

You cannot meaningfully shortcut shader compilation on a brand-new world; that work has to happen once. Things that do help every subsequent boot:

• Do not delete FactoryGame/Intermediate/ between boots: shader and pipeline caches live there.
• Keep the .sav file on the same disk as the game install (always true on Supercraft).
• Allocate enough RAM that the server is not swapping during boot. Late-game Satisfactory saves can deserialise into 6–12 GB of live state.

Hosting that doesn't re-shader on every boot

On Supercraft Satisfactory hosting the shader and pipeline caches survive restarts and engine updates, so the long first boot only happens once per major patch. Pair with dedicated server optimization for late-game performance.