Classic bug: Planet spy attack result inversion

Bug ID	GE-BUG-029
Affected versions	Classic 3.2e and published classic source/message file
Status	Verified in source and message definitions
Fixed in	ge-next 0.02 (message-file release running on the classic 3.2e DLL)
Primary source	call_4_help() and the reversed SPYM3/SPYM4 messages

Summary

Classic GE sends planetary spies the wrong result after an attack. A failed attack can be reported as a successful conquest, while a successful conquest is reported as an attack whose outcome was unclear.

The combat result and planet ownership are processed correctly. The bug is an inversion between the message identifiers selected by the attack code and the text assigned to those identifiers in MBMGEMSG.MSG.

Player-visible behavior

When a qualifying attack occurs on a planet containing another player's spy, the spy may send its owner an intelligence report.

Classic can produce these contradictory reports:

• If the defenders survive and the attacker does not capture the planet, the spy report can state that the attacker toppled the defenses and took over the planet.
• If the attacker does capture the planet, the spy report states only that an attack was launched and that its outcome was unclear.

The report is misinformation generated by the game, not uncertainty in the underlying battle calculation. Checking the planet later reveals that its real owner does not match the spy's report.

Both troop and fighter attacks are affected because both attack paths pass their result to the same notification helper.

How spy attack reports are selected

The troop and fighter routines maintain a won flag. A value of zero means that the attack did not conquer the planet; a value of one means that it did. After combat, they call call_4_help(), which can notify the planet owner and, under the applicable conditions, mail an intelligence report to plptr->spyowner.

The relevant classic branches are structurally correct:

if (won == 0 && send_spy_mail && gernd() % 6 == 0
    && plptr->spyowner[0] != 0)
{
    prfmsg(SPYM3, ...);
    /* send intelligence report */
}
else if (won == 1 && plptr->spyowner[0] != 0)
{
    prfmsg(SPYM4, ...);
    /* send intelligence report */
}

For an unsuccessful but sufficiently significant attack, the first report is also subject to the one-in-six random check shown above. A successful conquest uses the second branch without that random check once the helper is reached.

Cause

The two message bodies are assigned in reverse in the classic message file.

Classic SPYM3, selected when won == 0, says:

...hostile forces ... have toppled the defenses and taken over the planet.

Classic SPYM4, selected when won == 1, says:

...hostile forces ... launched an attack on this planet.
The outcome was unclear as of this report.

The message names themselves do not describe success or failure, so the error is easy to miss while reading either the C source or message file alone. The inversion becomes apparent only when the branch conditions and message bodies are compared.

Correction in ge-next

ge-next 0.01 and 0.02 were not yet compiled replacements for Galactic Empire. They supplied revised MSG, help, configuration, and related data files that ran on the original classic 3.2e DLL. Consequently, ge-next 0.02 corrected this bug without changing call_4_help() or any executable code. It swapped the contents of SPYM3 and SPYM4 in the message file:

• SPYM3, used for won == 0, now reports that the outcome was unclear.
• SPYM4, used for won == 1, now reports that the defenses were toppled and the planet was taken.

No battle calculation or ownership logic needed to change. The unmodified classic DLL continued selecting the same identifiers, but the corrected message mapping made its intelligence reports agree with the results it had already calculated.

An equivalent porting fix would be to exchange the two message identifiers in call_4_help(), but correcting the message definitions preserves the existing code's apparent SPYM3-then-SPYM4 progression.

Home · Play · Reference · Versions & history · Sysop · Development · Classic bugs