Classic bug: Disabled production repeats maximum-stock notices

Bug ID	GE-BUG-034
Affected versions	Classic 3.2e and published source
Status	Verified in source
Fixed in	Partially corrected in ge-next 0.1; planetary production remains scheduled for a future redesign
Primary source	Maximum-stock test in multiply()

Summary

When an item on a classic GE planet reaches its storage maximum, the owner receives a production report saying that no more items can be stored and that production has been suspended. The same report can then be generated during every subsequent planetary production update.

Changing that item's production allocation to zero does not stop the reports. The player must reduce the quantity stored on the planet below its maximum, usually by transferring at least one item to a ship. If the player does not want the item, it must then be sold, transferred elsewhere, or jettisoned.

This is best understood as an oversight in the maximum-stock notification design. It does not corrupt the planet record, but it can repeatedly fill a player's mail with reports that convey no new information and cannot be disabled through the production controls alone.

Classic production test

For each item, multiply() begins with the quantity already stored on the planet and adds the amount calculated for the current update:

temp = plptr->items[i].qty;
temp += (long)(qty * fact);

It then calculates that planet's current maximum for the item. Classic decides to send a maximum-stock report with this condition:

if (plptr->items[i].qty <= max && temp >= max)
{
    temp = max;
    /* construct and send the production report */
}

The test appears intended to detect the transition from below the maximum to the maximum. Both comparisons are inclusive, however. Once the stored quantity is exactly max, it continues to satisfy the left side on every update. The projected quantity also remains at least max, satisfying the right side.

The classic 3.2e release notes say that players will receive only the first message when production reaches its maximum. The implementation does not reliably achieve that stated behavior.

Why zero production does not help

An item's production allocation is stored in items[i].rate. Setting the allocation to zero makes the newly produced quantity zero, but it does not change the inventory already stored:

stored quantity = maximum
new production  = 0
projected total = maximum + 0 = maximum

The classic test therefore becomes:

maximum <= maximum && maximum >= maximum

Both expressions are true, and another report is sent. The message may say that production was suspended, but the code neither clears nor suspends the allocation. It only clamps temp to the maximum before storing the quantity.

Reducing the inventory by one item finally makes the zero-production case evaluate below the cap:

stored quantity = maximum - 1
new production  = 0
projected total = maximum - 1

That stops the notice, but it forces the player to manipulate cargo merely to acknowledge a production condition that was already addressed through the planetary administration screen.

Gameplay consequences

The problem becomes particularly noisy for players who administer several mature colonies. Every capped item on every updated planet can generate another production report. A player can reduce future production to zero but still continue receiving the same reports until each affected stockpile is brought below its maximum.

The notices are not evidence that more items were created. The calculated quantity is clamped to the same maximum each time. They are repeated reports of an unchanged state.

Partial correction in ge-next

ge-next 0.1 changed the final notification test so that the calculated total must actually exceed the maximum:

if (final_mult == TRUE && temp > max) {
    temp = max;
    /* construct and send the production report */
}

With production set to zero, a full stockpile produces temp == max, not temp > max, and the repeated reports stop. If production remains enabled and attempts to add more items, the report can still be generated on later production cycles.

This is a practical suppression of the most frustrating case, not a complete solution to planetary capacity and production reporting. The allocation is still not automatically suspended, and the system does not remember that a particular capacity warning has already been acknowledged. Planetary production, storage limits, and reporting are intended to receive a broader redesign in a future ge-next release.

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