Galactic Empire wiki

Classic bug: Reports list nonexistent phasers and shields

Bug ID GE-BUG-046
Affected versions Classic 3.2e when a ship class has no shields or phasers
Status Verified in source; corrected in ge-next
Fixed in ge-next 0.1
Primary source initship() in GEFUNCS.C and REPORT SYSTEMS in cmd_report() in GECMDS.C

Summary

Classic can list shields and phasers in a ship's systems report even when the ship's class has no capability for those systems. A newly created ship always receives Mark-1 values in its ship record, and REPORT SYSTEMS mistakes those stored values for proof that the class supports the equipment.

The rest of the game generally uses the class configuration as the authority. The result is a contradictory ship: its report claims that it has a Mark-1 system, but attempting to operate that system correctly reports that the ship does not have one.

Classic's default ship table does not contain any active class with a maximum shield or phaser level of zero. The stock configuration therefore conceals the defect. It becomes visible if an administrator customizes a class to omit one of those systems, or if a descendant uses additional zero-capability classes.

Two different kinds of values

GE stores related information in two places:

  • shipclass[class].max_shlds and max_phasr describe what that class of ship is physically capable of carrying. A maximum of zero means that the class has no such system.
  • shieldtype and phasrtype in an individual ship record describe the installed Mark level.

The classic ship configuration explicitly documents zero as a supported value. For example, its phaser option says that setting the maximum to zero means that the class has no phasers at all. The equivalent rule applies to shields.

For a capable class, both sets of values are useful. The class maximum limits installation and use, while the ship value records the player's current equipment. For an incapable class, however, an installed level is not a valid independent indication that the system exists.

Unconditional ship initialization

Classic's initship() initializes every new user ship with these values, without checking the selected class: 

tmpshp.phasr      = 100;
tmpshp.shieldstat = SHIELDDN;
tmpshp.shield     = 0;
tmpshp.shieldtype = 1;
tmpshp.phasrtype  = 1;

This is harmless for the stock classic table because every active default class supports at least a Mark-1 shield and phaser. If a class maximum is changed to zero, however, its newly created ships still retain the two Mark-1 type fields. The phaser charge also starts at 100.

The bad display can also arise if an existing ship record retains an installed type after the administrator changes that class's maximum to zero.

Faulty report tests

The systems-report path decides whether to print each system by checking the individual ship's installed type: 

if (warsptr->shieldtype > 0)
    {
    /* print shield type and state */
    }

if (warsptr->phasrtype > 0)
    {
    /* print phaser type and state */
    }

Because initship() sets both values to one, those conditions are true even when the class maxima are zero. A new zero-capability ship can therefore include lines equivalent to: 

Shields (Mark-1)...... DOWN
Phasers (Mark-1) <operative>

The phaser is described as operative because the same initialization gave it a positive charge. Neither line reflects the class's actual capabilities.

Contradiction during play

The operating commands use the correct source of truth. Classic's phaser command first checks: 

if (shipclass[warsptr->shpclass].max_phasr == 0)
    {
    prfmsg(PHASER0);
    outprfge(ALWAYS,usrnum);
    return;
    }

The shield command performs the corresponding max_shlds == 0 test. Consequently, the same ship can produce this sequence of results:

  1. REP SYS lists a Mark-1 shield and an operative Mark-1 phaser.
  2. SHIELDS UP answers, “We don't have a shield system on this ship, Sir!”
  3. PHASER answers, “We don't have a lousy Phaser system on this tub, SIR!!”

The commands are correct; the report is not. The false entries do not grant the ship usable equipment because combat and shield operation remain gated by the class maxima. The primary consequence is misleading status information, although other code that treats a positive installed type as capability would be vulnerable to the same inconsistent record state.

Why stock classic normally hides it

Classic permits 0 through 19 for both class options and documents the meaning of zero, but all of its active default user, Cybertron, and Droid classes have nonzero maxima. Even its unused class slots are shipped with nonzero placeholder values.

An unmodified classic installation therefore has no ordinary way to obtain a ship class that exposes the report error. This is still a code defect rather than merely unsupported configuration: the supplied configuration interface expressly permits zero, and the operational commands already implement the intended no-system behavior.

ge-next's expanded ship configuration included user classes without shields, without phasers, or without either. That made the dormant classic reporting assumption immediately visible and required the code path to be corrected.

Correction in ge-next 0.1

ge-next changed only the tests that determine whether each report section is applicable: 

if (shipclass[warsptr->shpclass].max_shlds != 0)
    {
    /* print shield type and state */
    }

if (shipclass[warsptr->shpclass].max_phasr != 0)
    {
    /* print phaser type and state */
    }

The report now asks the same fundamental question as the operating commands: does this class support the system? If not, the entire line is omitted.

For capable ships, the report continues to use the individual ship's shieldtype or phasrtype to display its installed Mark level. The correction therefore preserves legitimate per-ship upgrades while suppressing only equipment the class cannot possess.

No ship-record migration was required. The legacy Mark-1 values may remain in records for zero-capability classes, but they are no longer presented as real equipment and cannot be operated. The same correction is present in the 32-bit ge-next port.

Retrieved from "https://manicpop.org/gewiki/index.php?title=Classic_bug:_Reports_list_nonexistent_phasers_and_shields&oldid=1570"