Quests: design, validation and activation
How to prepare your own or blocked quests, check the resulting files, create a publication, apply it and plan the activation.
On this page
The Quests module is used to prepare your own SCUM quests and to block selected native quests in a controlled manner. The administrator works with a draft in the database, sees the resulting file preview, corrects errors, and only then creates a publication for a specific server.
Saving a quest does not mean that players can already see it. There are deliberately separate steps between the editor and the active game: design, validation, publication, apply and restart.
Where to find it
- Quests - profiles, quests, blocked identities, validation, publication and history.
- Quests → Preview – final preview of prepared JSON files.
What is profile, custom quest and blocked quest
- Profile: working set of quests for one selected server. It can remain as a draft until it is ready.
- Custom quest: a custom definition that Nodera will insert into the upcoming quest file.
- Blocked quest: the identity of the native quest to be blocked in this configuration. Blocking is not deleting the original game content.
- Publication: immutable published version of the verified profile intended for the application.
Recommended procedure
- Select a server and create or open its working profile.
- Add the first custom quest through the editor. Use a stable unique identity and fill in all mandatory fields displayed by the form.
- If you need to disable the native quest, add it to blocked identities. Do not create an empty custom quest with the same name as a substitute for blocking it.
- Start validation. Fix bugs, identity collisions and invalid bindings.
- Open Preview and read the result as a whole. Check that it contains only the intended quests and blocked entries.
- Create a publication. It will keep the exact verified status even if you edit the draft later.
- Send the publication via Apply. NODERAgent will only write allowed quest files; PHP admin does not write directly to the game server.
- Schedule a separate approved restart of the SCUM server. Quests will not become active until a successful Apply.
- After restarting, perform a game test: quest availability, progress, goal, reward and behavior of blocked quests.
How to read statuses
| Status | What can you claim |
|---|---|
| Draft saved | The draft exists in Nodera. Players may not see it yet. |
| Validation successful | Format and supported bindings passed the check. It's not a game test yet. |
| Publication created | There is an immutable version ready for deployment. |
| Apply successful | The files have been safely prepared on the server. SCUM did not restart automatically. |
| Restart and game test | Only after them can the new configuration be marked as active and verified. |
Current example from the Main server
Status of the database as of 1 September 2026.
- There was one working profile named "Default quest draft..." in draft status.
- Profile did not contain any custom quest definition.
- There was no publication ready to apply.
Therefore, at the time of the audit, the main server did not have its own quest published through this module. The configuration examples in this guide are a workflow, not a description of active Main content.
Example of a safe test
Create a simple quest on the Test server with a clear identity, one easily verifiable goal and a small reward. Validate it, check the Preview, create a publication and apply it. After the approved restart, verify acceptance, progress and completion. Only then prepare the same change for Main as a new publication.
Frequent problems
- Publish is not available: profile has validation errors or no meaningful content.
- Apply is not available: the selected agent may not report support for writing quests or another operation is already running.
- Apply succeeded, the quest is not in the game: most often the necessary restart has not yet taken place or another server has been tested.
- After the edit, the old publication changed: it shouldn't. Modifications belong to the draft and the next publication; history must remain unchanged.
- Quest passes validation but does not work: validation does not replace in-game acceptance. Test the entire process on the Test server.