Commit Graph

9 Commits

Author SHA1 Message Date
f93252f69b give output-group eligibility one home
The rule that decides whether a group may be picked -- every item it yields
unlocked, the group judged whole because its items are produced together
(REQ-LOCK-OUTPUT-POOL) -- was written out inside rollOutputGroup, where nothing
outside the sim could reach it. It moves next to producesItem and
getProducibleItems in RecipesConfig.h, which is where the recipe-level queries
already shared between lib and ui live.

Deliberately narrow: the helper says whether a group is eligible, not whether
eligibility is asked about at all. rollOutputGroup keeps its own reason for not
asking when a recipe has a single group.

No behaviour change; the pool's end-to-end test still covers the rule and a
direct one now pins the judged-whole semantics.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-20 14:26:36 +02:00
9c275e283c give every recipe one shape: a list of output groups
Implements REQ-MAT-OUTPUT-GROUP. A recipe had two shapes -- outputs produced
together, or outputs of which exactly one happened -- and every rule over them
was written twice, selected by `building == ReprocessingPlant`: sizing a
buffer, deciding whether a cycle fits, resolving what a cycle makes, costing an
item. RecipeDef now holds output groups, each a weight and a list of items, and
a cycle yields exactly one group. One group is the ordinary recipe, so the old
two cases are the same shape with one and with several, and all four rules
collapse to one expression apiece with no building-type test left.

rollReprocessingOutput becomes rollOutputGroup, where a single group returns
without drawing or testing eligibility. That early-out is load-bearing twice
over. Drawing there would consume entropy for every ordinary recipe and shift
every later random outcome; and eligibility must not apply either, since
implicit unlocking is demand-derived, so an ordinary recipe's output can be
producible while nothing yet calls for it -- testing it would stop the building
producing rather than gate a drop. Past the early-out a group is eligible only
when all of its items are unlocked, being produced whole.

Threat follows the recipe's shape rather than the building, and the per-unit
value now divides by the group's amount as well as its odds. That moves no
number today: every item resolved through this path has amount 1, which is why
the threat expectations are untouched.

Config keeps `outputs = [...]` as the single-group form, so only the two
reprocessing recipes change shape. The recipe summary gains "/" between groups
and keeps "+" within one, which also fixes the plant reading as though a cycle
produced all of its items at once.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-17 12:47:09 +02:00
f255224ccd show recipes visually instead of describing them in text 2026-08-11 21:47:35 +02:00
553a7e0701 add findShipDef/findModuleDef/findRecipeDef to config structs and re-use them in the rest of the code base 2026-08-03 20:57:31 +02:00
f766ae4a86 Allow to draw produced-item icons in recipe dialog and game world 2026-07-23 20:54:04 +02:00
a9082c57f3 Implement config-driven unlock groups so that multiple things can be unlocked at once (including buildings) 2026-07-22 21:34:59 +02:00
6ea0655eaf implement unlock dependencies 2026-07-03 08:35:45 +02:00
1641189b75 explicit recipe unlocking 2026-06-12 17:15:06 +02:00
41fd2a83ee add basic types and fix cmake 2026-04-19 15:35:21 +02:00