For a private cooperative ASKA group, start in Normal mode, choose a region close to the host or the majority of players, set a password, keep one stable save ID, and use a 10- or 15-minute autosave interval. Leave Keep Server World Alive off unless you intentionally want the simulation running while everyone is offline. Move to Custom mode only when the group has agreed on deeper world-generation, population, difficulty, or time settings—and make that decision before creating the long-term world.
The settings below explain what each field does, which changes require a new save, how to use presets, and how to change a hosted server without damaging a shared world.
What are the best ASKA server settings for a private group?
The safest baseline is deliberately conservative: Normal mode, a descriptive server name, a password for a closed friend group, a stable save ID, the nearest practical region, autosaves every 10 or 15 minutes, and Keep Server World Alive disabled. This combination protects progress without leaving a world running unattended or forcing the group to commit to custom generation rules before it knows what it wants.
| Setting | Recommended starting value | Why |
|---|---|---|
| Mode | Normal | Exposes the ordinary server fields and avoids committing to custom world generation. |
| Server name | A recognizable group name | Lets players identify the correct listing. |
| Password | Enabled for private groups | Prevents unwanted players from joining. |
| Region | Nearest to the host or most players; use default when the provider documents it as the best-ping choice |
Reduces likely connection distance. |
| Save ID | One recorded, stable ID | Ensures the intended existing world is loaded after restarts. |
| Autosave | Every 10 or 15 minutes | Balances progress protection with save activity; this is practical guidance, not a published benchmark. |
| Keep Server World Alive | Disabled | Allows the world to load when the first player joins and unload when the last player leaves. |
Write these values down before inviting anyone. A small configuration record—server name, region, password-sharing channel, save ID, mode, autosave choice, and any custom values—makes recovery much easier when a host panel is reset or a setting is changed accidentally.
How do Normal and Custom mode differ?
Normal mode is the appropriate starting point for most groups. Custom mode exposes deeper world-generation and gameplay controls, but hosting documentation generally treats it as a world-creation choice rather than a harmless toggle on an established save.
Normal mode
Normal mode presents the ordinary server fields: name, password, region, save selection, autosave behavior, and the world-alive option. It is easier to explain to new players and gives the group a known baseline for troubleshooting.
Custom mode
Custom mode is for groups that want to alter factors such as animal populations, monsters, invasions, weather, terrain, day and year length, or decay. BisectHosting describes custom mode as typically selected when creating a world and notes that it requires a new save or an uploaded save; Game Host Bros likewise separates normal settings from custom world settings. Treat that limitation as important: do not assume every custom property can be changed safely on an active world.
When should a group choose Custom?
Decide before the long-term world is created if the group already knows it wants a nonstandard difficulty or world-generation experience. If you are experimenting, copy or otherwise preserve the current save, change one setting at a time, and test the result on a disposable world before applying it to the shared campaign.
Which region, password, save ID, and server-name settings should I use?
These fields determine who can find the server, who can enter it, and which world the host loads. Set them before the first session and record the values outside the hosting panel.
Region
Pick the location closest to the person hosting most often or to the majority of players. Provider labels differ, so use the exact region names shown in your panel. Some Game Host Bros guidance describes default as the best-ping choice when appropriate; that is a provider-specific label, not a universal ASKA value.
Password
Enable a password for a private friend group and distribute it through a trusted channel rather than a public server listing. If the group later opens the server, change the password deliberately and tell players whether the old password should be considered compromised.
Save ID
The save ID identifies which existing save is loaded. Keep it stable, copy it into your configuration record, and verify it after any migration or panel reset. Starting the server with a different ID can appear to “erase” progress when it has actually loaded another world.
Server name
Use a name that distinguishes the world from test servers and includes a short group identifier. Avoid putting the password or personal contact details in the public name.
How often should an ASKA server autosave?
Choose every 10 or 15 minutes for a typical cooperative group. Hosting panels document options including every morning, disabled, and intervals of 5, 10, 15, and 20 minutes; the 10- or 15-minute recommendation is a practical compromise, not the result of an independent performance study.
| Interval | Best fit | Trade-off |
|---|---|---|
| Disabled | Only controlled testing where players accept manual-save risk | A crash can lose all progress since the last save. |
| Every morning | Groups that intentionally want a daily checkpoint | Usually too infrequent for an active evening session. |
| Every 5 minutes | High-risk building or groups that value a short rollback window | More frequent save activity and potentially more interruptions. |
| Every 10 minutes | Most small groups | More protection than long intervals without saving constantly. |
| Every 15 minutes | Groups wanting a slightly quieter schedule | A failure can remove up to roughly one additional quarter-hour of work. |
| Every 20 minutes | Groups that prioritize fewer save events | Larger potential progress loss between checkpoints. |
Do not describe these intervals as guaranteed recovery points: the actual loss after a failure depends on when the save completed and whether the host experienced a separate storage or process problem. Warn players before planned restarts even when autosave is enabled.
What does Keep Server World Alive do?
With the option disabled, ASKA can unload the world when the last player leaves and load it when the first player joins. With it enabled, the world remains alive between sessions, so simulation continues while nobody is connected.
Leave it disabled for session-based play
Disabling it is the sensible default for a group that plays together at scheduled times. It avoids unattended simulation and means players return to a world that was not advancing while everyone was offline.
Enable it only for intentional offline simulation
Turn it on when the group specifically wants systems such as time, weather, production, decay, or other world activity to continue between visits. Agree on that behavior first: a player who expects the world to pause can return to changed conditions and assume something is wrong.
Which custom settings are worth changing?
Custom controls can alter the character of a world far more than the basic server fields. Citadel’s ASKA settings guidance identifies categories including bears, herbivores, monsters, Wulfar, invasions, weather, terrain, day and year length, and decay.
Populations and enemies
Population controls change how often players encounter wildlife and threats. Adjust one population category at a time and record its previous value so the group can identify which change affected resource availability or difficulty.
Wulfar and invasions
These settings can raise the pressure on a settlement. Use a staged approach: test the new level with one or two players, then let the full group decide whether the added challenge fits the campaign.
Weather and terrain
Weather and terrain changes affect travel, visibility, building sites, and resource routes. They are especially disruptive after a group has memorized a map, so apply them before a permanent campaign or on a copied save.
Day, year, and decay
Changing time scales alters every schedule built around daylight and seasons. Decay settings can change the maintenance burden on a settlement. Record the old values and tell players exactly when the new rules take effect.
How do I create and apply a custom preset?
Create the preset in ASKA’s multiplayer Custom menu, then upload the resulting preset folder to the host. The host configuration must explicitly enable presets and select the uploaded preset before the server is started.
- Open ASKA’s multiplayer menu and choose Custom.
- Set the desired world and gameplay values, changing only one category at a time while testing.
- Give the preset a clear name and save it.
- Locate the saved preset folder and upload it to the host’s
Saves/presetslocation. - In the server configuration panel, enable presets.
- Select the uploaded preset from the provider’s preset field.
- Save the configuration and start the server.
- Join with one player first. Confirm the expected world loads and verify the changed behavior before inviting the entire group.
Keep a local copy of the preset folder and note which save ID it was designed for. A preset is not a substitute for a world backup, and the available controls can vary by host panel.
How do I safely change ASKA server settings on a hosted server?
Use a stop, record, edit, save, restart, and verify workflow. Editing a live process risks disconnecting players or leaving the panel and game process out of sync.
- Warn the group. Tell players when the change will happen and that a restart may disconnect everyone.
- Stop the server. Use the provider’s stop control and wait until the panel reports that the process has stopped.
- Record the current state. Copy the save ID, mode, autosave choice, region, Keep Server World Alive state, and any custom values.
- Change one setting or one related group. Avoid changing mode, time scale, populations, and decay simultaneously; otherwise you will not know which change caused a problem.
- Save the configuration. Confirm that the panel accepted the new values rather than merely displaying unsaved edits.
- Restart the server. Wait for the server to become joinable before asking everyone to connect.
- Verify with one player. Check the server name and password, confirm the intended save loaded, and observe the changed behavior.
- Tell the group what changed. A short change log prevents players from mistaking an intentional rule change for a bug.
This procedure is documented in variations by multiple ASKA hosts. Because custom-mode documentation emphasizes new saves or uploaded saves, preserve the existing world before attempting a mode change.
Which ASKA host has the settings a group needs?
Managed ASKA hosting is the most straightforward route when you want a web panel for stopping, editing, saving, and restarting the server. LogicServers, Game Host Bros, Citadel Servers, and BisectHosting all publish ASKA-specific configuration guidance, but their panel labels, region lists, preset workflows, backup tools, and available controls can differ.
| Provider documentation | Useful focus described in its ASKA guidance | What to confirm before ordering |
|---|---|---|
| LogicServers | World lifecycle behavior, including unloading the world when the last player leaves | Whether Keep Server World Alive is exposed and how world restarts are scheduled. |
| Game Host Bros | Ordinary server fields, region selection, save ID, and separation of normal and custom settings | Exact region names, the meaning of default, and how an existing save is selected. |
| Citadel Servers | Detailed custom categories such as populations, threats, weather, terrain, time, and decay | Which custom controls are available on your plan and whether they can be edited on an existing save. |
| BisectHosting | Custom-mode creation and new-save or uploaded-save requirements | How uploads, backups, and rollback work before you commit a campaign. |
No pricing, uptime ranking, or independent performance benchmark is established here. Compare hosts on the controls your group actually needs: save access, backups, region choice, preset upload, restart scheduling, player permissions, and clear recovery instructions. Ask the host whether a proposed setting is supported on an existing world rather than assuming that a visible text field is safe to change.
What should I check when players cannot join or the wrong world loads?
Most configuration problems can be narrowed down by checking identity, access, process state, and save selection in that order.
- Server is not visible: confirm the process is running, the selected region is one players are searching, and the server name has not changed.
- Password rejected: copy the current password from the panel, check capitalization and spaces, and distribute the new value through the agreed private channel.
- Fresh or empty world appears: stop the server and compare the configured save ID with the recorded ID. Do not continue playing on the unintended world if you intend to return to the original.
- Custom values have no effect: verify that Custom mode or presets are enabled, the preset folder is in
Saves/presets, and the server was restarted after saving the configuration. - Players lose progress after a crash: confirm that autosave is enabled and note the selected interval. The interval limits expected rollback but cannot repair a failed or corrupted save.
- World changes while everyone is offline: inspect Keep Server World Alive. If it is enabled, disable it and restart when the group wants session-based progression.
What configuration record should every group keep?
Store a plain-text or shared-document record outside the host panel. Include the server name, provider and region label, password-sharing method, save ID, mode, autosave interval, Keep Server World Alive state, preset name and folder copy, custom values, last change date, and the person who made the change.
That record is useful during a migration, after an accidental reset, or when a new administrator takes over. Keep historical entries instead of overwriting them so you can identify the last known-good configuration.
Can I switch from Normal to Custom without starting over?
Do not plan on a seamless switch. Hosting guidance says Custom mode is typically selected when creating a world and may require a new save or an uploaded save; the sources do not promise that every custom property can be changed safely on an existing world.
Preserve the current save, test the desired rules on a separate world, and ask the host how an uploaded save is handled before attempting a migration.
Frequently Asked Questions
Does ASKA autosave while the server is empty?
That depends on the Keep Server World Alive setting and the host’s process behavior. If the world unloads after the last player leaves, there is no active simulation to protect until someone joins; keeping the world alive is an intentional choice, not a requirement for ordinary autosaving.
Can I use different settings for different players?
Server settings apply to the shared world, so players do not get individual difficulty, weather, or population rules. Agree on a single configuration and record it before the session starts.
How can I test a custom preset without risking our campaign?
Upload the preset to a separate test save or a temporary server, then join with one player and inspect the relevant behavior. Keep the production save and its original preset untouched until the test is complete.
What information should I give a hosting provider before migrating an ASKA world?
Provide the save ID, current mode, preset folder if used, custom values, region, and whether the world must pause when empty. Ask specifically how the provider backs up and restores uploaded saves before you stop the old server.
Is a dedicated physical server required for ASKA multiplayer?
No physical product is central to the configuration described here. A managed host can provide the server panel and lifecycle controls; the important decision is whether it exposes the save, preset, region, backup, and restart features your group needs.