Scantab

The scantab (short for scan table) is the game's working list of ships detected by one player's scanners. It connects the letters shown on a scan map, usually A through O, to internal ship slots. A letter is meaningful only to the player whose table assigned it: A on one player's screen can be an entirely different ship from A on another's. The table is not a permanent ship registry, a list of planets, or a record of every ship in the galaxy.

What an entry contains

Each player has a separate table with 15 entries (NOSCANTAB). An occupied entry records a ship slot, a letter, its distance from the observer, relative bearing, relative heading, speed, and a state flag. The distance and motion figures are a snapshot taken when the table was rebuilt. The ship slot is an internal position that can eventually be reused; it is not a permanent identity belonging to a commander. The observing ship is excluded from its own table and appears as * on maps instead.

The entries are sorted nearest first. Their positions in the table and their letters are different things. A ship can move from the first entry to the third as distances change and still keep its letter. The table has only 15 entries even though the letter-assignment routine has an A-through-Z alphabet available. In normal play, a fresh table with 15 new contacts assigns A through O.

How the table is built

When a scan-table rebuild occurs, the game saves the letters of ships already in that player's table, then examines active ships other than the observer. It measures each candidate's distance, applies scanner-range and visibility rules, sorts qualifying contacts by distance, and keeps the nearest 15. Surviving contacts retain their old letters where possible; newly included contacts receive unused letters. Empty entries do not represent ships.

For example, suppose a scan assigns A to a nearby frigate and B to a more distant destroyer. If the destroyer moves closer, the next rebuild may put it first in the distance-sorted table, but it can remain B while the frigate remains A. If the frigate leaves range and later returns, its old assignment need not survive: A might meanwhile have been given to another ship. This is why a scan letter is a convenient local reference, not an enduring name or a reliable measure of current distance.

Only the nearest 15 qualifying ships fit. A sixteenth ship can be inside scanner range and still receive no letter in that observer's table. A smaller-scale SCAN RANGE map can show fewer ships than the table holds: both classic GE and ge-next build the table using the ship's full effective scanner range, while the selected scale limits the map. Their accompanying lists differ. In classic GE, SCANFULL can list ships from the full table even when they lie beyond the displayed map scale. ge-next filters its range-scan contact list to the selected scale, so those farther contacts are not listed. SCAN LONG uses broad neutron-distortion detection rather than this lettered contact list. Planet and wormhole numbers come from separate sector data, not the scantab. See Scan command for the different scan displays.

How letters are used

SCAN SHIP A, LOCK A, TORPEDO A, and MISSILE A use a scan letter to select the ship that the player's table associates with it. The command must still pass its own conditions: an identified ship may be outside weapon range, cloaked, or otherwise unavailable. A lock stores a ship slot rather than a letter; @ refers to that stored target even if its scan letter later changes. Neither a letter nor a lock makes a hidden or out-of-range target automatically attackable.

Some messages about other ships also need a letter from the recipient's point of view. The game uses shpltr() to translate a ship slot through that recipient's table. If the ship cannot be identified there, the usual fallback is ?. That may mean the source is genuinely outside range, concealed, or beyond the 15-contact limit; in classic GE it can also mean the recipient has not scanned recently. See Classic bug: Stale scantab and lock state for the distinct causes of question marks and stale references.

How this changed in classic GE

Before version 3.0, a ship's displayed letter corresponded to its BBS channel. Version 3.0a (July 15, 1992) introduced virtual ship channels and proximity-based letters: the nearest visible ship was A, the next B, and so on. Letters could therefore change as relative positions changed. The same release introduced LOCK and @ so a player could continue targeting a particular ship without repeatedly finding its current letter.

Version 3.1b (July 4, 1993) changed letter assignment again. Its release notes say a ship keeps its letter while it remains within the player's scanner range. The final classic 3.2e implementation preserves a continuing contact's letter while rebuilding the distance-sorted table. The table is still local and temporary: disappearing from it, including by falling outside the closest 15, can free a letter for reuse.

In classic 3.2e, SCAN RANGE and SCAN SECTOR rebuild the table. Other paths can consult the last table without refreshing it first. Thus a newly arrived ship may be detectable now but not yet have a letter in a player's stored view; conversely, an old letter can still refer to a ship that has since moved away. Classic's shared target lookup checks whether the selected ship is active and satisfies the requested same-sector or visibility condition, but an old table entry is not itself a fresh detection. This distinction matters when reading a delayed event message or targeting after ships have moved.

ge-next behavior

ge-next retains the per-player, 15-entry, distance-sorted table and persistent letters for continuing contacts. The effective range can be changed by a scan-range upgrade. Its rebuild also applies nebula visibility: ordinary detection cannot cross a nebula boundary, and two ships inside a nebula can ordinarily detect each other only within 1,200 distance units. A fully cloaked ship is likewise excluded from ordinary visible contacts. A target already locked when it becomes hidden by cloak or nebula conditions can remain briefly as an unidentified tracking contact; that does not make it available for detailed scanning or weapon fire. Jamming can scramble or omit information in scan output without making the table a permanent record.

ge-next refreshes the table before resolving a new ship-letter target in the shared command lookup. It also refreshes on demand when a message needs a letter for a ship absent from the recipient's existing table. Consequently, an ordinary letter-based command uses a more current view, and an event does not display ? merely because the recipient has not issued another scan. A fresh table still cannot identify a ship that is truly out of range, concealed, or excluded by the 15-contact limit. Empty entries and preserved letters are validated more carefully than in classic GE.

The scantab is still working state, not a durable identity system. Ship slots can be vacated and reused, and a display letter can be reassigned. For targeting and lock lifetime, see Locks; for the historical overflow and stale-table faults, see Classic bug: Stale scantab and lock state.

Ship selection also borrows the table

In classic GE and ge-next, the ship-selection screen borrows the player's scantab as temporary storage for persistent ship numbers. These entries represent ships the player owns and can choose to board, not nearby sensor contacts. In classic, findships() writes one entry for every owned ship without checking the table's 15-entry limit. A player with more than 15 ships can overwrite another player's scantab or memory beyond the allocated tables. ge-next retains the shared workspace but lists ships in bounded pages of at most 15 and validates the selection. See Classic bug: Ship-selection output overflow for the failure and its correction.