If Enshrouded can't edit world settings after the 1.0 launch, install the available game update first. Hotfix 1.0.0.2, released October 16, 2026 as build 1269579, fixed a world-settings configuration failure introduced by the preceding hotfix. Reopen the intended world and check the Edit action after updating; deleting the world is not part of this repair.
If the settings open but changes do not apply, check the Custom preset and the active server configuration. If you can join a server but cannot dig, change blocks or extend a base, check the permissions assigned to the password you used. Those are different failure paths, and the server permission named canEditWorld does not mean permission to edit the difficulty menu.
Identify the exact action that fails
Start with what happens on screen. A missing or unusable world-selection action needs a different investigation from an ignored gameplay value or a restricted building action. Record the action before changing a configuration file so you can repeat the same check afterward.
| Symptom | First check | What would verify progress |
|---|---|---|
| World settings do not open from world selection | Game update and the launch hotfix | Edit opens the intended world's settings |
| Individual gameplay values seem ignored | Custom preset and active configuration | The saved value and corresponding behavior agree |
| You cannot dig or change the world outside a base | The joining group's canEditWorld value | The intended action works with the correct group |
| You cannot change blocks or props inside a base | The joining group's canEditBase value | An authorized base edit succeeds |
| You can build but cannot add or change Flame Altars | The joining group's canExtendBase value | The intended altar action is permitted |
Check whether the failure affects only one player. If the host can make the same change but a visitor cannot, investigate the visitor's role before treating the entire world's configuration as broken. If nobody can open the world-settings menu, begin with the menu and version path.
Update before repeating the launch-period menu workaround
The 1.0.0.2 fix addresses an issue that prevented configuring world settings. It followed a hotfix that had changed the multiplayer session lists, so the timing of the failure is useful information when it began immediately after updating during launch.
Close the game and let the available update finish. Start it again, select the correct world and attempt the same Edit action. Check the installed version when reporting the result; a queued download does not establish that the game you launched contains the fix.
Treat this as a targeted check rather than a promise that every disabled button has the same cause. If the settings still fail to open after the update, retain the exact symptom and version. Do not escalate directly to replacing save files because the first check did not solve your particular case.
World-selection menus can also contain a Delete action. That action is separate from changing settings and is irreversible. Keep a recoverable copy of important progress before further troubleshooting, and avoid selecting deletion as an experiment to make the editor appear.
Use the local world's Edit action for difficulty changes
For a locally selected world, difficulty changes are accessed from the world selection screen through Edit. Select the world you intend to change before opening the settings. A character can be used in different worlds, so checking the wrong world's screen can produce a misleading comparison.
Open the settings, select the intended preset or supported change, save it and return to that world's settings to confirm the result. If the menu opens but a value does not persist, describe that as a save or application problem rather than continuing to report that the menu cannot be opened.
Keep the attempted change narrow while troubleshooting. Change one relevant value, note its previous state, and check it again. Replacing several unrelated settings at once makes it harder to identify whether the action saved correctly or whether another preset is determining the result.
This step concerns gameplay configuration. It does not determine whether a joining player can remove base blocks, access a chest or place another altar. If those are the failing actions, move to the role checks instead of cycling difficulty presets.
Select Custom when individual server settings are ignored
A dedicated server uses enshrouded_server.json for its configuration. Its gameSettingsPreset selects the preset, while the individual gameplay values sit under gameSettings. Individual settings are editable through this configuration only when the preset is Custom.
Check these two fields together. Editing a value inside gameSettings while leaving a named preset selected can explain why the intended custom behavior is absent. Do not treat the appearance of your edited text in a file as proof that the server is using the individual value.
For a hosted instance, use the configuration belonging to the active server. Stop the service before making an offline configuration change, preserve the existing file, edit the relevant fields, save valid JSON and start the service again. Then inspect the saved configuration and test the one behavior you intended to change.
Use the file generated by the installed server as the starting point. An older full-file example may omit newer keys or contain defaults that differ from your running version. A small edit to the appropriate field avoids replacing unrelated passwords, groups, save locations or gameplay settings.
Do not confuse the server configuration with the world save. Changing a preset does not require deleting the saved world. Preserve the save location and unrelated settings while testing the specific configuration issue.
Check invalid values when the server will not start
A server that fails to start after a file edit presents another symptom. Check the edited JSON structure and the server's error output before investigating a greyed-out in-game menu. A missing comma, incorrect value type or invalid text should not be addressed by changing a world-save file.
The configuration rules distinguish invalid text from an out-of-range numeric value. Invalid text can prevent startup and identify the entered value in the command output. A numerical value outside an allowed range can be limited to the minimum or maximum instead. That can make a value appear to be ignored when it was actually constrained.
Use the permitted value for the exact setting and installed version. Do not infer a valid spelling from a menu label or paste a large old configuration over the active one. Restore the last known working configuration if necessary, then repeat the smallest relevant change.
Once the service starts, verify the intended behavior separately. Successful startup establishes that the server accepted enough configuration to run; it does not prove that the correct preset, world or player permissions were selected.
Match the permission to the failed building action
Dedicated-server player permissions are assigned through userGroups. Each group has its own configuration and password. Inspect the actual group's values rather than assuming its displayed name always carries the same permissions as another server's Friend, Guest or Visitor group.
| Permission | Action to investigate |
|---|---|
| canEditWorld | Changes to the game world outside player bases, including the relevant digging or terrain-editing activity |
| canEditBase | Adding or removing blocks and props and terraforming within player bases |
| canExtendBase | Adding, upgrading or removing Flame Altars |
| canAccessInventories | Accessing chests and other containers |
These are separate capabilities. Being able to dig outside the base does not demonstrate permission to remodel it. Being allowed to change blocks does not establish permission to add an altar. Access to a chest is another independent question.
Ask the host to check the field that matches the blocked action. For example, a player who can build but cannot extend the settlement needs the altar-related permission inspected. Granting every administrative ability is unnecessary for diagnosing that one restriction.
A mining-effectiveness setting changes how mining performs; it is not the same control as permission to edit terrain. Likewise, changing enemy difficulty does not change whether the joining group can modify a base. Keep these settings out of the repair unless they explain the observed symptom.
Check the password and hosting mode used for the connection
The password used when joining selects the permission level. If the host has supplied different passwords for visitors and builders, reconnect using the intended group credential after the host confirms it. Do not assume that joining successfully means you entered the group with building access.
The host should compare the relevant group's actual permissions with the action you are trying to perform. Custom group names are possible, and groups can intentionally separate inventory access from building access. A permission difference can therefore be deliberate rather than a failed update.
For a peer-to-peer session hosted from the game, the host manages these options through Host Settings. Those host role settings are stored in enshrouded_user.json alongside the save data. Dedicated-server groups belong to enshrouded_server.json instead. Identify the hosting mode before editing a file with a similar name.
If a hosting panel offers its own password or role editor, confirm that it reflects the current user-group structure. An older panel field for one server password may not represent the role used for a connection. Check the actual active group rather than repeatedly entering a password in an unrelated field.
Verify the repair and report only the remaining failure
Repeat the action that originally failed. For the menu path, confirm that Edit opens the correct world's settings and that the intended change saves. For the Custom path, confirm the active preset and the relevant value after the server restart. For the permission path, reconnect with the intended group and test an authorized action in the appropriate area.
Keep the test small and agreed with the host. A permission check does not require demolishing a structure or removing an altar just to demonstrate that an action is possible. Use a permitted, reversible change suited to the capability being checked.
If the problem remains, record the game and server versions, hosting mode, world name, exact failed action, active preset and relevant permission values. Describe whether the host or another group can perform the same action. Omit passwords from screenshots or reports; the group name and permission values are enough to explain the configuration.
That evidence distinguishes an unresolved menu problem from a configuration that did not apply or a role that remains restricted. Preserve the working configuration and saved world while investigating the remaining failure. An update finishing, a server starting or a player joining is a useful intermediate result; the repair is confirmed when the intended edit itself works.