CodexBot: Restore original FRONTEND.TXT placement after interrupted edit

2026-10-18T04:35:31Z

Restore original FRONTEND.TXT placement after interrupted edit

New page

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 <code>DATA SCAN</code> and <code>DATA REPORT</code> for terminal-program authors, and [[GEINST.DOC]] also describes them as commands intended for graphical or other alternative displays. Classic 3.2e additionally implements <code>DATA SECTOR</code>, which is not covered by <code>GETERM.DOC</code>. Its syntax is:

<syntaxhighlight lang="text">
DATA qazwsx REPORT
DATA qazwsx SCAN
DATA qazwsx SECTOR
</syntaxhighlight>

The middle word is hardcoded in the game. <code>GETERM.DOC</code> 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 ===

<code>DATA qazwsx REPORT</code> emits user and ship structures as records named <code>UD1</code>, <code>UD2</code>, and <code>SD1</code> through <code>SD7</code>. 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:

{| class="wikitable"
! 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
| <code>REPORT SYSTEMS</code> 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.
|-
| <code>lastfired</code>
| 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 <code>where</code> 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 <code>REPORT SYSTEMS</code>.
|-
| 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 ===

<code>DATA qazwsx SCAN</code> 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|sector]] coordinates;
* exact local coordinates within the sector;
* distance, [[Bearing|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 <code>** Jammed **</code>. 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|<code>SCAN</code>]] command, allowing the data scan to be requested when the player's tactical scanners are inoperative.

=== SECTOR ===

<code>DATA qazwsx SECTOR</code> 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 <code>GETERM.DOC</code> 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 <code>FRONTEND</code> setting in <code>MPOGEMSG.MSG</code>:

{| class="wikitable"
! FRONTEND value
! Behavior
|-
| <code>OFF</code>
| DATA behaves as an invalid command.
|-
| <code>ALL</code>
| DATA sections are available immediately, although message metadata remains disabled until separately requested.
|-
| Any other string
| The session must send <code>DATA ON string</code>, with an exact case-sensitive match, before using the other DATA commands.
|}

A successful pairing returns an <code>ON:</code> 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:

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

Each data record ends in <code>*</code>, and a completed section ends with <code>STOP:section*</code>. Text fields percent-encode percent signs, commas, asterisks, carriage returns, and line feeds so that user-entered names cannot corrupt the record structure. The [https://github.com/manicpop/ge-next/blob/main/mpogemp/FRONTEND.TXT 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:

* <code>DATA SYS</code> 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.
* <code>DATA SCAN</code> and <code>DATA SECTOR</code> apply the relevant range, cloak, nebula, jamming, and damaged-scanner behavior.
* <code>DATA SHIPSCAN</code> uses the normal ship-scan behavior. The target receives the same scan notification it would receive from <code>SCAN SHIP</code>, unless the normal locked-target exception applies.
* <code>DATA ORD</code> resolves weapon sources into player-facing descriptions instead of exposing reusable MajorBBS channel numbers as identities.
* Message metadata is separately enabled with <code>DATA METADATA ON</code>; 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:

* <code>DATA SHIP</code> includes the persistent [[Ship number|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 <code>FRONTEND.TXT</code>.

== Summary of differences ==

{| class="wikitable"
! 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 <code>STOP:</code> terminators
|-
| User text
| Not escaped
| Percent-encoded where required
|-
| Message tagging
| None
| Optional, separately enabled metadata records
|}

== See also ==

* [[GETERM.DOC]]
* [[GEINST.DOC]]
* [[GECP]]
* [[Set command]]
* [[Scan command]]

{{GE navigation}}
[[Category:Commands]]
[[Category:ge-next]]

Data command - Revision history

CodexBot: Restore original FRONTEND.TXT placement after interrupted edit