You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
**Note:** No explicit source generator tracks MakaMekTerrains enum. The `MovementCostTypeResolverGenerator` handles MovementCost subtypes, not terrain. Check if any partial method on Terrain needs update. No changes expected.
70
70
@@ -74,7 +74,7 @@ All follow the same pattern as `WaterTerrain`, `ClearTerrain`, etc.
74
74
75
75
---
76
76
77
-
## [T04] Add `ConstructionFactor` field to `TerrainData` record
77
+
## [#1038] Add `ConstructionFactor` field to `TerrainData` record
78
78
79
79
**File:**`src/MakaMek.Map/Data/TerrainData.cs`
80
80
@@ -92,7 +92,7 @@ All follow the same pattern as `WaterTerrain`, `ClearTerrain`, etc.
92
92
93
93
---
94
94
95
-
## [T05] Extend `Terrain.GetTerrainType()` and `FromData()` for new terrain types
95
+
## [#1039] Extend `Terrain.GetTerrainType()` and `FromData()` for new terrain types
@@ -111,14 +111,14 @@ All follow the same pattern as `WaterTerrain`, `ClearTerrain`, etc.
111
111
112
112
**Testable by:** Unit tests: create `TerrainData` for each new type, call `FromData()`, verify type and properties. Bridge roundtrip with Height and CF.
113
113
114
-
**Dependencies:**T01, T02, T04.
114
+
**Dependencies:**#1035, #1036, #1038.
115
115
116
116
**Open Questions:**
117
117
- Q2 (blocking): `GetTerrainType()` currently has signature `(MakaMekTerrains, int? height = null)`. Adding CF parameter is a breaking change to the public API. Option: Add optional param `int? constructionFactor = null`. This is the simplest approach but slightly ugly for non-Bridge terrains. Alternative: refactor to accept `TerrainData` directly.
118
118
119
119
---
120
120
121
-
## [T06] Add `SkidCheck` to `PilotingSkillRollType` enum
121
+
## [#1040] Add `SkidCheck` to `PilotingSkillRollType` enum
@@ -186,11 +186,11 @@ All follow the same pattern as `WaterTerrain`, `ClearTerrain`, etc.
186
186
187
187
**Testable by:** Unit tests: hex with Road → true, hex with Pavement → true, hex with Bridge → true, hex with Clear → false, hex with LightWoods → false.
188
188
189
-
**Dependencies:**T01, T02.
189
+
**Dependencies:**#1035, #1036.
190
190
191
191
---
192
192
193
-
## [T10] Add `Road` value to `TerrainAssetType` enum
193
+
## [#1044] Add `Road` value to `TerrainAssetType` enum
@@ -219,14 +219,14 @@ All follow the same pattern as `WaterTerrain`, `ClearTerrain`, etc.
219
219
220
220
**Testable by:** Unit tests with mock MMTX stream containing `terrains/road/000001.png`. Verify texture returned for known bitmask. Verify null for missing bitmask.
221
221
222
-
**Dependencies:**T10.
222
+
**Dependencies:**#1044.
223
223
224
224
**Open Questions:**
225
225
- Q3: Should Pavement hexes participate in road bitmask connectivity? The PRD says "Road and Bridge neighbors both count toward road connectivity" but doesn't mention Pavement. If Pavement is a broad area (not a strip), it likely should NOT create road connections. If the intent is otherwise, `ComputeCanonicalBitmask` would need to check multiple terrain types. **Recommendation:** For v1, only Road and Bridge count for bitmask connectivity. Pavement hexes use the isolated texture.
226
226
227
227
---
228
228
229
-
## [T12] Implement on-road cost substitution in `BattleMap.ConvertPathToSegments()`
229
+
## [#1046] Implement on-road cost substitution in `BattleMap.ConvertPathToSegments()`
230
230
231
231
**File:**`src/MakaMek.Map/Models/BattleMap.cs`
232
232
@@ -245,15 +245,15 @@ All follow the same pattern as `WaterTerrain`, `ClearTerrain`, etc.
245
245
- Unit test: fromHex is Clear, toHex is Road → cost = underlying terrain cost (not road bonus).
246
246
- Unit test: road+woods hex with elevation change → cost = 1 + |elevationChange|.
- Q4: When on-road with HeavyWoods underlying, the `TerrainMovementCost.TerrainId` is HeavyWoods but value is 1. Is this semantically OK? The PRD says yes: "Hex.MovementCost property itself is not changed." If the downstream consumers need to display the correct terrain name, this could be confusing. Consider whether `TerrainId` should be `Road` when on-road.
252
252
- Q5 (known limitation): Pathfinding (A*) doesn't know about road cost reduction. This means the shortest path may not utilize road benefits. It's acceptable for v1 but should be documented.
253
253
254
254
---
255
255
256
-
## [T13] Add road/bridge bitmask rendering to `HexControl`
256
+
## [#1047] Add road/bridge bitmask rendering to `HexControl`
@@ -379,11 +379,11 @@ All follow the same pattern as `WaterTerrain`, `ClearTerrain`, etc.
379
379
380
380
**Testable by:** Unit test: 20-ton Mech skids 4 hexes → standard falling damage per hex = 2, half = 1, total = 4 damage vs normal fall of 1 level = 2 damage.
-Q11:Whereexactlydoestheclearancecheckgo?Options: (a) inpathfinding's level-change validation, (b) in `ConvertPathToSegments`, (c) in `MovementPhase.ProcessMoveCommand()`. Best fit is probably in `MovementPhase` — when processing each non-road segment into a bridge hex, validate clearance before allowing the move.
|Q5|Pathfindingdoesn't use road cost reduction. Documented limitation. | T12|
534
-
|Q6|Howshouldskiddingmodifiersintegratewithto-hitcalculation — via `Mech.GetAttackModifiers()` or `ToHitCalculator.GetDetailedOtherModifiers()`?|T15, T22|
|Q5|Pathfindingdoesn't use road cost reduction. Documented limitation. | #1046|
534
+
|Q6|Howshouldskiddingmodifiersintegratewithto-hitcalculation — via `Mech.GetAttackModifiers()` or `ToHitCalculator.GetDetailedOtherModifiers()`?|#1049, #1056|
0 commit comments