After unexpected server crashes or shutdowns, drones can become "orphaned" where they exist in your save file without valid references to their home drone ports. This can prevent server loading and they create warnings in logs and the drones won't function.

In my case, I didn't notice the error until the game crashed and the server would not restart. However, I did notice in game problems with deleting and creating drones, and drones that wouldn't dock. In summary:

• Log warnings: "Drone has no home station and will not function properly"
  
• Save file integrity warnings
  
• Non-functional drones (never docking)

Here's the error:

Tool needed: Satisfactory Calculator Interactive Map [satisfactory-calculator.com]


Quick fix:

• Open the Satisfactory Calculator Interactive Map
  
• Click or drag your save file to "Click/Drop Your Save Game Here"

Save file location (Windows 11) is at:

{C:}\Users\<username>\AppData\Local\FactoryGame\Saved\SaveGames\server

This tool is not without issues, and is not ideal in that the tool causes unintended problems with the save file. After using SCIM to delete only orphaned drones, my server logs revealed missing mercer shrines, a deleted storage box, and other issues.


Look for drones not docked to any station and check for drones mid-flight. Delete the problematic drones:

• Right-click the drone
  
• Select "Delete Building"

Then download the corrected save file and rename it to match your latest autosave name.

Example: YourWorld_autosave_2.sav

Replace the corrupted save file and restart your server. Check logs.

When servers crash during drone operations, the save file can capture drones in states where their home station references are broken or missing. The game loads these objects but they're non-functional. Manual save file editing is currently the only solution.


My server logs trace the immediate crash to the drone logic: an EXCEPTION_ACCESS_VIOLATION within Windows 11. An access violation occurs in unmanaged or unsafe code when the code attempts to read or write to memory that has not been allocated, or to which it does not have access. This usually occurs because a pointer has a bad value. An access violation usually indicates that several reads or writes have occurred through bad pointers, and that memory memory might be corrupted. Thus, access violations almost always indicate serious programming errors.

A Drone object in my save file tried to execute a core function (like moving or docking), but its required link to its Home Port (`mHomeStation`) was invalid (a null pointer). The game code failed to safely check if the link was there before trying to use it, causing the entire program to be terminated by the operating system.


This isn't about simple programming mistakes; it's likely about scale and timing:

• The Root Cause: A Race Condition: My factory has dozens of drones, which is key. These crashes often start as a Race Condition—a bug where two processes conflict because they run simultaneously (e.g., the Autosave function starts writing data just as a drone is deleting/updating its port reference).
  
• The Failure Point: With massive factories and countless objects running in parallel, the chances of the unexpected crash occurring at the exact millisecond a drone object is in this unsynchronized state skyrocket. The corrupted drone is then permanently saved with a broken link.
  
• The Result: The next time the server loads, that single corrupted link causes a fatal, unhandled exception that stops the game before it can even draw the map.

This means we aren't just looking for a simple bug fix; we're dealing with a difficult, low-probability timing issue in the core game/engine serialization code that becomes a high-probability disaster on large saves.


The fix requires addressing both the runtime logic (handling deletion) and the loading logic (handling corruption).
The core issue is a dangling pointer—a field pointing to a memory address that no longer contains the expected object. In Unreal Engine (UE), this can often be prevented by leveraging the engine's built-in memory management features.

• The mHomeStation field on the \text{Drone} object should be a pointer to the \text{Drone Port} (likely an \text{AActor} or \text{UObject})
  
• Crucially: This pointer must be marked with the \text{UPROPERTY()} macro
  
• Why? When an object that is referenced by a \text{UPROPERTY} field is destroyed, the Unreal Engine garbage collector automatically clears the reference, setting the pointer to \text{NULL} (or \text{nullptr}). This prevents the dangling pointer and is the engine's primary defense against this type of crash

• If the reference should not prevent the \text{Drone Port} from being garbage collected, the \text{Drone}'s reference should be a \text{TWeakObjectPtr}
  
• Why? A \text{TWeakObjectPtr} does not keep the referenced object alive and is automatically set to an invalid state when the referenced object is destroyed, which can be safely checked using its \text{IsValid()} method

Even with the correct pointer types, code must always assume a state of corruption is possible.

• The fatal crash occurs because the code trusts the pointer before using it.
  
• Fix: Every piece of \text{Drone} logic that relies on \text{mHomeStation} must include a null/validity check.

The \text{else} block above must contain logic to safely clean up the orphaned \text{Drone}.

1. Log a warning (which is already happening).
   
2. Mark the \text{Drone} for deletion after the next game tick.
   
3. As a temporary measure, force the \text{Drone} to despawn or return to the player inventory instead of crashing the entire server.

The race occurs during the multi-threaded interaction between gameplay and saving.

• Atomic Transactions on Deletion: When a \text{Drone Port} is deleted, the entire process of finding all referencing \text{Drones} and updating their pointers must be treated as an atomic transaction relative to the save routine.
  
• This usually means acquiring a write lock on the affected \text{Drone} objects (or the system manager that holds all references) before the deletion/update, and releasing it after the deletion/update is complete. This ensures the save thread cannot snapshot the system mid-update.

The persistence of this bug offers several critical lessons about developing large-scale, persistent simulation games (see comments)