mlangkabel/dota_factory
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

number the buildings from the factory that holds them

Browse Source 
The building-id counter was the last piece of factory data living on Simulation
behind a callback: every construction site, every building, and every tile a
station entity claims took its id from a std::function BuildingSystem held, which
the arena and three test fixtures each had to supply.

It moves into FactoryState as nextBuildingId, handed out by
allocateBuildingId(state) in FactoryQueries beside the other operations over the
state. BuildingSystem's callback is gone; so are Simulation::allocateBuildingId
and ArenaSimulation::allocateBuildingId, whose remaining callers now allocate
from the state directly.

Checksum order is untouched: Simulation folds the counter where it always did.

What is left on BuildingSystem is the config, the belts, the RNG, and two
callbacks that reach genuinely outside the factory -- spawning a finished ship
into the entity model, and testing an output group against the unlock state.
Neither is factory data, so this is where the migration stops.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
This commit is contained in:
Malte Langkabel
2026-08-19 17:31:48 +02:00
parent 780d5e5052
commit e7bfd91054
13 changed files with 43 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/architecture.md
View File

@@ -273,12 +273,12 @@ building could run and what its status light shows. A caller therefore depends o
it reads rather than on whichever system happens to tick it — which is what let the UI, the
balancing tool and the tests stop reaching through `BuildingSystem` for const answers.
What has not moved yet: the building-id counter and the global building block stock are
factory data that still live on `Simulation`, reached through callbacks
(`m_allocateBuildingId`, `m_addBuildingBlocks`) held by `BuildingSystem` and
`DeconstructionSystem`. `m_spawnShip` and `m_isItemUnlocked` are genuine cross-domain
reaches — into the entity model and the unlock state — and are not candidates for this
struct.
The struct also carries the two counters that used to live on `Simulation` and be reached
through callbacks: `nextBuildingId` (handed out by `allocateBuildingId`) and
`buildingBlocksStock`, which placement spends, deconstruction refunds, and HQ belt
deliveries add to. What remains on `BuildingSystem` is `m_spawnShip` and
`m_isItemUnlocked` — genuine cross-domain reaches into the entity model and the unlock
state, not factory data, and so not candidates for this struct.
## Debris