Plan the task
Start with the problem the group wants to change: levels outrunning equipment, too much gathering, short fights or an overloaded base. Change the relevant cluster and keep the others stable for one representative session. The three editable presets are source-informed editorial starting points; they are not official difficulty modes or a configuration already applied to the game.
Parameter meanings were checked against Pocketpair’s documentation marked version 1.0.4. Preset values come from a guide titled for 1.0 with an unverified exact revision. Official game news is at v1.0.5. Record all three contexts instead of treating an old recommendation as a verified current-game default.
Choose a pace, then tune it after a full session
The editor contains all twelve source preset fields, including building deterioration. A 0.75 EXP starting point is an editorial pacing experiment for a group that explores and completes capture bonuses together. It is not evidence of a hidden co-op bonus. Raise it toward 1.0 if the group skips optional activity or stalls below useful technology; lower it only after confirming equipment and materials are keeping up.
Keep resource quantities separate from level pacing. If the complaint is reaching a new technology tier too soon, reducing drops adds hauling without directly answering that problem. If the complaint is waiting for a specific breed, changing incubation addresses waiting rather than combat. Verify the in-game egg timer after applying the setting.
| Preset in the editor | Purpose | Values that define its tradeoff |
|---|---|---|
| Steady co-op | Give a group room to use each equipment tier | EXP 0.75; capture / gathering / enemy drops 1.0; Huge Egg baseline 1 hour; item-only death drops |
| Building focus | Shorten collection and waiting while retaining fights | EXP 1.0; capture 1.25; gathering 2.0; enemy drops 1.5; incubation 0; no death drops |
| Longer fights | Ask for coordination with slower progression | EXP 0.5; player output 0.8; player damage taken 1.2; Pal output / taken 1.1; spawn 1.25; items and equipment drop |
Read the inverse settings before changing them
For example, PlayerDamageRateDefense 0.8 requests less damage taken, while PlayerDamageRateAttack 0.8 requests less player damage dealt. Swapping their meanings changes the whole fight. Preserve the parameter spelling, including Decreace in the official stamina keys.
| Setting family | Lower multiplier or interval | Higher multiplier or interval |
|---|---|---|
| PlayerDamageRateDefense / PalDamageRateDefense | Less incoming damage | More incoming damage |
| PlayerStaminaDecreaceRate and hunger-depletion rates | Slower depletion | Faster depletion |
| BuildObjectDeteriorationDamageRate | Less decay; the source preset uses 0 to request no decay | More decay |
| CollectionObjectRespawnSpeedRate | Shorter resource-respawn interval | Longer interval |
| DayTimeSpeedRate / NightTimeSpeedRate | Longer day / night phase | Shorter phase |
Choose random placement and random levels separately
For a first story run, None avoids turning an acquisition guide into a search for a relocated target. For a replay, Region with level randomization false is a conservative editorial starting point. Seed alone is insufficient documentation when a patch changes the spawn system.
| Option | Discovery change | Planning consequence |
|---|---|---|
| RandomizerType=None | No placement randomization | Use the ordinary region routes. |
| RandomizerType=Region | Shuffle placement within regions | Retain a regional framework while changing discoveries. |
| RandomizerType=All | Shuffle placement across the world | Treat ordinary species locations as a reference rather than a route guarantee. |
| bIsRandomizerPalLevelRandom=False | Use each area’s intended level range | A more predictable starting experiment for a mixed-skill party. |
| bIsRandomizerPalLevelRandom=True | Fully random wild levels | Prepare for large early mismatches; this is an intentional chaos choice. |
| RandomizerSeed | Seed input for randomized placement | Record the seed with build and settings; do not promise identical cross-version spawns. |
Treat old randomizer worlds as a migration
The official 1.0 release says random-spawn placement from v0.7.3 and earlier is not retained through the habitat rebalance. It also limits the start-with-all-saddles-unlocked behavior to newly created randomizer worlds and excludes older carried-forward saves.
Before updating an established randomized world, stop it and preserve a full recoverable copy. Record important worker and travel locations. After migration, inspect the starting area and a known route before assuming the old placement remains. The saddle announcement concerns unlocks; it is not a promise that gear is already crafted or equipped.
Apply and record one recoverable change
- Name the problem in one sentence and record the installed host/client builds, platform, old values and intended new values.
- Stop the dedicated server and copy its save and configuration tree. For a local world, retain a recoverable save before a large change. A settings export from this website is not a world backup.
- Edit the active PalWorldSettings.ini under Pal/Saved/Config/WindowsServer or LinuxServer. Pocketpair says editing DefaultPalWorldSettings.ini itself does not apply a change.
- Merge the editor’s assignments into the existing OptionSettings tuple, preserving unrelated settings. The twelve assignments are not a complete replacement file.
- Restart, confirm that the intended behavior changed, then play a session containing travel, production, a representative fight and recovery. Note failures as well as the best moment.
- Record the outcome, date and values. Revert a harmful change from the known baseline rather than applying another unrelated preset on top. Keep secrets out of publicly shared configuration notes.
Keep co-op challenge recoverable
The Longer fights preset changes several values for comparison, but tune them one family at a time in an established world. Begin by testing player output 0.8; the intended tradeoff is a longer encounter. If that already creates a satisfying fight, leave incoming damage alone. If mistakes still have too little consequence, try a modest damage-taken increase and assess every player’s recovery, not only the strongest player’s clear.
Do not multiply wild spawns as the first difficulty adjustment. It combines combat density with server cost. Keep capture changes separate too: failed throws can consume more materials without making attacks more interesting. None, Item, ItemAndEquipment and All have different recovery burdens; the official death-drop description includes party Pals for All. Agree on that consequence before selecting it.
If a player repeatedly dies before an action can register, check latency, equipment and the encounter before adding incoming damage. Choose a nearby recovery test and verify the actual drops once; a readable rescue run is more useful than discovering the penalty during a remote raid.
Budget load with the group online
Record connected players, active bases, process memory, save pauses and visible lag during the same route before and after the change. If available, compare host CPU and storage activity too. A smooth solo visit does not establish capacity for the full group, and a stutter is not automatically a network fault.
Pocketpair’s launch-argument page warns that the older multithreading flags may perform better when left unset from v1.0 onward. It is a reason to compare the current documented startup configuration, not to append every historical optimization flag. No universal worker, building or player count is established by this guide.
| Setting | Why to watch it | Controlled test |
|---|---|---|
| PalSpawnNumRate | More wild entities can increase simulation cost | Keep 1.0 as the comparison; test 1.25 during representative travel/combat. |
| BaseCampWorkerMaxNum | More workers add work and pathing | Raise one busy base’s demand at a time; inspect blocked routes and memory. |
| BaseCampMaxNumInGuild | More bases add persistent activity | Test the actual active-base pattern rather than only an empty new world. |
| MaxBuildingLimitNum | More structures increase the world’s workload | Use a deliberate public-server cap; 0 is documented as unlimited. |
| bIsUseBackupSaveData | Backups add disk work | Keep recoverability and measure save-related stalls; do not remove the only backup to win a short benchmark. |
Run the world with a visible baseline
Keep the original backup, current applied file and a short change log. Share the gameplay values with the group and verify them after moving hosts or restoring a save. A copied website plan remains a plan until the running world shows the expected result.
For an unexplained result, first confirm that the correct file was edited, the process restarted and the current game accepts the key. Then isolate one setting. Native accepted ranges, interactions with mods and actual host performance need a build-specific check; the source preset does not validate them.
Choose the task and finish the next step
Choose world settings for the intended pace and difficulty, then document the values so a group can reproduce them. Explain tradeoffs and distinguish configuration parameters from an official recommended preset.
Work from a reproducible starting point
- Check the prerequisite, selected game revision and the current state of the save.
- Use the actual linked Pals, item recipes and map/tool entries for the next step.
- Verify the intended outcome, then record the inputs so another player can repeat the task.
Evidence boundary
The factual tables preserve the stated source snapshot. Source-specific recommendations and mechanics have not been independently reproduced in the current game. Exact gameplay rule gaps remain in the coverage notes rather than being filled with invented quantities.