Data command

The DATA command has two substantially different implementations. In classic Galactic Empire, it is a documented interface for terminal programs, used by frontends such as GECP, but it also exposes a considerable amount of raw internal state and relies on a hardcoded access word. In ge-next, it is a configurable, session-enabled frontend protocol whose output is designed to follow the same information restrictions as ordinary play.

Classic implementation

The classic command is not listed in normal in-game help. GETERM.DOC documents DATA SCAN and DATA REPORT for terminal-program authors, and GEINST.DOC also describes them as commands intended for graphical or other alternative displays. Classic 3.2e additionally implements DATA SECTOR, which is not covered by GETERM.DOC. Its syntax is:

DATA qazwsx REPORT
DATA qazwsx SCAN
DATA qazwsx SECTOR

The middle word is hardcoded in the game. GETERM.DOC calls it the terminal-program password, intended to keep everyday users from using these commands. Because that same word is published in the documentation and source, it is not meaningful authentication. A client must repeat it with every DATA request; there is no session-level enable state.

REPORT

DATA qazwsx REPORT emits user and ship structures as records named UD1, UD2, and SD1 through SD7. Some fields duplicate information available through ordinary reports, including the user ID, score, cash, population, ship name, inventory, position, energy, installed equipment, and registered kills.

Other fields expose implementation details that are not normally available to the player:

Exposed value	Why it is normally hidden
Numeric ship-class index	Normal reports identify the class by name rather than exposing its table index.
Exact numeric hull damage	`REPORT SYSTEMS` describes damage in words instead of displaying the internal damage value.
Raw speed value	The normal navigation report converts internal speed units into the displayed impulse or warp value.
Raw phaser state	The command exposes the internal phaser charge or damage counter rather than only the player-facing operative/inoperative state.
`lastfired`	This is the internal user-channel attribution used when deciding who receives credit for a destruction. It is not a player-visible ship statistic.
Raw shield state and charge	Ordinary reports present the shield state and, while shields are raised, a percentage. DATA exposes the underlying state value and charge.
Raw cloak state	This reveals cloak transition and damage-state values rather than only the visible cloak status.
Tactical and helm damage counters	Normal reports say that these systems are damaged. They do not reveal the exact internal repair magnitude.
Training counter	This is an internal state used by the training sequence, not gameplay information reported to the player.
Raw location code	The `where` field encodes whether the ship is in space, at Zygor, or orbiting a numbered planet. Normal output describes the location instead.
Incoming weapon slots	Every incoming torpedo and missile slot includes its raw source channel and remaining distance. Classic has no equivalent player-facing ordnance report.
Jammer state, hostile state, and combat-exit timer	These are internal flags or countdowns. Their exact values are not shown during normal play.
Maintenance, hyper-phaser, and fire-control counters	These expose internal repair or cooldown state. Classic does not even list damaged fire control in `REPORT SYSTEMS`.
Self-destruct and ship-status values	The player can see a self-destruct countdown as it runs, but cannot ordinarily query its raw counter or the ship record's internal status code.

The result is more than a machine-readable version of the visible reports. It is effectively a partial dump of the user and ship records, including values that can reveal combat state and implementation details to a player or automated client.

SCAN

DATA qazwsx SCAN updates the scanning table and emits the player's scan range, the player's own position, and one row for every visible ship contact. A contact row includes:

its scan-table letter;
exact galactic sector coordinates;
exact local coordinates within the sector;
distance, bearing, relative heading, and speed;
its numeric class index and class name.

A normal range scan plots contacts and gives useful navigational information, but it does not reveal every contact's exact sector and local coordinates. Identifying a ship's class normally requires a ship scan, which can notify the target. Classic DATA SCAN therefore provides precise and sometimes otherwise unavailable information without that notification.

When the player's jammer field is active, classic DATA SCAN suppresses the contact rows and prints ** Jammed **. It does use the normal scan-table construction, so it does not simply reveal every cloaked or out-of-range ship. However, it bypasses the command-level damaged-tactical-system check used by the ordinary SCAN command, allowing the data scan to be requested when the player's tactical scanners are inoperative.

SECTOR

DATA qazwsx SECTOR loads the current sector and emits its exact coordinates followed by every planetary object, including each object's number, exact local coordinates, and raw object type.

Unlike the ordinary sector scan, this path does not apply the tactical-system or jamming checks. A player can therefore use it to recover precise sector layout and object-type information while jammed or while tactical scanners are damaged. This is one of the clearest cases where the classic DATA interface leaks information that normal gameplay intentionally withholds.

Protocol limitations

The classic frontend interface has several limitations by modern protocol standards:

There is no configurable frontend identifier or pairing handshake.
Access relies on a word embedded in the source code.
REPORT records resemble delimited data, while SCAN and SECTOR use different, more human-oriented layouts.
There are no explicit end-of-section records.
User-entered text is not escaped, so delimiters in names can make parsing ambiguous.
Many fields are raw structure values rather than player-visible concepts; even the fields described in GETERM.DOC depend on classic's internal representation.

ge-next implementation

ge-next replaces the classic DATA interface with a frontend protocol that avoids exposing most raw internal state. The command must first be made available through the FRONTEND setting in MPOGEMSG.MSG:

FRONTEND value	Behavior
`OFF`	DATA behaves as an invalid command.
`ALL`	DATA sections are available immediately, although message metadata remains disabled until separately requested.
Any other string	The session must send `DATA ON string`, with an exact case-sensitive match, before using the other DATA commands.

A successful pairing returns an ON: record containing the frontend identifier, project name, version, and architecture. This is an application-level pairing mechanism, not strong authentication, but it allows each game installation to be associated with an intended frontend instead of relying on a universal source-visible password.

Sections

The ge-next interface divides information into independently requested sections:

Command	General contents
`DATA USER`	Player identity, finances, score, population, and related user information.
`DATA SHIP`	Ship identity, class, registered kills, communications frequency, and ship number.
`DATA CAP`	Current ship capabilities.
`DATA INV`	Inventory, cargo weight, and cargo capacity.
`DATA UPG`	Installed upgrades and transponder state.
`DATA NAV`	Navigation information corresponding to `REPORT NAVIGATION`.
`DATA ORD`	Incoming ordnance information corresponding to `REPORT ORDNANCE`.
`DATA SYS`	System condition corresponding to `REPORT SYSTEMS`.
`DATA MSG`	Message-filter settings.
`DATA SCAN`	Parseable range-scan information.
`DATA SHIPSCAN target`	Parseable ship-scan information, subject to the normal ship-scan rules and notification policy.
`DATA SECTOR`	Parseable sector-scan information.

Each data record ends in *, and a completed section ends with STOP:section*. Text fields percent-encode percent signs, commas, asterisks, carriage returns, and line feeds so that user-entered names cannot corrupt the record structure. The FRONTEND.TXT file, included with ge-next, is the authoritative field-by-field protocol reference.

Information visibility

The ge-next routines were written to return the information represented by the corresponding player-facing commands rather than exposing raw structures. Important examples include:

DATA SYS returns descriptive system states and follows the Enhanced Damage Control rules for whether a repair time is visible. It does not expose every raw damage counter.
DATA SCAN and DATA SECTOR apply the relevant range, cloak, nebula, jamming, and damaged-scanner behavior.
DATA SHIPSCAN uses the normal ship-scan behavior. The target receives the same scan notification it would receive from SCAN SHIP, unless the normal locked-target exception applies.
DATA ORD resolves weapon sources into player-facing descriptions instead of exposing reusable MajorBBS channel numbers as identities.
Message metadata is separately enabled with DATA METADATA ON; enabling DATA alone does not turn it on.

There are a small number of deliberate exceptions where a frontend needs information that the terminal interface does not print directly:

DATA SHIP includes the persistent ship number so a frontend can retain per-ship settings.
Mine contacts include exact distance and bearing so a frontend can plot them on a map. The terminal scan plots mines graphically but does not list those two numbers.

These are explicit protocol decisions rather than the broad, incidental disclosure of internal fields found in the classic command.

ge-arena

ge-arena uses the same access, framing, escaping, scan restrictions, and metadata system. It retains applicable ge-next sections and adds arena-specific records such as match state and player standings. Fields that have different meanings in an arena mode are documented separately in the ge-arena section of FRONTEND.TXT.

Summary of differences

Area	Classic GE	ge-next
Access	Hardcoded word repeated with every request	Configurable per-installation setting and per-session pairing
Purpose	Documented terminal-program interface used by frontends, including GECP; exposes raw state	Documented frontend protocol
Information policy	Exposes numerous hidden counters, channel numbers, and structure fields	Generally mirrors information available through normal player commands
Scan restrictions	Some DATA paths bypass damaged-scanner, notification, or jamming behavior	Reuses normal visibility and notification rules
Framing	Inconsistent layouts with no common terminator	Named records and `STOP:` terminators
User text	Not escaped	Percent-encoded where required
Message tagging	None	Optional, separately enabled metadata records