Setting up Pod Restore

Required mods

Workshop ID: 2784972075

Mod ID: BTSE_Base

Mod ID: BTSE_RestorePods

If you have loaded the above correctly, you should have these showing in your Sandbox Options:

Sandbox Options

BTSE | Restore (common settings)

Default values

Value definitions

Only keep the following amount of restore points per user (0 = infinite)

This value determines how many restore points are retained for each user. A restore point is the same as a personnel file in game. Think of them as "past lives" or "deaths". Setting this to zero will keep every restore point on permanent record, however only a maximum of fifty will ever be shown to players and admins to restore from.

Seconds between restore queue steps

How long the system will wait between processing the chunks of restore XP. You can extend this if you want a slow restore for RP reasons, or if your players are experiencing issues with anti-cheat being triggered. The default values should not trigger any PZ anti-cheat.

Seconds until a restore queue step is retried

Minimum of zero, maximum of three hundred (0-300). Determines how long the process waits before attempting a missed restore step. Only change this if you are experiencing issues with the restore process.

Call vanilla STR/FIT refresh function after trait restoration

If this box is checked, the restore process will force a strength and fitness refresh from the game. This makes the game check the player's STR/FIT values and determine if any traits need to be added or removed. The game automatically does these checks periodically regardless of this box's value.

Clear user restore queue before restore processes

In very rare cases the restore queue can get stuck in the verification process. Enable this option and then attempt to restore again. Consider this as a troubleshooting option and not standard play.

Ingame hours between automatic snapshots (0 = off)

The amount of time before a player's current stats are saved to their "live" file. When a player dies, the pod restore mod will attempt to record that player's stats to their "live" file so it reflects their at-death condition. Sometimes this process can be missed due to lag or performance issues, particularly during heavy events and zombie spawning. As a fallback, these automatic snapshots provide a periodic update to that "live" file to reduce the amount of potential skill data lost on death.

Configure this value to your preference. Setting this to zero will turn off the function and rely purely on the at-death process to catch the user's data. Setting the value lower will prompt more regular data collections and may have performance impacts. Adjust as necessary if the players are noticing data loss.

Preserve initial spawn XP during the restore

"Initial spawn XP" refers to the default skill levels a certain build provides. For example, if your character's build normally spawns in with 5 Fitness, 5 Strength, and 2 Carpentry, that is considered the "Initial spawn XP".

If this box is checked, during a restore the player will always at minimum receive the same levels as their initial build would have given them. If Fitness and Strength are configured to restore zero percent but the initial spawn XP in our example provided five of each, the player will always at minimum receive five of each.

If this box is not checked, during a restore the player will only receive the restore values compared to their pod data and will not take into account their initial spawn XP. If Fitness and Strength are configured to restore zero percent and the initial spawn XP in our example provided five of each, the player would restore zero points in Fitness and Strength.

Having the box unchecked and not restoring initial spawn XP can lead to diminishing returns and punishes repeated deaths

Maximum survived hours for people to transfer spawn xp

This option is specifically for servers that have added the pod restore option mid-season or mid-wipe. This is an integration option to smooth over the transfer to the pod restore method. To explain this option, we first must understand a little more about how the restore system works.

In a server that runs the pod restore system from the start of the wipe, players create their builds on first login and that build is recorded into their "live" file on character creation. That build data is important for the "initial spawn XP" option mentioned above.

When those players die, the "live" file already contains their initial spawn XP and everything works as normal.

In a server that adopted the pod restore system after the start of the wipe, all pre-existing characters do not have their initial spawn XP recorded in their file as the mod has no way of knowing what they chose on character creation. When a player attempts to recover their "live" file from a pre-existing character, the initial spawn XP option above cannot be applied until the mod is informed what the player's original build contained.

To allow players to update their file, a process was added so players could spawn in with their desired build and use that build to update the file after the death. The player can right-click the file and choose "Store build specific XP". The new build must match the previous build's profession.

This sandbox option sets the amount of ingame hours that the option is available to players. Setting this longer allows more leniency for updating their file which is useful if you have restricted access to pod locations, however this also allows players time to farm XP which will be included in the initial spawn XP values. Adjust as necessary.

Do remember this is a one-time process during integration of the pod restore mod. Once a player's file includes build specific XP, that file cannot be updated again. Any player created after the mod is added will automatically include the build specific XP in the file on character creation.

BTSE | Restore (item specific)

Default values

Information shown in restore item name

This option changes how the Personnel File gets named by the system. This name updates if you change the option.

Option 1: Personnel file
This option shows the number associated with the restore point the file is referencing

Option 2: Date / Time of death
This option shows the in-game date and time in YYYY-MM-DD HH:MM format.

Allow users to rename their restore items

A simple checkbox that enables a "Rename this file" option under the context menu.

If a file name is changed this way, it no longer follows the "Information shown in restore item name" logic and becomes a static name.

Allow users to scrap personnel files (needs client relog)

If enabled, this allows users to delete their personnel file item in their inventory. This does not delete the actual snapshot which can still be recovered via other means.

Perks excluded from restore (separated by ;)

If left blank, this option has no impact on the pod restore system. 

BTSE | Restore (pod specific)

Default values

Automatically create map annotations for discovered pods

With this checkbox enabled, players will hear the scribble noise play when they load a chunk with a pod inside it. Their map will show a brain marker with a down arrow. This marker is centred on the pod tile.

The marker icon is only written once. If players manually erase their marker icon, it will not return without the pod being placed again.

BTSE | Restore (3rd party)

Default values