Abiotic Factor sandbox settings: build a balanced preset safely

Define balance before changing a value

A balanced preset is not one fixed list of numbers. It is a ruleset that keeps the parts your group enjoys while reducing a specific source of friction. One group may want the standard survival economy with slower enemy pressure. Another may want normal combat with less inventory sorting. Those goals require different changes even if both groups describe the result as relaxed.

Write a one-sentence goal before opening the file. A useful goal names the problem and the protected system: “reduce repeated material runs while keeping night power and enemy combat at their defaults.” That sentence supports a clear choice: change the inventory or loot system, but leave combat and power alone. “Make the game better” gives no way to tell whether the preset worked.

The official default starts with [SandboxSettings]. Among the documented defaults are LootRespawnEnabled=False, PowerSocketsOffAtNight=True, and multiplier values of 1.0 for enemy spawning, enemy health, enemy damage to players, player XP gain, item stack size, and item weight. A value of 1.0 is therefore the comparison point, not an instruction to raise every multiplier.

Use a one-system preset

Change settings that answer the same problem, then test before crossing into a second system. This avoids a common failure: enemy health, spawn rate, player XP, stack size, and loot behavior all change together, so nobody can explain why the new save feels worse.

1. Copy the current SandboxSettings.ini and give the backup a date.
2. Record the default or current values for the system being changed.
3. Change the smallest number of keys that can test the written goal.
4. Reload a local save or restart the dedicated server as the source instructs.
5. Test one repeatable situation, such as an ordinary supply route or a known encounter, without changing equipment at the same time.
6. Keep the change only if the observed result matches the goal and does not erase a protected system.

For example, a storage-focused test can adjust stack size while keeping item weight at its current value. That separates “fewer stacks” from “lower carry cost.” If both change together, a route may feel easier, but the group will not know which setting caused the improvement.

Preserve important dependencies

Some options affect a larger loop than their short labels suggest. The official Sandbox Settings page explains that disabling night socket shutdown removes the need for batteries and may be required for a night-only cycle. That means the power option is also a base-design choice. Likewise, enabling loot respawn can change resource gathering and may produce intersecting or floating objects; it is not merely a convenience switch.

Before accepting a change, trace its effect through three steps:

This is why the page does not label maximum values as a ready-made “hard” or “easy” preset. The documented range tells the file what it accepts. It does not tell every group what will preserve its preferred pacing.

Build three preset layers

Keep a named base layer, one experiment, and one rollback copy. The base layer contains the last ruleset the group agreed was stable. The experiment changes one system. The rollback is an untouched copy stored outside the active world folder. This structure makes comparison easier than keeping files called settings-new, settings-new2, and settings-final.

Use a short change card beside each experiment:

The Sandbox Config Builder produces a reviewed eight-key block. Use it as a transcription aid, not as an automatic replacement for a longer existing file. If the active file contains other keys, replace only matching lines unless the official instructions for that version say otherwise.

Validate the generated file

First confirm syntax. The section header must be present, documented key names must be spelled exactly, Boolean values should follow the published True and False form, and decimal values should use a period. Then confirm behavior. Seeing a valid-looking text file does not prove that the server loaded the file from the correct world folder.

Run one observable check. If loot respawn was the only change, do not use enemy difficulty as evidence. If night sockets were changed, inspect a known powered device during the relevant part of the cycle. If a multiplier was changed, compare the same route state rather than a different sector with different equipment.

Do not infer an exact hidden formula from one observation. A sandbox multiplier can interact with progression, dynamic difficulty, available equipment, or the specific system it scales. The purpose of the test is to confirm that the intended setting loaded and that the group accepts the result.

Recover from a bad preset

Stop changing values when the result no longer maps to the experiment. Shut down the server before restoring the known-good file, keep the failed copy for comparison, and return only the changed system to the last accepted state. If the save itself behaves unexpectedly, preserve it before attempting another configuration edit.

Common recovery errors include restoring a backup to the wrong world, overwriting the only known-good copy, and changing several more values to “compensate” before the original cause is identified. A clean rollback is more useful than a fast sequence of unrecorded guesses.

Completion checklist

A balanced preset is ready when the following statements are true:

• The active file begins with the required section header.
• Every changed key exists in the current official settings reference.
• The previous file and world state have recoverable copies.
• One named system changed and protected systems were checked.
• The group can explain the reason for each non-default value.
• The test result was observed in the loaded world, not only in the text file.
• A rollback was tested or its exact location was recorded.

The settings catalog will change as the game changes. Re-open the linked source after updates and treat any removed, renamed, or newly documented key as a new test. This workflow remains useful because it separates source facts, group preferences, and observed results instead of blending all three into a preset that cannot be audited.