Mine command
The MINE command leaves one timed neutron mine at the firing ship's current coordinates. The mine does not follow the ship after launch; its countdown and explosion are described on Mines.
Syntax
MINE delay
The command may be abbreviated to MIN. delay must be an integer from 1 through 50. Each mine tick is one main ship-state update, normally six seconds, so MINE 10 schedules detonation in approximately 60 seconds. Classic 3.2e calls these ticks “centocks” and describes them as about five seconds, but its configured update interval is six seconds. ge-next displays both ticks and nominal seconds when a mine is launched.
Deployment checks
The ship class must support mines, the ship must carry at least one, and it cannot be cloaked or in the neutral zone. The delay must be in range, the laying ship must be below its active-mine limit, and the global mine table must have a free slot. ge-next also refuses deployment if the mine launcher is damaged or reloading, or the ship is already at fatal damage. Classic does not have those additional launcher-state checks.
The command does not require the ship to stop, leave orbit, or exit hyperspace. A successful launch records its position at that instant, consumes one carried mine, and starts the laying ship's combat-exit timer. It does not consume neutron flux or lower raised shields. A failed launch does not consume the mine.
Limits and responses
USRMINES limits how many active mines one ship slot can own; its stock value is three in both classic and ge-next. NUMMINES limits all active mines combined; the stock value is 12 in classic 3.2e and 18 in ge-next. These are sysop-configurable limits on deployed mines, not inventory capacity. Once an active mine detonates, its slot becomes available again.
Classic uses the same “launcher temporarily jammed” message when either limit blocks deployment. ge-next gives separate responses for the per-owner limit, a full global table, and a reloading launcher. A successful ge-next deployment starts a one-update mine-launcher reload delay.
Because mines live in the global in-memory table, they do not persist through a module restart or cleanup. In classic, a mine remains active under the original ship-slot number after its owner is destroyed or leaves; it still counts against that slot's USRMINES limit, even if another player later occupies the slot. In ge-next, the mine remains active but becomes ownerless and no longer counts against the former owner's limit. See ownership and kill credit.
See also
Home · Play · Reference · Versions & history · Sysop · Development · Classic bugs