Jump to content

Classic bug: Stationary Cyber-Base movement

From Galactic Empire wiki
Bug ID GE-BUG-016
Affected versions Classic 3.2e and published classic source
Status Verified in source and gameplay
Fixed in ge-next 0.2
Primary source GECYBS.C: cyb_check_lockon() and cyb_lives(); GEFUNCS.C: rotateship(), moveship(), and telezip()

Summary

The classic Cybertron pursuit routine can directly give a Cybertron Base Star movement speed even though the class is configured with zero acceleration and zero maximum warp. The same zero acceleration gives the Base a turn rate of zero, so it moves without being able to rotate toward the ship it is pursuing.

A distant player can exploit the interaction by attacking a Base once and fleeing. The attack assigns that player to the Base's cybmine target field. When the target becomes sufficiently distant, pursuit gives the Base an immediate high speed. It commonly continues along its old heading, repeatedly strikes the galactic perimeter, accumulates perimeter damage, and eventually destroys itself.

Intended class behavior

The default Cybertron Base Star is class 23. Its class settings include:

Property Default
Acceleration 0
Maximum warp 0

The Base is intended to remain where it was generated. It can scan nearby ships, select attackers, raise shields, fire its weapons, and produce Cyber-Base messages, but it should not cruise or pursue targets across the galaxy.

Classic implicitly uses zero acceleration as the sign that a class is immobile in some movement calculations. It does not enforce that rule at the AI decision point where pursuit speed is assigned.

How a Base acquires a target

Cybertrons store the ship they are pursuing in cybmine; 255 means that no target is assigned. Successful attacks on an automated ship set its cybmine to the attacker's channel. Projectile launch and targeting paths can also provoke a Cybertron before impact under classic's combat rules.

The Base is an automated Cybertron, so these assignments apply to it just as they do to mobile Cybertron classes. Once a player has provoked it, cyb_check_lockon() treats the Base as a pursuing ship.

The long-range pursuit bypass

The ordinary acceleration routine would not make the Base move. Its acceleration rate is zero, so incrementing its current speed toward a requested speed cannot make progress.

Long-range Cybertron pursuit bypasses that protection. When the distance to cybmine is at least hyperdist1, classic effectively executes:

speed2b = distance * 2000;
speed = speed2b;
head2b = bearing to target;
where = hyperspace;

Assigning speed directly is the critical error. The code does not ask whether the class has propulsion and does not wait for accel(). A zero-acceleration Base instantly receives the same special long-range pursuit movement used by mobile Cybertrons.

At intermediate distances the pursuit path can also set a requested cruising speed and heading. The direct long-range assignment is what turns the defect into dramatic movement from an otherwise stationary object.

Why the Base cannot steer

Classic calculates rotation per movement update as:

rotation amount = class acceleration / 10

For a Cybertron Base, that is zero. Pursuit updates head2b to point at the target, but rotateship() cannot move the actual heading toward it. Except for the unlikely case where the existing heading already exactly matches the desired heading, the Base retains its old orientation.

The result is not a Base sensibly chasing a player. It is a stationary class given a large velocity along whatever heading it happened to have. If that heading points away from the target, pursuit can make the Base travel farther away while continuing to request a heading it can never reach.

Perimeter self-destruction

With galaxy wrapping disabled, moveship() handles a perimeter crossing by placing the ship just inside the boundary and calling telezip(). That routine:

  • sets current and requested speed to zero;
  • adds TELEDAM, normally 17 points, to ship damage; and
  • prints the galactic-perimeter collision message.

Stopping the Base does not clear cybmine. Its distant target is still valid, so a later Cybertron behavior update enters long-range pursuit again and directly restores high speed. Because the Base still cannot turn, it can run into the same edge repeatedly.

Each collision adds more damage. Automatic repair may reduce some damage between impacts, but repeated 17-point perimeter penalties eventually drive the Base to the destruction threshold. The general damage check then destroys and removes it like another killed ship.

Gameplay exploit

A player does not need enough weapons to defeat the Base's shields and enormous durability directly:

  1. The player finds a Cybertron Base and lands a provoking shot.
  2. The shot records the player as the Base's cybmine target and normally also as lastfired when it causes an effective hit.
  3. The player retreats until the long-range pursuit threshold is crossed.
  4. Pursuit assigns movement speed directly to the Base.
  5. The Base cannot rotate toward the player and travels on its existing heading.
  6. It reaches the perimeter, takes damage, stops, and then launches itself again because the pursuit remains active.
  7. Repeated perimeter collisions eventually destroy the Base.

In effect, taking one shot at a Base and then fleeing can lead to its destruction without the player defeating it in combat. If the attacker's lastfired attribution remains on the Base, classic can credit that attacker with the kill and its substantial Cyber-Base score even though perimeter damage delivered the fatal damage.

Even when the player is not credited, the bug removes a rare, high-value NPC through its own navigation logic. It also causes a supposedly fixed installation to disappear from its generated location, making later attempts to find the announced or previously scanned Base confusing.

Other visible consequences

Depending on its original heading and the target's movement, players may observe:

  • a Cybertron Base changing sectors or appearing in hyperspace;
  • a Base moving away from the player it is supposedly pursuing;
  • repeated perimeter warnings associated with an NPC;
  • the Base vanishing after accumulating unexplained damage; or
  • a delayed Base kill awarded after the attacker has long since left the area.

The behavior can be intermittent because the existing heading, starting position, target direction, repair between impacts, and timing of Cybertron updates all affect how quickly the Base reaches and repeatedly strikes a boundary.

Correction in ge-next

ge-next 0.2 made zero acceleration an explicit exclusion from pursuit rather than relying on the later acceleration routine to prevent movement.

The correction is applied at multiple AI entry points:

  • automatic pursuit assignment ignores Cybertrons whose class acceleration is zero;
  • the main Cybertron update does not call damage-flee or lock-on movement logic for a zero-acceleration class;
  • generic NPC cruising returns before assigning speed or heading to an immobile class; and
  • other movement reactions, such as jammer evasion and zipper escape behavior, are similarly gated by positive acceleration.

A Base can still set or retain cybmine for combat purposes. It can recognize and fire on an attacker who is within range, but that target state no longer authorizes movement. Its coordinates remain fixed unless an external administrative or game-world operation deliberately relocates it.

Porting guidance

Immobility should be enforced before every AI operation that assigns current speed, requested speed, or heading. Checking only the physical acceleration step is insufficient when pursuit, teleportation, scripted movement, or emergency behavior can write speed directly.

A useful invariant is: when a class has zero acceleration, ordinary AI must never increase its speed above zero. Target acquisition and weapon behavior can remain independent of that invariant.