A custom world backup script for FCE (or any game)

Overview

FortressCraft Evolved is a great game, but the technical implementation makes your savegames vulnerable to corruption should you experience a crash or BSOD. In this guide I share my method for scripting self-managed world backups.FCE is certainly not unique in this regard. I’m posting this for FCE because it’s what I’m playing right now, but this process is also relevant (and I’ve used it successfully) for many other games that use fully local save content (e.g. Minecraft, Rimworld, Colony Survival, Don’t Starve, Empyrion, Oxygen Not Included, Skyrim, Starbound, Terraria, etc). The guide is focused on Windows and PowerShell, but can easily be applied to other OSes/languages.

Intro

Recently I lost a singleplayer FCE world save I had invested about 70 hours into, due to corruption caused by a BSOD while I was playing. This is not the game’s fault, I just have unresolved hardware issues right now. It may happen again, so now that I’ve gotten over my loss, I plan to go forward with a new world, performing my own full backups, as I’ve done with other similar games in the past, because I do not want to have this happen again. I thought I’d share my process in case it’s useful for others.

If you don’t care about my nerdy, uninformed musings on the mechanics of FCE save files, just skip down to the “File locations” section. Or for the technically-inclined, see the next “TL;DR” section.

TL;DR

I have a tendency to be overly verbose. If you’re tech saavy or just want the deets without reading a wall of text, here’s a summary of my backup strategy, which is really very simplistic, but just makes it very easy to backup an entire directory to a compressed archive:

1. Create a script that uses 7-zip commandline executable to compress your chosen (savegame) directory to an archive in the backup location.
   • Below I provide a well-commented PowerShell script. Obviously, this could be re-written for any OS and scripting language combination.
     • Customize the $world and $worldsDir variables to match your savegame location.
   • Below I provide instructions on how to get the standalone 7-zip executable I use in the script.
     • 7-zip only exists for Windows, with a Linux port, but you could slot in other archiving tools.
2. If you’re using Windows/PowerShell and use an admin account, below I provide a handy batch script that runs the PowerShell script, bypassing your system’s PowerShell execution security policy. This makes running the script a simple doubleclick operation.
3. Choose a backup location, preferably on a different drive than your OS/game, and put those scripts in that directory.
4. Whenever you want to backup your world, simply run the batch script (or make a handy shortcut to it and run that). Run it liberally.

FCE segment files: the important bits

FCE saves data about the blocks in your world as “segment files”. Each segment file contains data about little chunks in your world (sort of like “chunks” in Minecraft). Like Minecraft, the segments are 16×16, however as far as I can tell, unlike Minecraft, FCE also splits these chunks up vertically into little cubes, making them 16x16x16. This is probably because the world is so friggin deep.

If your game or machine crashes, it’s likely that some of the loaded segments files will become corrupted. This will likely result in the corrupted segments being re-generated from the world seed when the game loads, wiping anything you had ever done to that area in game. This is not an uncommon issue with voxel-based games and will likely never change.

FCE does make some backups behind the scenes. However the main backups do not contain any segment data, only data about your player, inventory, research progress, etc. Supposedly the game is supposed to make backups of certain segment data in some circumstances, but I have not found this to be the case in my experience. Or at least whatever the game did do, wasn’t useful for me to restore the corrupted files.

Why are segment files a challenge to back up?

Because segments are so numerous, the number of files required to save an entire world is staggering. In a brand new world, there were nearly 100,000 files in my world folder. See the image to the right for a visual representation of this.

Technically, this is probably done to limit the amount of file data being accessed at any given time when playing in a world. For example, if you are at your base, the game probably doesn’t need to load segment data from land you explored way out behind the Overminds at the corners of the map.

Additionally, this segmented mechanism can actually work to protect your world in case of corruption. Because the game only needs to write to certain segments, it’s likely that only a small number of segments (i.e. only certain areas of your world) would be corrupted during a crash. Meaning that, perhaps, MOST of your world would still be intact. Compare this to a game like Minecraft that has a single large world file. Minecraft can still experience localized chunk corruption, but if something in that one file is corrupted, it’s possible the whole world is hosed.

From a multiplayer perspective, the segmented method could be much better, as corruption damage could be significantly limited. However in my single player experience, I just lost basically all of my good stuff, so it may as well have just deleted my world entirely IMO.

Anyway… I might just be pulling all of that speculation out of my rear, but suffice it to say that the way segments are saved is probably integral to the game/engine, and the number of files probably can’t really by helped, and will likely only grow as your world ages.

All that to say, if you’re not familiar with how files work, copying and manipulating lots of tiny files like this means there’s a lot of processing/caching overhead. When copying one large file, your computer can kind of set it and forget it, going full speed for the entire data transfer. But with lots of tiny files, it has to constantly slow down and read/manipulate the header information for each file. The difference between copying one 1 GB file and one million 1 KB files is astronomical. You be looking at something like 15 minutes versus several days, respectively.

So let’s do something different

My usual method of backing worlds up is simply to script a copy operation of the whole relevant world folder, placing the copy in a datestamped folder on a separate drive. This works great for games that keep their world data in single large files, like Minecraft. For FCE however, this is time-prohibitive, due to the segment files.

The built-in Windows 10 copy function, RoboCopy, and UltraCopier all see a massive performance slog when copying these files, making backing up even a brand new world take half a day or more. At least, that was my experience testing copying a new (~300MB) world from an SSD to a USB 3.0 external (though that could be limited by the speed of the drives inside the external enclosure).

So I tried simply archiving the (same ~300MB) world folder using 7-zip. This was lightning fast, taking about a minute. Extracting the archive took longer than compressing it, but it still fully and successfully extracted in less than 4 minutes. This is also preferable as the backups will be a fraction of the size (~300MB down to 19MB in my test).

TBH, my smart-assiness ends here. I have no idea why this would be faster than a copy operation. Perhaps it’s because the archiving tool doesn’t need to interact with the disk’s filesystem for every file it touches. Though that wouldn’t explain why it extracts so quickly. Either way, we have a winner. Now to script it.

File locations

Before we can script it, we need to know where everything is. For my example I’ll be copying (or rather archiving) the whole world folder for a particular world directly from the live location to an external drive. The script will be kept on the external drive within the folder where I want the backups to go. As a result, the script will only have one hard coded path (the live location). Everything else will reference paths relative to the script.

Here’s what the backup folder/file structure will look like.

Backup folder and files:
<wherever>backups
<wherever>backupsbackup.ps1
<wherever>backupsbackup.bat
<wherever>backups7za.exe

Live world location:
C:UsersRoachyAppDataLocalLowProjectorGamesFortressCraftWorldsRoachWorld

Go ahead and create this folder structure and the two backups script files as new, blank files. Remember to actually change their extensions, so you don’t end up with backup.ps1.txt, etc.

I’d recommend that <wherever> be somewhere on a different hard drive than your main OS drive, in case the corruption you experience is due to hard drive failure. So something like “d:fcebackups”.

I’ll explain 7za.exe later and give you download instructions.

The script

Historically I’ve used a batch script for this. But recently I’ve become a fan of PowerShell, so I rewrote everything in that. This could pretty trivially be translated to bash/python/etc.

Copy the below into your backup.ps1 file. It looks like a lot, but most of it is just comments. I recommend editing with Notepad++[notepad-plus-plus.org] for the syntax highlighting.

Make sure to edit WORLDNAME (in $world) and USERNAME (in $worldsDir) to reflect your actual world name and path.

A second script to more easily run the script

PowerShell has some annoying security features that prevent you from running things by default. If you want, you can change your system’s PowerShell ExecutionPolicy, but you would want to remember to change it back afterward for security reasons.

it’s just easier to script bypassing the security as a one-time thing, each time you run the script. To that end, here is a one line batch script which will call the PowerShell script, bypassing the security.

Copy this into your backup.bat file.

For this to work, your user account must have admin permissions. We’d all be in a lot of trouble if non-admins could bypass PowerShell restrictions.

Grab 7za.exe

The script uses 7za.exe to archive the world folder. 7za.exe is an officially supported, standalone executable commandline version of the popular open source 7-Zip archive/file manager tool. It doesn’t come with 7-Zip by default, so you have to grab the extra package containing 7za.exe from their file repository.

The extra package comes in compressed 7z format, so you’ll need to install the regular 7-zip first to open it. Here’s a link to the latest 7-zip installer[sourceforge.net]. Go ahead and download and install it if you don’t already have it installed.

I don’t think I can link directly to the extra package of the latest version. So here’s how you find it:

1. Go to the Files list of 7-Zip Sourceforge project page[sourceforge.net]
2. Click on the latest version (currently that’s 18.05)
3. Click to download the “7z<version>-extra.7z” package, e.g. 7z1805-extra.7z

Open the extra package. It should open in 7-zip. Then simply copy/drag 7za.exe out of the archive into your backup folder. I used the x64 version from the package’s x64 folder, but it shouldn’t matter.

Now run it!

You should now have everything you need in your backup folder. See the file list above to confirm.

If you edited your script correctly, you should just be able to double click the backup.bat file and see the progress in action:

Note that during operation, the archive file will be appended with “_backing-up”. At the end of the script the archive is renamed. So if the script finished and you see an archive with “_backing-up” still appended, then you know something went wrong.

Now remember to run it!

Admittedly, this will not solve all your problems. If your game/machine crashes and corrupts your save, you’re still going to lose some progress.

Just remember to always run this script after your play sessions. If you’re like me and play for hours and hours on end, it will be good practice to quit to desktop every now and then and run the script. You could probably get creative and find a way to automate it after the game is closed. But that sounds like a challenge for someone else. Plus it could cause issues if the game is restarted before the script finishes.

Running the script while the game is running shouldn’t cause a problem, but the resulting archive will probably be of no use, since some of the files may have been in use and not fully saved when they were archived. It might possibly be useful for a very complicated restoration, but either way I wouldn’t recommend it. Just get out of your dang chair every once in a while. Go stretch and call your mom.

That said, this solution creates holistic backups, meaning if something does go wrong and you want to restore a backup, it’s a simple as extracting the latest archive to the live savegame location and launching the game. You can’t buy that kind of peace of mind.

Fine print

This script and methodology is provided as-is, as a resource to my fellow gamers. I won’t be held responsible if you somehow damage files or blow up your computer. I won’t provide any support for using this script/methodology, unless I feel like it.

7-zip and associated files are free and open source software, with which I am not affiliated. For licensing information and support see [link].

Keep calm and backup your sh–,
== Roachy