Palworld 1.0 Old Save Checklist

Make the recovery copy before opening the updated world, then record the settings that change loss and travel risk. This gives the rest of the audit a stable starting point and prevents a one-time load or an automatic migration from becoming the only state you can inspect.

On the first load, check the mission log and map before changing the party or base. Mission progress and older random-spawn assumptions can move at the same time, so following a remembered route may send you toward a marker or habitat that no longer represents the current world.

Next, audit one party job and one base cycle. Re-read Partner Skills slot by slot, then watch one input-to-output handoff at the base. A changed skill or work balance may be local; replacing the whole team and layout together removes the clue that would have told you what actually changed.

Only after those checks pass should the save enter the new 1.0 content loop. Keep the old systems that still complete their job, retest the changed dependency, and rebuild one connected lane when the old assumption is genuinely invalid.

• CopyPreserve a separate recovery world before the first load.
• OrientRead missions, settings, and map before rebuilding systems.
• IsolateChange one party or base dependency at a time.

For missions, the pass condition is a current marker and a readable next objective. For the map, it is a route you can reach with the current travel network. For Partner Skills, it is a party slot whose job still works without relying on an old stacking interaction.

For the base, follow one item from input to production, output, hauling, food, rest, and storage. If the first broken handoff is a full output point, adding another producer is the wrong fix even when the worker’s suitability looks strong. The observed cycle is more useful than an old value taken from a spreadsheet.

For combat, pick a familiar encounter and compare movement, commands, damage uptime, and recovery. Do not use new endgame content to diagnose an old assumption; a known fight gives you a controlled benchmark before the level cap and new systems add more variables.

Write the pass condition next to every check. A saved note that says “map okay” is hard to revisit; “activated the nearest watchtower and returned to the base Palbox with the same supplies” can be tested again after a hotfix.

• MissionConfirm the current marker and next objective.
• BaseTrace one complete input-to-output cycle.
• CombatBenchmark one familiar fight before new content.

A ready save has a recoverable copy, current mission and map answers, a party with distinct jobs, a base that can complete a visible cycle, and settings whose death and travel behavior you understand. If one lane is still unclear, keep it in the audit rather than spending rare resources around a guess.

Choose one new goal after the baseline holds: the level 80 climb, a five-capture bonus, the 48-Pal condensation requirement, Awakening, Mutation, a new weapon lane, or the World Tree route. The goal should be specific enough that you can tell whether the new system changed the route.

When an old dependency fails, rebuild only that connected section and save a new baseline. This preserves working production, a proven party, and the comparison needed for the next update. A complete teardown is a last resort, not the default response to a large patch.

The result is a return path that remains useful as the live world changes. The checklist tells the player what to verify; the database and tools can then expose stable Pal, work, and progression relationships without pretending every old value survived unchanged.

• ReadyConfirm mission, map, party, base, and settings together.
• ChooseEnter one new progression lane at a time.
• BaselineSave again after the verified systems work together.