Ship slot

A ship slot is one position in the game's in-memory array of active ships. Code uses the slot number to retrieve a ship's current state and to refer to it from scanner entries, target locks, incoming projectiles, mine ownership, and combat-credit fields. It is a live position, not the persistent Ship number assigned to one of a player's saved ships.

Slot identity and lifetime

The first nterms slots correspond to MajorBBS terminal channels. A player on BBS channel 5 uses ship slot 5 while playing, even if channels 0–4 are occupied by people elsewhere on the BBS. Each terminal has one reserved live slot, not one slot for every ship its player owns. On leaving or changing ships, that slot can be emptied or reused while the saved ship's shipno remains unchanged. Likewise, a slot that held one automated ship can later hold another. A stored slot reference must not be mistaken for a permanent identity.

The game allocates nships live slots in total. Slots from nterms onward are available to automated ships; their number comes from the configured NPC allotments in ge-next. A slot can exist without currently holding an active ship. ge-next caps the overall live-slot count at 125, whereas classic's configurable NPC count could exceed limits assumed by other fixed-size structures. See Classic bug: Stale scantab and lock state.

User, Cybertron, and Droid ranges

These are three functional groups, not three different kinds of ship-number record:

Occupant	Where it lives	What the slot means
Player ship	Terminal-channel range, `0` through `nterms - 1`	The slot equals the player's current BBS channel. Only one of that player's saved ships can be active there at a time.
Cybertron	NPC range, beginning at `nterms`	A live automated ship. Standard GE and ge-next save Cybertron records under synthetic identities such as `@Cybrg-23`, where 23 names the slot, not a player fleet's ship number.
Droid	NPC range, beginning at `nterms`	An automated ship allocated from its configured class allotment. Unlike Cybertrons, Droids are transient rather than saved as persistent ships.

For a concrete illustrative layout, suppose the BBS provides 16 terminals and the configured NPC classes request 24 Cybertrons followed by six Droids. The 46 live slots are numbered 0–45: users occupy 0–15, Cybertrons 16–39, and Droids 40–45. The class table further divides the NPC range into consecutive per-class allotments. The Cybertron and Droid ranges are contiguous in this example because those classes were configured in that order; changing their order can interleave them. In classic, all 30 NPC slots form a shared pool rather than reserved per-class ranges, so the example's class boundaries are not guaranteed there. ge-next 0.2 made each NPC slot belong to the class specified by its place in the loaded class table. See Classic bug: NPC class slot crowding.

ge-arena still reserves the terminal-channel range for players. Its NPC range is sized for the largest configured mode and used for that mode's Cybertrons; it has no Droid group at present. Arena ships and Cybertrons are match state rather than the ordinary persistent fleet.

A separate three-group movement schedule

The three movement groups are unrelated to the three occupant types above. Each slot joins a movement group according to its number modulo three:

Group	Example slots	Movement callback
0	0, 3, 6, 15, 18	First one-second pass
1	1, 4, 7, 16, 40	Second one-second pass
2	2, 5, 8, 17, 41	Third one-second pass

The callback cycles through these groups, rotating, accelerating, and moving active ships in just one group each second. For example, a player in slot 1, a Cybertron in slot 16, and a Droid in slot 40 all move on group 1's pass despite being different kinds of occupants. Each active ship therefore receives a movement update roughly every three seconds. The separate six-second system pass visits all active slots for shields, repairs, projectiles, and other ship-state work regardless of movement group. NPC decision-making has its own timer as well. See Game timing.

Inspecting and filling slots with SYS

Authorized administrators can enter SYS LIST to inspect occupied live slots. SYS LIST 40, for example, starts at slot 40; each invocation covers at most 50 slot positions and omits vacant entries. The output includes slot number, ship identity, sector, damage, and NPC timing/target fields; ge-next includes additional diagnostic fields. The command lists live slots, not a player's saved fleet or the full class table. See Sys command.

Standard ge-next adds SYS FILLSLOTS for testing and administration. It immediately initializes every vacant configured NPC slot with the class assigned to that slot and reports how many it filled. It neither creates player ships nor replaces occupied NPCs. Normally the automated-ship scheduler considers one vacant NPC slot every 30 seconds, so this command avoids waiting for a new population to fill gradually. Classic has SYS LIST but not SYS FILLSLOTS; the latter is disabled in ge-arena.

Classic slot-related defects

Classic bug: Channel-zero NPC targeting: channel 0 is a real player slot, but classic also treats zero as an uninitialized NPC target in some paths, preventing normal Cybertron pursuit of that player.
Classic bug: NPC class slot crowding: classic's shared NPC pool and random class choice let one class consume slots needed by another; ge-next reserves slots by configured class.
Classic bug: Stale NPC database records: a saved Cybertron tied to @Cybrg-N could be restored into slot N after configuration changed, even when the slot now belonged to another class.
Classic bug: Stale scantab and lock state: remembered letters and locks can outlive the ship occupying a reusable slot, or identify a different occupant later.
Classic bug: Wormhole projectile cleanup: incoming projectile arrays belong to the target ship while their owner fields name the firing slot; clearing the wrong side left incoming rounds active and detached outgoing rounds from their owner.
Classic bug: Ship-selection output overflow: the fleet selector borrows a per-channel scan table with room for 15 entries; listing more could overwrite the next channel's table.
Classic bug: Cross-user planet cache corruption: a separate per-slot planet cache could also be written one entry out of bounds, corrupting the next channel's cached planet position.