An Abiotic Factor world is one folder, and that folder holds everything: the facility state, every deployable, each player's character in a PlayerData subfolder, and the world's rules in SandboxSettings.ini. On a dedicated server those folders live under AbioticFactor/Saved/SaveGames/Server/Worlds/, and the -WorldSaveName launch argument picks which one loads. That design makes two jobs easy that are awkward in most survival games. Moving a world you hosted from the game onto a server is a folder upload and one argument. And because the sandbox file sits inside the world, the rules travel with it. This guide goes through every sandbox key with its default and range, suggests settings for different kinds of group, and covers moving, backing up and restoring worlds.
For installation, launch arguments, ports and admins, see the Abiotic Factor dedicated server guide. This post assumes the server runs and concentrates on the world.
Where the sandbox file lives#
On current builds, each world carries its own sandbox file:
AbioticFactor/Saved/SaveGames/Server/Worlds/<WorldSaveName>/SandboxSettings.iniOlder builds and older guides put a single sandbox file under AbioticFactor/Saved/Config/WindowsServer/, and the -SandboxIniPath= launch argument can point the server at any file you like. If your edits seem to do nothing, the server is reading a different file from the one you are editing. The start of the server log shows which files were loaded; read it once and you will never wonder again. Reading the console covers finding that line quickly.
The file must begin with the [SandboxSettings] header, keys are case-sensitive, and booleans are written True and False. Edit it with the server stopped. Changes apply on the next start.
SandboxSettings.ini, key by key#
The values below are from the official dedicated server documentation. Ranges are what the in-game sliders allow; values outside them may be clamped or behave strangely.
Difficulty and death
| Key | Default | Range | What it does |
|---|---|---|---|
GameDifficulty | 1 | 1-3 | Normal, Hard, Apocalyptic |
HardcoreMode | False | One life per character | |
AllowIronMode | True | Allows iron mode characters | |
DeathPenalties | 1 | 0-5 | From keep everything to items destroyed |
DurabilityLossOnDeathMultiplier | 0.1 | 0-1 | Gear damage on death |
HostAccessPlayerCorpses | True | Whether the host can loot other players' corpses | |
ShowDeathMessages | True | Death notices in chat | |
FirstTimeStartingWeapon | 0 | 0-6 | From none to random |
Enemies
| Key | Default | Range | What it does |
|---|---|---|---|
EnemySpawnRate | 1.0 | 0.5-3 | How often enemies spawn |
EnemyHealthMultiplier | 1.0 | 0.75-3 | Enemy health |
EnemyPlayerDamageMultiplier | 1.0 | 0.25-3 | Damage to players |
EnemyDeployableDamageMultiplier | 1.0 | 0-5 | Damage to your base. 0 makes it untouchable |
DetectionSpeedMultiplier | 1.0 | 0.1-3 | How fast enemies notice you |
EnemyAccuracy | 2 | 0-4 | Ranged accuracy, pathetic to precise |
ApocalypticAbilities | False | Apocalyptic enemy abilities at lower difficulty | |
MaximizeEnemySpawns | False | Spawns at maximum density | |
DamageToAlliesMultiplier | 0.5 | 0-3 | Friendly fire. 0 turns it off |
Survival needs
| Key | Default | Range | What it does |
|---|---|---|---|
HungerSpeedMultiplier | 1.0 | 0-2 | Hunger drain |
ThirstSpeedMultiplier | 1.0 | 0-2 | Thirst drain |
FatigueSpeedMultiplier | 1.0 | 0-2 | Tiredness |
ContinenceSpeedMultiplier | 1.0 | 0-2 | Bathroom needs |
FoodSpoilSpeedMultiplier | 1.0 | 0-2 | Spoilage |
RefrigerationEffectivenessMultiplier | 1.0 | 0-2 | How well fridges slow spoilage |
SinkRefillRate | 1.0 | 0-10 | Water refill speed |
TaintedSinkWater | False | Sink water needs treating | |
RadiationDealsDamage | False | Radiation hurts directly |
Items, progression and building
| Key | Default | Range | What it does |
|---|---|---|---|
PlayerXPGainMultiplier | 1.0 | 0-3 | Skill levelling speed |
BonusPerkPoints | 0 | integer | Extra perk points at creation |
ItemStackSizeMultiplier | 1.0 | 1-30 | Stack sizes |
ItemWeightMultiplier | 1.0 | 0-5 | Carry weight of items |
ItemDurabilityMultiplier | 1.0 | 0.1-10 | How long gear lasts |
BaseInventorySize | 12 | integer | Starting inventory slots |
AllowRecipeSharing | True | Recipes learned by one are learned by all | |
AllowPagers | True | Pager communication | |
AllowTransmog | True | Cosmetic appearance changes | |
DisableResearchMinigame | False | Skips the research minigame | |
AllowCharacterReset | True | Players can respec | |
StructuralSupportLimit | 5 | integer | How far you can build unsupported |
PlayerFurnitureDestruction | False | Whether players can destroy furniture |
World and environment
| Key | Default | Range | What it does |
|---|---|---|---|
LootRespawnEnabled | False | Loot comes back over time | |
PowerSocketsOffAtNight | True | Facility power cuts at night | |
DayNightCycleState | 0 | 0-2 | Normal, always day, always night |
DayNightCycleSpeedMultiplier | 1.0 | 0.1-3 | Day length |
WeatherFrequency | 3 | 1-5 | Never to daily |
A few more keys exist - StorageByTag (default True), BridgeSupports (2, range 0-2), HomeWorlds (True) and InvisibleRadiation (False) - and their exact effect is best read from the descriptions on the in-game sandbox screen, which uses the same names. New keys also arrive with content updates. If you are setting up a server months after this was written, generate a fresh world once and compare its sandbox file with yours; anything missing from yours is simply at its default.
How the settings interact#
Most sandbox values are easy to understand one at a time and surprising in combination. A few pairs are worth thinking about together before you change either.
Needs and spoilage. Lowering hunger and thirst without touching FoodSpoilSpeedMultiplier means food rots in the fridge long before anyone needs it, and the group learns to stop cooking. If you slow needs, slow spoilage by a similar amount, or raise RefrigerationEffectivenessMultiplier, so the kitchen stays part of the game rather than a place where rations go to die.
Death penalties and durability. DeathPenalties decides what you drop; DurabilityLossOnDeathMultiplier decides what happens to what you keep. A harsh first setting with a gentle second one still punishes a player who dies far from base, because they have to walk back to their corpse. A gentle first setting with harsh durability loss turns every death into a repair bill. Pick the experience you want - a run back for your gear, or a slow drain on resources - and set both to support it.
Spawn rate and loot respawn. More enemies with finite loot means a group burns ammunition it cannot replace. If you raise EnemySpawnRate on a server meant to last, turn on LootRespawnEnabled at the same time, or the server becomes harder every week for reasons nobody chose.
Stack size and weight. Raising ItemStackSizeMultiplier without touching ItemWeightMultiplier makes a full stack heavier, which can feel like a nerf. Groups that want convenience usually lower weight slightly as well.
Power at night. PowerSocketsOffAtNight is one of the game's more interesting pressures - nights mean generators and planning. Turning it off is a large quality-of-life change for a part-time group and removes a whole layer of base design for everybody else. Decide as a group, not as an admin on their own.
The general habit: change one setting at a time, write down what and why in your server's Discord, and look at it again after a week of play. A settings file that has been edited by four people over three months without notes is a file nobody can reason about.
Settings recipes for different groups#
These are starting points, not answers. Change two or three values, play a week, and adjust.
Part-time friends
The default needs are built for people who play several hours at a stretch. A group that plays an hour after work spends half of it eating.
[SandboxSettings]GameDifficulty=1HungerSpeedMultiplier=0.6ThirstSpeedMultiplier=0.6FatigueSpeedMultiplier=0.6ContinenceSpeedMultiplier=0.5FoodSpoilSpeedMultiplier=0.7AllowRecipeSharing=TrueDeathPenalties=1DamageToAlliesMultiplier=0.0Recipe sharing matters most here. Without it, the person who only plays at weekends spends every session behind everyone else. Friendly fire off avoids the evening ending in an argument about a stray shot.
A long-running public server
The facility is finite. With loot respawn off, a server open for months is picked clean and new players arrive to empty cabinets.
[SandboxSettings]LootRespawnEnabled=TrueEnemySpawnRate=1.25EnemyDeployableDamageMultiplier=0.5PlayerFurnitureDestruction=FalseHostAccessPlayerCorpses=FalseDeathPenalties=2Halving deployable damage stops raids from undoing a week of building while keeping base defence meaningful. Turning off host access to corpses matters on a public server, where "the host" may be somebody no player knows.
A hard campaign
[SandboxSettings]GameDifficulty=2EnemyHealthMultiplier=1.25DetectionSpeedMultiplier=1.25EnemyAccuracy=3ItemDurabilityMultiplier=0.8DeathPenalties=3Leave HardcoreMode off unless everyone has agreed in advance. One life per character on a server where a disconnect can kill you is less fun than it sounds.
Larger groups than the game expects
The default cap is six players, and the economy is built for that. If you raise -MaxServerPlayers, compensate: turn loot respawn on, raise ItemStackSizeMultiplier to 2, and consider EnemySpawnRate above 1 so a dozen people still find something to fight. How many players fit on a server covers why game design, not hardware, is usually the real limit.
Inside a world folder#
Worlds/ Cascade/ SandboxSettings.ini PlayerData/ (world save files)PlayerData holds a character per player who has joined that world. Characters are not portable between worlds - a scientist belongs to one world - and when somebody joins your server for the first time, their character is created here, not on their PC. That is the opposite of games such as Terraria or Valheim, and it is worth telling people before they invest an evening in a test world.
Treat the folder as one unit. Copying individual save files between worlds produces a world that references things that do not exist.
Moving a hosted world onto the server#
A world you hosted from the game lives on the host's PC:
%LocalAppData%\AbioticFactor\Saved\SaveGames\<SteamID64>\Worlds\<WorldName>\- Have the host close the game so the world is fully saved.
- Copy the whole world folder, including
PlayerDataandSandboxSettings.ini. - Stop the server.
- Upload the folder into
AbioticFactor/Saved/SaveGames/Server/Worlds/. Over SFTP this is one drag; SFTP and the file manager has the connection details. - Set
-WorldSaveName=to the folder's name exactly, capitals included. Alternatively rename the folder to the current world name - but only after moving the existing folder of that name out of the way. - Start the server and watch the log for the world loading rather than a new one being created.
The group's characters come across inside PlayerData, including the host's. Each player picks up where they left off as long as they join with the same account they played with. Sandbox rules come too, because the file is inside the folder - check it after the move, because a world created in a single-player sandbox may have settings you would not choose for a server.
Going the other way
To take a server world back to a PC - to keep playing when the server ends, or to give it to someone else to host - stop the server, download the world folder and place it in the host's local Worlds folder. It appears in the game's world list. Do this before cancelling any server: on most hosts, deleting the server deletes its saves.
Between servers, and starting over
Moving from one host to another is the same upload with a download in front of it: stop the old server, download the world folder, upload it to the new one, set -WorldSaveName and start. Check the game version on both ends first - a world saved by a newer build may not load on an older one.
Starting a new campaign never requires deleting anything. Set -WorldSaveName to a new name and start; a fresh world is created beside the old one, with a fresh sandbox file at defaults. Stop it once the folder exists, copy your preferred SandboxSettings.ini into it and start again before the group joins, so the first session is not played on settings you meant to change. The old world stays on disk, and switching back is one argument.
Backups and restoring#
The game keeps rolling backups of local worlds in a backups folder beside the worlds, which has saved many hosted campaigns. Do not rely on the server doing the same; check whether your build writes them, and even if it does, they sit on the same disk as the world.
A sound routine:
- Nightly backup of the `Worlds` folder, kept off the server, while the group is active.
- A manual backup before every game update. Abiotic Factor is in active development and content updates are exactly when save compatibility is tested in production.
- A manual backup before changing sandbox values that alter state, such as turning loot respawn on, so you can undo the decision.
- A practice restore. Restore a backup under a different world name, point
-WorldSaveNameat it, join and check your character exists. Then point it back.
Backups that actually restore is the long version of why the last step is the important one.
On RE:NODE, -WorldSaveName and the other launch arguments are fields on the Startup tab, so pointing the server at a test world and back is two edits. Backups are taken on demand or on a schedule, stored off the machine, downloadable, and restored with one button. A Schedules entry can run a nightly backup followed by a restart as ordered tasks, and the Restart button sends a clean stop so the world is saved first. If the server reaches its memory limit it is stopped and restarted clean rather than left to swap, which is an unsaved stop - another reason the nightly backup is worth having.
Troubleshooting#
Sandbox changes do nothing. The server reads a different file. Check the log for the sandbox path, check for a -SandboxIniPath argument, and confirm the [SandboxSettings] header is spelt exactly.
An uploaded world is ignored and a fresh one starts. -WorldSaveName does not match the folder name exactly, or the files are nested one level too deep - the folder named in the argument must contain the world files directly.
Players start as new characters on a moved world. PlayerData was not uploaded, or they joined with a different account from the one they played with.
A value has no effect at an extreme. It is outside the slider range and was clamped. Use the ranges in the tables above.
The world loads but the facility is empty. Loot does not respawn by default. Turn on LootRespawnEnabled for long-running servers, and accept that existing empty containers refill over time rather than immediately.
The server crashes loading an old world after an update. Restore the pre-update backup into a spare world name and check whether it loads; if not, wait for a patch rather than repeatedly loading the original.
FAQ#
Where is SandboxSettings.ini on an Abiotic Factor dedicated server?
On current builds, inside the world's folder: AbioticFactor/Saved/SaveGames/Server/Worlds/<WorldSaveName>/SandboxSettings.ini. The -SandboxIniPath argument can point elsewhere, and older builds used Saved/Config/WindowsServer/.
Can I change sandbox settings on an existing world?
Yes. Stop the server, edit the file and start it again. Settings that affect future events, such as loot respawn or enemy spawn rate, take effect from then on rather than rewriting what already happened.
Do characters carry over when I move a world to a server?
Yes, as long as the PlayerData folder comes with it and players join with the same accounts. Characters belong to the world, not to the player's PC.
Can I use my character on someone else's server?
No. A character exists in one world only. Joining a different server means starting a new scientist there.
How do I keep two worlds on one server?
Give each its own folder under Worlds and switch with -WorldSaveName. Only one runs at a time, and the other is untouched while you play.
What should I change for a server that runs for months?
Turn on LootRespawnEnabled, otherwise the facility empties for good. Consider lowering deployable damage so raids do not undo a long-running base.




Comments
Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.