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

Rename Demolish to Deconstruct

Browse Source
This commit is contained in:
mlangkabel
2026-07-22 21:40:42 +02:00
parent b2ce20e6ad
commit e20a0bba67
30 changed files with 166 additions and 166 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/replay_design.md
View File

@@ -55,7 +55,7 @@ data, not the UI gesture. Example: placing a miner records
One command per sim-mutating operation (the complete mutation surface):
- `PlaceBuilding`
- `Demolish`
- `Deconstruct`
- `RotateInPlace`
- `SetRecipe`
- `SetShipLayout`
@@ -125,7 +125,7 @@ the only way production code can reach them is `apply(command)`.
> `BeltSystem` directly, and every production `buildings()`/`belts()` call is a const query.
> So:
>
> - `Simulation::tryPlaceBuilding`, `demolish`, and `applySchematicChoice` are **private**.
> - `Simulation::tryPlaceBuilding`, `deconstruct`, and `applySchematicChoice` are **private**.
> - The mutable subsystem accessors are private and renamed `buildingsMutable()` /
> `beltsMutable()`; only `const BuildingSystem& buildings() const` / `belts() const` are
> public (queries). UI query sites bind to the const overload unchanged.
@@ -377,7 +377,7 @@ The whole feature rests on a deterministic sim, so prove that before building on
Reshape mutations to flow through one path; behaviour unchanged.
- Defined `Command` base + derived types (`PlaceBuilding`, `Demolish`, `RotateInPlace`,
- Defined `Command` base + derived types (`PlaceBuilding`, `Deconstruct`, `RotateInPlace`,
`SetRecipe`, `SetShipLayout`, `SetSiteSplitterFilters`, `SetSplitterFilters`,
`ClearBeltTiles`, `ApplySchematicChoice`, `Reset`) in `lib`, each with a `playerId` (always 0
now). `PlaceBuilding` is atomic (carries optional config — see the refinement note above).