Classic bug: Men do not consume food
| Bug ID | GE-BUG-024 |
|---|---|
| Affected versions | Classic 3.2e and published classic source |
| Status | Verified in source |
| Fixed in | ge-next 0.1; configurable for classic compatibility |
| Primary source | GEPLANET.C: multiply() |
Summary
Classic checks whether a planet has enough food to support its civilian men and kills civilians when food is insufficient. If enough food is present, however, the men do not consume any of it. The same food stockpile can satisfy the civilian check again during every later planetary update.
Troops do consume food. The omission affects only civilian men.
Classic update order
At the beginning of multiply(), classic handles food and starvation in this order:
- Compare troop requirements with the current food stockpile.
- If food is insufficient, kill one eighth of the troops and send a distress message.
- Subtract food consumed by the surviving troops.
- Compare civilian requirements with the remaining food.
- If food is insufficient, kill one eighth of the men and send a distress message.
- Continue directly into taxes and production without subtracting food for the surviving men.
Both populations require one food case per 100 people for each planetary update. Integer division discards populations below 100 when calculating the requirement.
The troop consumption is explicit:
temp = plptr->items[I_FOOD].qty;
if (temp > plptr->items[I_TROOPS].qty / 100) {
temp -= plptr->items[I_TROOPS].qty / 100;
plptr->items[I_FOOD].qty = temp;
} else
plptr->items[I_FOOD].qty = 0;
Classic then performs the civilian starvation test:
if ((plptr->items[I_MEN].qty / 100) > plptr->items[I_FOOD].qty) {
cnt = plptr->items[I_MEN].qty / 8;
plptr->items[I_MEN].qty -= cnt;
/* send civilian starvation distress mail */
}
There is no equivalent subtraction using I_MEN after this block. Execution proceeds to taxes, item production, and revolt calculations.
Simple example
Consider a planet with:
- 10,000 men;
- no troops; and
- 100 food cases.
The civilian requirement is:
10,000 / 100 = 100 food cases
The starvation comparison is strictly greater-than:
if (100 > 100)
It is false, so nobody starves. Classic then omits civilian consumption, and the planet finishes the check with all 100 food cases still present. If the population remains unchanged and no troops are added, those same 100 cases can support the same 10,000 men indefinitely.
With civilian production enabled, population growth can eventually raise the requirement above 100 and trigger starvation. The important defect remains: food is being used as a reusable population threshold, not as a resource consumed every cycle.
Stabilization after starvation
The omission also changes what happens when a planet starts just below its requirement. With 10,000 men and 99 food cases:
- The requirement is 100, which exceeds the available 99.
- Classic kills one eighth of the population: 1,250 men.
- The planet retains 8,750 men and all 99 food cases.
- On the next update, integer division gives a requirement of 87.
- Since 87 does not exceed 99, no more men starve and the food remains at 99.
Unless population growth raises the requirement again, the survivors can continue indefinitely on the same food that previously failed to support the larger population.
Gameplay consequences
The bug makes civilian food logistics much easier than the surrounding design suggests:
- A planet needs a sufficient stockpile, but not a continuing food supply, for its civilian population.
- An owner can stop food production after reaching the desired threshold and assign that labor elsewhere.
- Large civilian populations do not create recurring food demand unless troops are also present.
- Food retains an active role for troop support but has much less economic importance for civilian colonies.
- Civilian starvation can become a one-time population reduction followed by stability on an unchanged stockpile.
This also weakens the intended tradeoff between population growth and food production. Men provide labor, taxes, and production while failing to consume the resource that is checked as their support requirement.
Correction in ge-next
ge-next added the missing civilian consumption immediately after the starvation check:
if (meneat) {
temp = plptr->items[I_FOOD].qty;
if (temp > plptr->items[I_MEN].qty / 100) {
temp -= plptr->items[I_MEN].qty / 100;
plptr->items[I_FOOD].qty = temp;
} else
plptr->items[I_FOOD].qty = 0;
}
The subtraction uses the surviving population, so men killed by that cycle's starvation check are not also charged food. The first released version with this correction was ge-next 0.1.
Because correcting the omission materially changes an established planetary economy, ge-next made it configurable:
MENEAT {Do men eat? YES} B
YES is the ge-next default. Setting it to NO reproduces classic 3.2e behavior.
ge-next also raised the default food-production factor from 8,000 to 12,000, increasing food output to help offset the new recurring civilian demand. Its configuration documentation recommends restoring 8,000 when MENEAT is disabled.
Compatibility notes
This is a missing state update, but correcting it changes long-established game balance. A faithful classic implementation may intentionally preserve the omission. A corrected implementation should either rebalance food production and existing colonies or expose a compatibility option as ge-next does.
When enabling consumption in an existing galaxy, administrators should warn players first. Colonies designed around classic's reusable food threshold may begin consuming large stockpiles or starving as soon as their next planetary update occurs.
Porting guidance
Keep starvation testing and actual resource consumption as separate, explicit steps. Tests should verify the food quantity after an update, not only whether anybody starved. Include cases with exact supply, insufficient supply, troops and men together, fewer than 100 people, and population growth across the requirement boundary.
Home · Play · Reference · Versions & history · Sysop · Development · Classic bugs