Skip to main content

Plan Palworld base and worker limits before expanding a guild

Increasing a Palworld guild's bases or active workers changes the workload players can create. Plan the expansion around a representative base rather than treating a larger limit as a performance fix. You need a recoverable save, a known busy period and a volunteer who understands which base will act as the test case.

Record separate capacity controls

The current Pocketpair reference distinguishes total server bases, bases per guild and workers per base through BaseCampMaxNum, BaseCampMaxNumInGuild and BaseCampWorkerMaxNum. Its current guidance warns that larger guild-base and worker limits increase processing load. Check the reference for your installed build instead of copying maximum values from another server.

Count the group's existing bases and workers before editing. Record concurrent players and representative resource use from the panel, including whether the server has recently restarted. A quiet, empty server provides little evidence about a busy production base. Save the current configuration and note any template fields that could overwrite it.

Run a bounded expansion trial

  1. Choose one bottleneck: an additional guild base or additional workers. Agree a small increment with players and write the original limit beside the proposed limit.
  2. Schedule the change and take a complete save checkpoint. Stop the process and edit the single supported limit in the existing options record.
  3. Restart and confirm that the panel preserved the value. Have the volunteer exercise the intended capacity without building several additional bases at once.
  4. Observe the server during comparable play. Record active players, the test base, resource readings, noticeable delays and log errors over the same observation window.
  5. Ask players at another base whether they notice new delays. Compare with your baseline before authorising another increment or changing a second limit.

Interpret the result carefully

A rise in memory use after players join does not prove a leak, and a short quiet test cannot guarantee smooth peak-hour play. Investigate repeated errors and sustained resource pressure before making a capacity decision. Keep a dated record of approved limits so future staff can distinguish the purchased resources from the game's gameplay caps.

If the expansion works for your group, tell guild owners what you changed and discourage everyone from testing the new maximum at once. Arrange another review after a representative busy session. Do not combine a limit increase with new mods, randomizer settings or a major game update when you want evidence about that limit.

Plan reductions before touching live settings

Lowering a cap after players use it may affect gameplay in ways a configuration-only rollback cannot reverse. First ask owners to reduce the relevant live usage through supported game actions, or test the reduction on a separate copy. Keep the complete pre-change checkpoint and present save. If the server becomes unstable, preserve evidence and ask support for a recovery plan rather than repeatedly cutting caps or deleting base data.

Pocketpair base capacity and performance settings.

No comments to display