For a relaxed cooperative Atlas PvE group, start with XPMultiplier=2.0, HarvestAmountMultiplier=2.0, and TamingSpeedMultiplier=3.0 under [ServerSettings] in GameUserSettings.ini. This doubles experience and harvest gains and triples taming speed relative to the normal 1.0 rate. Treat those numbers as a baseline rather than a permanent “best” configuration: change one category at a time, observe how your group plays, and then adjust. Choose PvP instead of PvE only when player combat is an intentional part of the server. Keep world layout in the JSON grid files, back up before changing maps, and make sure the grid contains at least one home grid so players can join.
What are the best Atlas server settings for a small group?
The most useful starting profile for a small cooperative group is:
| Setting | Starting value | Effect compared with 1.0 | Why it suits a small group |
|---|---|---|---|
XPMultiplier |
2.0 |
Twice normal experience gain | Shortens the early grind while leaving room to unlock and use progression systems. |
HarvestAmountMultiplier |
2.0 |
Twice normal resource yield | Reduces the amount of repetitive gathering when only a few players are supplying a base. |
TamingSpeedMultiplier |
3.0 |
Three times normal taming speed | Makes acquiring creatures practical for a group that cannot stay online for long taming sessions. |
LogicServers’ worked example defines the scale plainly: 1.0 is the normal rate, 2.0 doubles it, and 0.5 halves it. The values above are therefore rate multipliers, not percentages. A value of 2.0 means 200% of the normal rate, not a 2% increase.
Do not change every gameplay variable at once. Run the profile for a few play sessions, ask whether any activity has become trivial, and adjust only the relevant multiplier. If progression feels too fast, lower the single setting responsible; if one activity remains tedious, raise that setting without changing the others.
How do XP, harvest and taming multipliers work?
All three keys use the same relative-rate idea, but they affect different bottlenecks. Keeping them separate lets you tune the server around the way your group actually plays.
What does XPMultiplier change?
XPMultiplier controls experience gain. At 2.0, activities that award experience do so at twice the normal rate. This helps a small roster reach useful unlocks without requiring one player to perform every leveling task for the group.
XP acceleration also moves players through the progression curve faster. If your group enjoys the slower discovery pace, keep XP at 1.0 and increase only harvest or taming. If everyone reaches later unlocks before the group has explored the world, reduce XP rather than slowing resource collection.
What does HarvestAmountMultiplier change?
HarvestAmountMultiplier changes how much material a gathering action produces. The recommended 2.0 value doubles the normal yield, so construction and crafting consume less real-world time for a small team.
Harvest speed and storage capacity are separate practical concerns. A higher yield can fill containers quickly, so agree on a storage and hauling routine before raising this value again. If building remains the only tedious activity, adjust harvest rather than XP.
What does TamingSpeedMultiplier change?
TamingSpeedMultiplier controls how quickly creatures complete the taming process. The baseline 3.0 makes the process three times faster than normal, which is useful when no one can remain logged in for a long session.
Taming is often the most time-sensitive of the three systems. If a three-times setting removes too much risk or preparation, lower it while leaving XP and harvest at 2.0. Conversely, a group that likes gathering and exploration but dislikes waiting can keep XP and harvest at 1.0 and raise only taming.
Which Atlas configuration file should you edit?
Atlas uses two configuration families. The Atlas Admin Documentation describes JSON and INI files as the two main types, with different jobs.
| File or family | Primary purpose | Use it for | Do not use it for |
|---|---|---|---|
GameUserSettings.ini, especially [ServerSettings] |
Cell-wide and gameplay server settings | XP, harvest, taming, PvE/PvP and other routine server controls exposed by your host or installation | Defining the overall island grid |
ServerGrid.json |
Base world and grid definition | Islands, cells, travel layout and a custom or predefined map | Routine progression multipliers |
| Cell-specific INI overrides | Settings applied to individual cells | Claim types and resource overrides that need to differ by cell | Replacing the complete grid definition |
Think of the JSON as the map’s skeleton and the INI files as the rules applied to that skeleton. A custom grid can be generated or edited with the ServerGridEditor project, while cell-specific behavior remains in INI configuration.
How do I edit GameUserSettings.ini safely?
Use the following sequence for a routine progression change. Managed hosts usually expose the same file through a web control panel; a self-hosted installation requires opening the file directly.
- Stop the server. Never edit a live configuration while the process is writing settings or saves.
- Open the configuration area. In a managed panel, choose the server’s Configuration Files section. On a self-hosted machine, locate
GameUserSettings.iniin the Atlas server configuration directory. - Find or create the
[ServerSettings]section. Keep the multiplier keys in that section so the server reads them as gameplay settings. - Add or change the exact keys. For the recommended profile, use:
[ServerSettings] XPMultiplier=2.0 HarvestAmountMultiplier=2.0 TamingSpeedMultiplier=3.0 - Save the file. Check that the editor did not add an extra file extension or convert the file into a rich-text document.
- Start or restart the server. The new values are loaded during startup; players already connected will not make a running process reread the file.
- Verify in game. Perform a small, observable action such as earning XP or harvesting a known resource, then compare the result with the intended profile before changing more settings.
Keep a dated copy of the original file before editing. If a change produces an unexpected result, restoring the prior copy is faster and safer than trying to reconstruct several edits.
Should a small group choose PvE or PvP?
Choose the mode that matches the social contract you want players to follow. The mode is a server-level rule, not a progression multiplier.
| Question | PvE | PvP |
|---|---|---|
| Is player combat enabled by the server rule set? | No player-versus-player combat as the intended rule set | Player combat is enabled |
| Best fit | Friends who want cooperative building, exploration and creature collection | A group that deliberately wants conflict, defense and competitive risk |
| Effect on progression tuning | 2x XP, 2x harvest and 3x taming are a forgiving cooperative baseline | The same multipliers can make recovery from raids faster, but may also accelerate competitive escalation |
| Administrative concern | Protect shared builds and settle ownership rules before inviting others | Agree on combat boundaries, raid expectations and dispute handling before launch |
For a private friends-only server, PvE is usually the least contentious starting point. Select PvP when the group explicitly wants player combat; do not enable it merely because the setting is available.
How do I configure a single grid or a custom Atlas map?
The world layout is controlled through ServerGrid.json, not the three progression keys. A single grid is simpler to administer; a clustered or custom grid can provide a larger journey but creates more files and migration risk.
What does a single-grid setup involve?
A single grid uses one defined world layout and is the easiest choice for a small group that wants to start playing quickly. You still need a valid home grid, and the server must point to the matching JSON definition.
When should I use a custom or clustered grid?
Use a custom grid when the group has a clear reason to change island placement, cell count or travel structure. The ServerGridEditor repository describes its tool as an example for generating Atlas JSON; use it to create or edit the grid, then preserve gameplay overrides in the appropriate INI files.
Custom layouts increase administration work. Every cell must be assigned consistently, and a malformed or mismatched JSON can prevent the server from presenting the intended world. Test a copy of the configuration before replacing the live grid.
Why is a home grid required?
Nitrado’s Atlas documentation states that a server needs at least one home grid for players to join. A map can appear correctly configured yet remain inaccessible if no cell is designated as home. Set and verify a home grid before troubleshooting client connection settings.
What should I back up before changing a map?
Changing the map is a destructive migration, not a cosmetic toggle. Nitrado notes that changing the map changes ServerGrid.json and that switching to a different map deletes the old one, so keep backups first.
- Copy the current
ServerGrid.json. - Save every relevant INI file, including
GameUserSettings.iniand cell-specific overrides. - Preserve the current Redis data and Savegame before any wipe.
- Record the current map selection, home-grid assignment and server start arguments.
- Keep the backup outside the live server directory so a reinstall or cleanup cannot remove both copies.
For a documented map migration, stop the server, install the selected map, assign the server to a grid, wipe Redis and Savegame, and then start the server. The wipe removes the old world state; treat it as a reset and tell every player before proceeding.
Which progression profile should my group use?
Start with the profile that matches the group’s available play time, then adjust one category at a time. The following profiles are tuning patterns built from the documented multiplier behavior, not official presets.
| Group preference | XP | Harvest | Taming | When to choose it |
|---|---|---|---|---|
| Normal-paced experiment | 1.0 |
1.0 |
1.0 |
You want the standard rate as a reference before making changes. |
| Relaxed cooperative baseline | 2.0 |
2.0 |
3.0 |
You want less grinding while retaining meaningful exploration and preparation. |
| Low-grind taming focus | 1.0 or 2.0 |
1.0 or 2.0 |
3.0 |
Your group enjoys gathering and progression but does not want long taming waits. |
| Deliberate slow progression | 0.5 |
0.5 |
1.0 |
You want a more demanding pace; expect every resource and level to take longer. |
The 0.5 row illustrates the documented meaning of halving a normal rate; it is not a recommendation for every group. Avoid changing from the baseline directly to several extreme values because you will not know which adjustment caused the problem.
Is self-hosting or managed Atlas hosting better for a group?
The choice is mainly about administration, not a different set of gameplay rules. Both approaches ultimately rely on the same INI and JSON concepts.
| Consideration | Self-hosted server | Managed host control panel |
|---|---|---|
| Editing settings | You stop the process and edit files on the host machine. | You stop the server and use a Configuration Files editor, with text editing available for advanced changes. |
| Grid management | You install and maintain the ServerGrid JSON and related tools yourself. | The provider may offer map selection and grid assignment controls, but you still need to understand the files being changed. |
| Backup responsibility | Your group must schedule and store copies of JSON, INI, Redis and Savegame data. | The host may expose backups, but confirm what is included and keep an independent copy before a map switch. |
| Migration risk | You control every step, including the Redis and Savegame wipe. | The panel can simplify the sequence, but a map change can still delete the old world. |
| Best fit | An administrator comfortable with files, restarts and recovery. | A group that values a guided interface and wants less server maintenance. |
Whichever route you choose, keep your own configuration archive. A managed interface reduces typing, but it does not remove the need to understand which file or world state is being changed.
Why are my Atlas settings not taking effect?
Check the failure in this order so you do not erase a working world while diagnosing a simple configuration mistake.
The server still uses the old multiplier
- Confirm the server was stopped before the edit and fully restarted afterward.
- Verify the keys are in
[ServerSettings]and spelled exactly as documented. - Check that you edited the active server’s file, not a local copy or an unused cell configuration.
- Remove duplicate entries and leave one intended value for each multiplier.
- Make a small in-game test before changing another setting.
Players cannot join after a map change
- Confirm the server points to the intended
ServerGrid.json. - Check that at least one home grid is assigned.
- Make sure the selected map was installed before the server was started.
- If this was a migration, verify that the documented Redis and Savegame reset was completed in the correct order.
The new map removed the old world
This is expected when switching to a different map: the old world can be deleted. Stop further changes, restore the backed-up JSON and saved data if recovery is required, and only then retry the migration with a separate backup.
Progression feels unbalanced
Identify the activity that feels wrong instead of lowering every multiplier. Lower XP if levels arrive too quickly, lower harvest if materials are effectively unlimited, or lower taming if creatures are acquired without meaningful preparation. Change one group of values, restart, and test again.
What is the safest launch checklist?
- Decide whether the server is PvE or PvP and tell every invited player.
- Choose a single grid or custom layout and confirm the intended home grid.
- Back up
ServerGrid.json, INI files, Redis and Savegame data. - Set the initial values in
GameUserSettings.iniunder[ServerSettings]. - Stop and restart the server after saving configuration changes.
- Join with one test account and verify the world, home-grid access and a small XP, harvest or taming result.
- Invite the rest of the group only after the test succeeds.
- Keep a change log with the date, setting changed and observed result.
This process separates gameplay tuning from map migration. You can safely adjust a multiplier later without touching the grid or wiping the world.
Frequently Asked Questions
Can I change Atlas multipliers while players are online?
Stop the server before editing and restart it after saving. A running process normally continues with the values loaded at startup, and editing a live file also risks having the server overwrite your change during a save.
Do I need to edit both JSON and INI files for a normal XP boost?
No. A routine XP, harvest or taming adjustment belongs in GameUserSettings.ini under [ServerSettings]. Edit ServerGrid.json only when you are changing the world layout or map definition.
What happens if I switch back to my old Atlas map?
Switching maps can delete the current world state. Restore the backed-up JSON and saved data deliberately, and verify the server’s grid and home-grid assignment before allowing players to connect.
How can I let new players join without opening PvP combat?
Use a PvE rule set and designate at least one home grid. Joining access and player-combat rules are separate decisions, so confirm both before launch.