Jump to content

Configuring Galactic Empire

From Galactic Empire wiki

Galactic Empire is configured through message-source files, ship-class definitions, and BBS module settings. This page is the sysop's starting point for finding the right file and changing it safely. The classic and ge-next settings are compared at Main configuration reference and Item and equipment configuration; the focused guides explain how groups of settings affect a running game. Begin by deciding whether a change is only to displayed text, to a rule used by future actions, or to the shape of an existing persistent galaxy. These have different upgrade risks.

Where to start

For wording, colors, prompts, and many numeric game options, start with the build's main MSG file and the main configuration reference. For ship capabilities, starting equipment, and automated-ship populations, use Ship class configuration. For radius, boundaries, sector generation, and planet odds, use Galaxy configuration. These guides explain the effect of settings; the MSG reference records the stock classic values, not universal defaults for every build.

BBS/module registration and host-side settings are separate from the game's MSG options. Start with Installing Galactic Empire for package and host setup, MajorBBS integration for the module's relationship to the BBS, or Running Galactic Empire with MBBSEmu for a local emulator installation. For classic registration specifically, see Classic registration and security system. Persistent records, clean templates, and reset procedures belong to Database files, not a text or class MSG file.

Choose the file

Purpose Classic GE Elwynor GE ge-next ge-arena
Main messages and configuration MBMGEMSG.MSG ELWGE.MSG MPOGEMSG.MSG MPOGAMSG.MSG
In-game help MBMGEHLP.MSG ELWGEHLP.MSG MPOGEHLP.MSG MPOGAHLP.MSG
Ship classes and class help MBMGESHP.MSG ELWGESHP.MSG MPOGESHP.MSG MPOGASHP.MSG

The optional classic MBMGEMNU.TXT supplies text for the configurable menu selection; see MBMGEMNU.TXT. Classic also has an open-file bug in that menu path. MBMGEHLP.MSG is preserved here as an original help document, not as instructions for configuring the game.

Find the right reference

How message sources are used

MSG files contain both displayed text and configuration entries. Sysops can edit configurable options with the MajorBBS CNF utility or edit the MSG files directly as text. They are compiled into MCV resources loaded by the module. Code refers to messages by generated identifiers whose values depend on the order of entries in the source file. Reordering or deleting an entry without rebuilding matching code can make the module display unrelated text. Generated headers are build products, not independent configuration files.

Hand editing requires particular care: preserve entry syntax, identifiers, order, option types and ranges, the file's character encoding and line-ending style, and any ANSI control sequences. Keep identifiers within the legacy toolchain's limits; ge-next uses names of no more than eight characters. Formatting parameters must agree with every code path that calls a message. Mismatches can print corrupt output or read invalid memory. Keep visible text and terminal controls suitable for an 80-column display.

When a change takes effect

Editing a source MSG file alone does not change what the running module displays or uses. The matching compiled MCV resource must be regenerated and loaded with the intended module build. Some settings then affect future operations, not data already saved: changing sector-generation odds will not repopulate existing sectors, and changing a ship class definition does not automatically rewrite every stored ship. Likewise, changing a production setting does not immediately run a planetary update. Review Galaxy configuration, Ship class configuration, and Planetary production before assuming an existing galaxy will adopt a new default.

A fresh database is a separate choice, not a normal consequence of recompiling messages. It discards or replaces persistent game state. Database files explains which files form that state and how to keep a rollback copy. Changes to on-disk record layouts or database keys need explicit migration guidance rather than just a new MCV file.

Safe customization

  1. Back up the released sources and record local changes before editing.
  2. Change values or text without reordering identifiers unless the matching module is being rebuilt. Keep class help text consistent with the actual class fields.
  3. Compile the related MSG files into MCV resources and test startup before replacing a live installation. Keep the module and compiled resources from the same build.
  4. When upgrading, merge local settings into the new release rather than copying an old MSG file over the new one.
  5. Before changing a live galaxy, class order, class types, or database filenames, review the applicable guide and upgrade and rollback guidance. Some changes require a fresh database or a release-specific migration.

Classic GE, ge-next, and ge-arena have different option sets and messages. Do not substitute one build's compiled resources for another's. An original MSG description may reflect intended behavior rather than what the classic code does; compare surprising results with the Classic bug database.