Database files

Galactic Empire keeps its saved game in files beside the module. A sysop should know which files belong together, which clean templates to retain, and which files to restore when starting a new game. For field layouts and Btrieve keys, see Data structures; this page covers the files as an operational set.

Game files

Purpose	Classic GE	Elwynor GE	ge-next (0.3+)
Players, preferences, scores	`MBMGEUSR.DAT`	`ELWGEUSR.DAT`	`MPOGEUSR.DAT`
Persistent player ships	`MBMGESHP.DAT`	`ELWGESHP.DAT`	`MPOGESHP.DAT`
Discovered sectors, planets, wormholes	`MBMGEPLT.DAT`	`ELWGEPLT.DAT`	`MPOGEPLT.DAT`
In-game mail	`MBMGEMAL.DAT`	`ELWGEMAL.DAT`	`MPOGEMAL.DAT`
Teams	`MBMGETEA.DAT`	`ELWGETEA.DAT`	`MPOGETEA.DAT`

The USR, SHP, PLT, and MAL files are Btrieve databases. Despite its .DAT extension, the TEA file is not a Btrieve database: it is GE's fixed-width text team table. Keep it with the rest of the saved game when backing up or resetting. ge-arena uses only its own MPOGAUSR.DAT and MPOGAPLT.DAT; it does not use persistent ship, mail, or team files.

These game variants have distinct file prefixes. Do not merge their directories or substitute one variant's data files for another's. In particular, a classic MBMGEUSR.DAT is not an in-place replacement for a ge-next MPOGEUSR.DAT, and 16-bit and 32-bit files should not be interchanged without a supported conversion procedure.

Templates and record sizes

The 16-bit packages provide clean *.NEW templates corresponding to their *.DAT files. The 32-bit packages use *.VIR templates for the same purpose. Keep the original templates unchanged so a fresh game can be created later.

The 16-bit Btrieve user, ship, and planet-family records are 246, 501, and 493 bytes respectively. The 32-bit versions use 256-byte user records and 512-byte ship and planet-family records. Mail has its own record format, and the team file is text rather than a Btrieve record set. These sizes matter when choosing the correct package or diagnosing a mismatched file; the individual fields belong in Data structures.

Back up or start over

Before changing files, stop the game or BBS and make a copy of the entire game's data set. Back up the matching .DAT files together, including TEA if present; restoring only a user or planet file can leave ships, scores, ownership, and teams inconsistent. Preserve the clean .NEW or .VIR templates separately from these live-game backups. If the host provides a supported consistent-backup method, that is an alternative to stopping it; ordinary copies taken while Btrieve is writing may contain records from different points in time.

A recoverable installation backup should also include the matching module executable, module-definition and configuration files, compiled main/help/ship-class messages, and any local text resources in use, such as menu text or frontend settings. Record the relevant BBS/module configuration and keep release notes with the backup. Database files are the critical saved game, but they may not be usable with an unrelated DLL or message-file version.

To start a new game, with the module stopped, copy each clean template over its matching .DAT file: for example, MPOGEUSR.NEW to MPOGEUSR.DAT in 16-bit ge-next, or MPOGEUSR.VIR to MPOGEUSR.DAT in ge-next32. Do this for all files used by that game, not just one database. Keep a backup of the old game until the fresh one has started successfully. This resets the game; it is not a way to repair an existing game while preserving its progress.

Upgrades and rollback

Before upgrading, read the intervening release notes and check for changes to database records, file prefixes, configuration options, or required migrations. Keep the old installation and a consistent backup until the new version has been verified. Use the new release's message files as the starting point and merge local configuration values deliberately; replacing messages blindly can discard local settings, while retaining old messages can omit required options or text. A clean .NEW or .VIR template is for starting over, not for upgrading a live game while preserving its players and planets.

After startup, inspect host and module logs, then test the menu, roster, a saved ship and planet, scans, and a database-changing action. Verify scheduled cleanup when practical and keep the previous backup until the new build has seen normal multi-user play. If rollback is needed, restore the executable, messages, configuration, and all related saved records from the same backup point. Replacing only the DLL while leaving records written by a newer layout is not a safe rollback.

MBBSEmu

MBBSEmu converts the module's Btrieve .DAT files to corresponding SQLite .db files and runs the game using those SQLite copies. A .DAT file may remain in the folder even when the live changes are in its .db companion. The team TEA.DAT remains a text file; it does not become a Btrieve-backed .db game database.

For backups under MBBSEmu, stop the emulator and copy the game's .db files and its .DAT files as one set, plus the team file if used. For a full reset, stop MBBSEmu, back up the old files, remove the game's corresponding .db copies, and copy the clean .NEW templates over all of that game's .DAT files (including the team file). MBBSEmu will create fresh SQLite copies when it next loads the module. Merely replacing .DAT while leaving an old .db in place is not a reliable reset.