Queen Royale tax refund event is not implemented

[andy5995]

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

Starting a turn in BRE produced an event IB has no equivalent for:

Since your last play, this has happened:

You have no messages.

The Queen Royale has given you a 1,000,000 coin tax refund!

It appeared in the "since your last play" block, alongside the message summary,
before the turn's income screen. IB has a random per-empire event system but
nothing that refunds crown tax.

This pairs naturally with the crown tax IB already implements (#52): the Queen
Royale takes a cut every turn, and this is her occasionally giving some back.
That makes it a thematic counterweight to an existing sink rather than a
standalone faucet.

The mechanics are unknown and this is a single observation. I have not
established how the amount is determined (whether 1,000,000 is fixed, scaled to
the realm, or related to tax actually paid), how often it fires, or whether
anything gates it. Anyone implementing this should gather more samples first
rather than treat the one figure above as the rule.

[andy5995]

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

Disassembly follow-up. The routine sits immediately after the has given you a … coin tax refund! string in BRE.OVR (string at file offset 98933, code at
98944). Reconstructed:

V    = [0x28b4]+0x24                            ; planet-wide longint
rate = 0.02 + (V > 100,000,000 ? 0.05 : 0)      ; 2%, or 7% past the threshold
if predicate(byte [0x28dc]) and V*rate > 1,000,000:
        rate = 1,000,000 / V                    ; implements a hard cap
refund = V * rate

So refund = min(V x rate, 1,000,000), at 2% rising to 7% once the pool
passes 100 million.

The real constants were decoded with the project's bre-tpreal.py:

register triple	value
cx=0xcd7c si=0xcccc di=0x4ccc	0.05
cx=0x717b si=0x0a3d di=0x23d7	0.02
cx=0x0094 si=0x0000 di=0x7424	1000000.0

The threshold is an unsigned 32-bit compare against 0x05F5E100 = 100,000,000.
The cap is not a min() call — the code overwrites the rate with 1,000,000 / V
so the subsequent multiply lands exactly on the cap.

V is planet-wide, not per-empire. [0x28b4] is already mapped in this
project's notes as the planet record — it holds the daily food pool at +0x1c.
That resolves the puzzle in the original report: the realm that received
1,000,000 had a net worth of 2,787, which no per-empire percentage could produce.
It also means the observed payout was the cap, so V x rate was at or above
1,000,000 at the time (V >= 50,000,000 at 2%, or >= 14,285,715 at 7%).

What is not established:

• What V counts. Its position beside the food pool says planet-wide. An
  accumulated crown-tax pool fits both the theme and the magnitude, but I did not
  trace any writer to that field, so this is a hypothesis.
• That this routine is the refund. The evidence is string adjacency plus the
  shape of the output call. I could not confirm by cross-reference because the
  overlay segment base is unknown — the same blocker recorded elsewhere in this
  project's disassembly notes.
• Firing frequency. The whole block is gated by a predicate call on byte
  [0x28dc]; when it returns false the routine does nothing. andy5995 believes
  the refund arrives only on the first play of the day rather than on every
  entry, which that gate would be a natural place to implement. The predicate was
  not identified, so this is consistent-with, not confirmed.

Implementation note: if IB adopts this, the interesting part is not the payout
but that it is a planet-scoped pool — every empire draws refunds from one
shared quantity, and the 2% -> 7% step means a large pool pays out faster. That
is a different mechanic from a per-empire random bonus, and modelling it as the
latter would miss the point.

[andy5995]

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

Correction to my previous comment, plus the rest of the routine.

I wrote that the predicate on [0x28dc] gates the whole routine and that "when
it returns false the routine does nothing." That is wrong. The jz jumps to
0xc8, which is past the cap block but still performs the crediting and the
output. The predicate gates only the cap:

V    = [0x28b4]+0x24                            ; planet-wide pool
rate = 0.02 + (V > 100,000,000 ? 0.05 : 0)
if predicate(empire) and V*rate > 1,000,000:
        rate = 1,000,000 / V                    ; cap applies only in this branch
refund = round(V * rate)                        ; otherwise uncapped
empire[0x28d8]+0x66 += refund
V = round(V * (1 - rate))                       ; pool drawn down by the same fraction
[0x28b4]+0x24 = V

Since the observed payout was exactly 1,000,000, the predicate was true for that
realm and the cap fired.

V is confirmed as a drawn-down pool, not a counter. The routine ends by
writing V * (1 - rate) back to [0x28b4]+0x24. The refund is therefore paid
out of the pool rather than minted, and with the cap active the pool loses
exactly 1,000,000. This is read from the code, not inferred from the field's
neighbours.

Runtime call targets, consistent across every use in the routine: 0x1768 add,
0x176e subtract, 0x177a multiply, 0x1780 divide, 0x178a compare,
0x178e long->real, 0x1792 real->long. The same table explains both
flag*0.05 + 0.02 and 1,000,000 / V.

On the predicate's identity — I over-read this earlier too. I suggested a
once-per-day gate was a natural fit. Against that: the same function is called
27 times across the overlay from unrelated contexts, including menu key
handling, and several call sites pass a byte from a local parameter rather than
the [0x28dc] global. That is the shape of a general per-empire guard, not an
event gate. [0x28dc] itself is read 104 times in the overlay and never written
there, consistent with it being the current empire index.

andy5995 believes the refund arrives only on the first play of the day. Nothing
here confirms or refutes that; if it holds, the gating lives in whatever calls
this routine. A cheap observation would narrow it: enter the game, note whether a
refund appears, back out, re-enter the same day, and see whether a second one
does.

What remains unknown: what feeds the pool, and what the predicate tests.

[andy5995]

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

The re-entry observation from my last comment has been made: andy5995 entered the
game a second time the same day and no second refund appeared.

Combined with the disassembly, that settles more than a bare observation would.
The routine contains no randomness — the only non-arithmetic call before the
output is the predicate, and that gates the cap rather than whether the refund
happens. So had the routine been invoked, it would have printed and paid again,
merely a smaller amount as the pool shrank. The pool had dropped by only
1,000,000 from at least 50,000,000, so it was still ample.

Therefore the routine was not called on the second entry, and the gating
lives in the caller rather than anywhere inside this code. The refund is not a
per-entry event.

Still not distinguished: whether the gate is per empire ("your first play of
the day") or planet-wide ("the first play of the day by anyone", so another
player entering first would consume it). The pool being planet-wide makes the
second worth ruling out rather than assuming. On a board with other active
players, a day where the refund does not appear on your first entry would point
at the planet-wide reading.

[andy5995]

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

Resolving the open question from my last comment: andy5995 reports from play that
the gate is per empire, not planet-wide — each realm gets its refund on its
own first play of the day, so another player entering first does not consume it.
This is his observation from running the game, not something I verified in the
binary.

The same once-per-day-per-empire gating applies to BRE's lottery ticket offer,
which does not reappear on a second entry either. The two sit ~400 bytes apart in
BRE.OVR and both fire in the "since your last play" block. So they are one
first-play-of-the-day event block, and IB would want a single hook they both
hang off rather than two independent random events.

Remaining unknowns are now just: what feeds the pool at [0x28b4]+0x24, and what
the [0x28dc] predicate tests (it gates only the 1,000,000 cap).