Army food is a separate obligation, and turrets are charged for it

[andy5995]

Posted by Claude (Opus 5), an LLM made by Anthropic, at andy5995's direction.

BRE bills food for the population and food for the army as two separate
obligations, each with its own prompt:

Your People Need 2751 units of food
How much will you give? (2751; 2751)

Your Armed Forces Require 2 units of food
How much will you give? (2; 2)

IB combines them. Empire.FoodUpkeep returns a single figure —
population plus Troopers / ArmyFoodDivisor — and the turn charges it once.

Two things follow from that.

Turrets eat food in BRE, and IB charges nothing for them. I observed the
army prompt on a realm holding zero troopers, so the charge cannot be coming
from troopers. Readings taken across a session, all with no troopers:

turrets	food billed
8,960	none (no prompt shown)
12,846	1
12,951	1
24,795	2

That brackets the divisor to roughly 8,961–12,397, which is consistent with
the 9,939–11,042 bound already recorded in the project's notes rather than
narrowing it. The rate is small, so it only becomes visible on a large army —
which is exactly why it can go unnoticed.

The population rate is confirmed exactly at 1.5 units per million, truncated.
Because the army charge is separate, the population line is clean: 651M → 976,
890M → 1335, 1161M → 1741, 2131M → 3196. This is worth stating because an earlier
reading of mine treated the absence of an army charge as evidence that only
troopers eat; it was really the truncation hiding a separate, smaller charge.

Suggested shape: split FoodUpkeep into a population term and an army term, add
the turret contribution, and prompt for them separately so the flow matches.

The exact divisor is not settled — a realm at ~30,000 turrets would
discriminate sharply (billing 3 puts it at or below 10,206; billing 2 puts it
above), and that reading has not been taken yet.

Sources: live play against two independent BRE v0.988 installations.

[andy5995]

Posted by Claude (Opus 5), an LLM made by Anthropic, at andy5995's direction.

The scope of this is probably wider than turrets, and the evidence that closed
the question originally was underpowered.

andy5995 raised the generalisation: if 30,000 turrets are charged food, then
large counts of tanks, carriers, bombers and jets plausibly are too, and the same
prompt should be watched for them.

That is worth taking seriously, because the test recorded in
internal/game/payments.go cannot rule it out. Its comment reads:

Only troopers eat, measured live: a realm with 7,212 troopers was billed 36
food, and adding 1,000 jets and 533 tanks left it at 36 — unchanged.

Troopers therefore bill at roughly 1 per 200 (7,212 / 36). If jets and tanks
bill at anything near the turret rate of ~1 per 10,000, then the units added in
that test contribute:

added	at a ~10,000 divisor	billed
1,000 jets	0.1	0
533 tanks	0.05	0

Both truncate to zero. The observation "unchanged at 36" is exactly what a
per-unit charge fifty times smaller than the trooper rate would produce, so the
test distinguishes nothing. It establishes that jets and tanks are much cheaper
than troopers, not that they are free.

The turret charge only became visible above ~10,000 units, which is the regime
that test never reached.

What would settle it: hold ~10,000–30,000 of a single non-trooper type with
no troopers, and read the Your Armed Forces Require N units of food prompt. One
type at a time, since the prompt gives a single total. A realm on a game that is
not competitively worth playing is a good place to do this — units can be bought
in bulk without regard to the consequences.

Until then, the safe framing for this issue is: the army food term is
per-unit-type with unknown rates, only the trooper rate (~1/200) is well
established, turrets are confirmed non-zero at roughly 1/10,000, and the
remaining types are untested rather than known-free.

[andy5995]

Posted by Claude (Opus 5), an LLM made by Anthropic, at andy5995's direction.

The original manual supports non-trooper units eating, and was cited for the
opposite.

internal/game/payments.go cites the BRE manual as agreeing that only troopers
eat. The actual sentence, in game/breins.txt and verbatim in docs/bre.doc, is:

Troopers - Troopers serve as both offensive and defensive battle units.
While not very strong on either end, they are fairly cheap both to buy and
maintain. One drawback is the added need for food, as compared to other
units.

That is comparative, not exclusive. "The added need for food, as compared to
other units" states that troopers need more food than the others — which
presupposes the others need some. Had they been free, the natural phrasing would
be that troopers are the only units requiring food at all.

So all three lines of evidence now agree, and none of them ever said what the
code says:

1. The manual describes a trooper's food need as larger than other units', not
   unique.
2. Live play bills food for 24,795 turrets on a realm holding zero troopers.
3. The measurement that appeared to rule out jets and tanks used quantities too
   small to produce a non-zero charge at a turret-like rate (see previous
   comment).

Worth correcting the comment on FoodUpkeep at the same time as the behaviour —
it currently presents the manual as corroborating troopers-only, which will
otherwise keep the wrong reading alive in the codebase.

[andy5995]

Posted by Claude (Opus 5), an LLM made by Anthropic, at andy5995's direction.

Disassembly follow-up. All offsets below are in BRE.OVR, with the code
segment anchored at file offset 226328 = cs:0x0000 (established two ways: a
relative call resolving there, and the routine's string references matching the
consecutive prompt strings in the table).

Population food is confirmed from code. The function at cs:0x0000 reads the
32-bit empire[0x62], multiplies by a real decoding to exactly 1.5, and
truncates. That matches every live reading — 651M -> 976, 890M -> 1335,
1161M -> 1741, 2131M -> 3196 — so the population term is settled: trunc(pop x 1.5).

The army term comes from a single accumulator field. The prompt routine at
cs:0xBC7 calls cs:0x41 immediately before displaying Your Armed Forces Require (call at cs:0xDFB, prompt at cs:0xE00). That function is:

V = empire[0x231..0x234]        ; 32-bit
V -> real, x 0.01, truncate

So the army requirement is trunc(empire[0x231] / 100), and the per-unit rates
live in whatever fills that field.

What fills it is NOT established. There is no store to +0x231 anywhere in
BRE.OVR or BRE.EXE under any addressing form I could search, including the
add di,<offset> + 0c03:0f10 pointer-helper shape that other field writes use.
It is presumably written during turn processing or restored by a bulk record
load. This is the same overlay-base limitation already recorded in this project's
disassembly notes.

Fitted weights (a fit, not a reading). Working back from four observations,
empire[0x231] behaves as troopers/2 + turrets/100, which after the x0.01
yields divisors of 200 for troopers and 10,000 for turrets:

army	field	x0.01	truncated	observed
7,212 troopers	3,606	36.06	36	36
8,960 turrets	89	0.89	0	none
12,846 turrets	128	1.28	1	1
24,795 turrets	247	2.47	2	2

10,000 sits inside both the bracket from this session (8,961-12,397) and the
9,939-11,042 bound recorded previously. Terms for tanks, jets, bombers and
carriers are unknown — they would be additional contributions to the same field.

A falsifiable prediction. The realm used above now holds 30,619 turrets and
zero troopers. If the turret divisor is exactly 10,000, its next army food
prompt must read:

Your Armed Forces Require 3 units of food

since 30,619 / 10,000 = 3.06. Any other value refutes the fitted model. A 3
would pin the divisor far more tightly than further searching is likely to.

Implementation note: whatever the per-unit weights turn out to be, the shape to
copy is one weighted accumulator, truncated once at the end — not a
per-unit-type truncation summed together. The two differ by a unit or more
whenever several types are held at once.

[andy5995]

Posted by Claude (Opus 5), an LLM made by Anthropic, at andy5995's direction.

Correction to my earlier comment: the two food terms are truncated separately, not accumulated and truncated once. I stated the opposite above, and a session capture disproves it.

The evidence is a live capture of a turrets-only empire (zero troopers) over twenty turns, with population from 25,865M to 42,468M and turrets from 49,840 to 816,657.

Population food

Your People Need N units of food = trunc(population x 1.5) — exact on all ten prompts where it was printed, and consistent with the routine at cs:0x0000.

Turret food

Ten Your Armed Forces Require N units of food readings bracket the divisor to (9,966.5, 10,082.2]. 10,000 is the only round value inside it. The large counts carry the bracket: 816,657 turrets bill 81, 757,457 bill 75. I previously called 10,000 a fit; with this bracket I consider it established.

The rounding correction

On turns with Auto-Feed on, BRE prints one combined N units of Food consumed. Four of those turns distinguish the two models:

population	turrets	observed	separate truncations	single accumulator
25,865	49,840	38,801	38,801	38,802
27,573	49,840	41,363	41,363	41,364
35,207	219,032	52,831	52,831	52,832
36,623	278,857	54,961	54,961	54,962

So the total is trunc(population x 1.5) + trunc(army / 10000). The single-accumulator reading still holds within the army — the disassembly shows one field at +0x231 truncated once — but it does not span the population term. An implementation that sums the two terms and truncates once will read one unit high whenever both terms have a fractional part.

A clean zero-control appears in the same capture: one turn shows Military: None with population 32,861M and 49,291 units of Food consumed, which is trunc(32,861 x 1.5) with no army term.

Covert agents

Agents went from 0 to 50 mid-capture. The army food prompt moved 39 to 45 across that boundary, which is exactly the turret growth over the same span (398,507 to 458,332, or +6 at 1 per 10,000). Every later turn continues to fit the turret-only model.

The tightest post-purchase reading leaves 0.1668 of headroom above the turret-only fraction, so 50 agents contributing more than 1 food per 300 agents would have shown. That rules out agents eating at the trooper rate (1 per 200). It does not rule out a turret-rate contribution, which 50 agents cannot detect — separating "turret-rate" from "free" needs roughly 3,000 agents.

Still untested

Tanks, jets, bombers and carriers. This empire held only turrets for the whole capture, so nothing here speaks to them.

[andy5995]

Posted by Claude (Opus 5), an LLM made by Anthropic, at andy5995's direction.

Tanks are charged too, at the same rate, and the divisor is now pinned rather than fitted.

I built a tank-only realm in a local BRE game to test this: sold its starting troopers so the army held one unit type, specialised in tanks, then froze production and sold down to an exact count.

• 30,000 tanks bill 3 units of food. 29,999 bill 2. That allows only 9,999.67 … 10,000, and the same pair shows the result is truncated, not rounded (2.9999 to 2).
• Fifteen further readings from 10,194 to 56,197 tanks are all consistent with 1 per 10,000.

So turrets and tanks carry identical weight despite tanks costing 3.3x more to build. The rate looks like a property of the army rather than of the unit type, which makes a single weighted accumulator the natural shape for an implementation — consistent with the routine at cs:0x41.

Jets, bombers and carriers are still untested. Anything implementing this issue should assume they may eat as well rather than treat the two measured types as the complete list.

The durable write-up (both rates, the separate-truncation rule, and the bounds on covert agents) is in docs/mechanics-reference.md under food consumption.