Match this symptom
A setting appears to do nothing, resets after startup, or was placed in the wrong configuration file or section.
The answer first
Identify the setting's correct home before editing it: command-line argument, GameUserSettings.ini or Game.ini. Stop the server, back up the files, make one change with the exact documented section and syntax, then verify the effective value after restart.
The three configuration layers
- Launch arguments choose the map and process-level options such as ports, session identity and startup behaviors.
- GameUserSettings.ini contains the [ServerSettings] section and many server, session and rate options.
- Game.ini contains gameplay rules, engram overrides and other arrays or class-based settings.
- A value in the wrong file can be ignored without producing an obvious error.
Safe editing procedure
- 1Use a server save command or maintenance window, stop the process, and back up ShooterGame/Saved plus both configuration files.
- 2Copy the exact option name, capitalization and expected value type from the current reference.
- 3Place it in the documented file and section. Keep only one active definition unless the option is explicitly an array.
- 4Start the server, check logs for parsing warnings, and verify the result in a controlled session.
- 5If it fails, roll back the single change. Do not compensate with several unrelated values.
Common reasons a setting resets
- The server manager writes its saved UI value at startup and overwrites a manual edit.
- The edit was made while the process was running and the server wrote its in-memory value during shutdown.
- The setting belongs in a different file, section or launch argument.
- The same option appears twice and the effective occurrence is not the one you changed.
- A game update renamed, removed or changed the permitted value.
Keep an audit trail
Record the old value, new value, date, server version and expected result. For rates and breeding settings, note a concrete in-game measurement. That turns a large ARK configuration into a set of reversible experiments.
Determine which layer is rewriting the value
Take a checksum and modification time for GameUserSettings.ini, Game.ini, and the launch definition after the server is stopped. Start once with the management UI closed, then compare them before and after a normal shutdown. A changed file reveals a writer or generated setting; an unchanged file with ignored behavior points instead to the wrong section, option syntax, precedence, or an unsupported current-build value.
Use a harmless, measurable test and preserve arrays exactly. ARK array settings can require repeated entries or specific class paths, so deduplicating them like scalar keys can change meaning. If a server manager owns the setting, change its stored model rather than hand-editing the generated file. Keep the last known-good config and ShooterGame/Saved snapshot so reverting one experiment never becomes a map rollback.
When a value can exist both as a launch option and in an INI, record both before deciding which one won. Remove or change only one definition on the private test copy, then confirm the effective runtime value. This avoids 'fixing' a file that is correctly being overridden by the documented process-level configuration.