CodexBot: Link Btrieve explanation at first mention

2026-10-18T17:53:49Z

Link Btrieve explanation at first mention

New page

'''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 ==
{| class="wikitable"
! Purpose !! Classic GE !! Elwynor GE !! ge-next (0.3+)
|-
| Players, preferences, scores || <code>MBMGEUSR.DAT</code> || <code>ELWGEUSR.DAT</code> || <code>MPOGEUSR.DAT</code>
|-
| Persistent player ships || <code>MBMGESHP.DAT</code> || <code>ELWGESHP.DAT</code> || <code>MPOGESHP.DAT</code>
|-
| Discovered sectors, planets, wormholes || <code>MBMGEPLT.DAT</code> || <code>ELWGEPLT.DAT</code> || <code>MPOGEPLT.DAT</code>
|-
| In-game mail || <code>MBMGEMAL.DAT</code> || <code>ELWGEMAL.DAT</code> || <code>MPOGEMAL.DAT</code>
|-
| Teams || <code>MBMGETEA.DAT</code> || <code>ELWGETEA.DAT</code> || <code>MPOGETEA.DAT</code>
|}

The <code>USR</code>, <code>SHP</code>, <code>PLT</code>, and <code>MAL</code> files are Btrieve databases. Despite its <code>.DAT</code> extension, the <code>TEA</code> 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 <code>MPOGAUSR.DAT</code> and <code>MPOGAPLT.DAT</code>; 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 <code>MBMGEUSR.DAT</code> is not an in-place replacement for a ge-next <code>MPOGEUSR.DAT</code>, 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 <code>*.NEW</code> templates corresponding to their <code>*.DAT</code> files. The 32-bit packages use <code>*.VIR</code> 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 <code>.DAT</code> files together, including <code>TEA</code> if present; restoring only a user or planet file can leave ships, scores, ownership, and teams inconsistent. Preserve the clean <code>.NEW</code> or <code>.VIR</code> 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 <code>.DAT</code> file: for example, <code>MPOGEUSR.NEW</code> to <code>MPOGEUSR.DAT</code> in 16-bit ge-next, or <code>MPOGEUSR.VIR</code> to <code>MPOGEUSR.DAT</code> 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 <code>.NEW</code> or <code>.VIR</code> 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 <code>.DAT</code> files to corresponding SQLite <code>.db</code> files and runs the game using those SQLite copies. A <code>.DAT</code> file may remain in the folder even when the live changes are in its <code>.db</code> companion. The team <code>TEA.DAT</code> remains a text file; it does not become a Btrieve-backed <code>.db</code> game database.

For backups under MBBSEmu, stop the emulator and copy the game's <code>.db</code> files '''and''' its <code>.DAT</code> 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 <code>.db</code> copies, and copy the clean <code>.NEW</code> templates over '''all''' of that game's <code>.DAT</code> files (including the team file). MBBSEmu will create fresh SQLite copies when it next loads the module. Merely replacing <code>.DAT</code> while leaving an old <code>.db</code> in place is not a reliable reset.

== See also ==
* [[Data structures]]
* [[Integer and storage assumptions]]
* [[MBBSEmu]]
* [[Classic registration and security system]]

{{GE navigation}}
[[Category:Sysop documentation]]
[[Category:Development]]

Database files - Revision history

CodexBot: Link Btrieve explanation at first mention