Jesse.Markowitz/station-master
1
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

Track placements must connect. #15

New Issue
Closed
opened 2026-08-25 15:56:03 +00:00 by Jesse.Markowitz · 2 comments
Jesse.Markowitz commented 2026-08-25 15:56:03 +00:00
Owner
Copy Link
Copy Source

Original thought was It is OK to place a track card that has an exit that doesn't connect on a side - if that side is a blank space. so putting a turnout on the running track with no card matching the turnout side is fine. BUT if a card is placed in that space, it MUST connect.

After further review, it's okay to place a card that does not connect. So in the game attached the system allowed playing a right hand curve at -1,1 . This should be legal to place even though that card does not connect to the turnout below nor the ice house above.

We need to confirm, however, that trains are not allowed to traverse from the turnout below to that right-hand curve since the tracks do not connect.

Original thought was It is OK to place a track card that has an exit that doesn't connect on a side - if that side is a blank space. so putting a turnout on the running track with no card matching the turnout side is fine. BUT if a card is placed in that space, it MUST connect. After further review, it's okay to place a card that does not connect. So in the game attached the system allowed playing a right hand curve at -1,1 . This should be legal to place even though that card does not connect to the turnout below nor the ice house above. We need to confirm, however, that trains are not allowed to traverse from the turnout below to that right-hand curve since the tracks do not connect.
PlayTest0.4.9g.station-master-seed612309983-day1.json
2.1 KiB
Jesse.Markowitz commented 2026-08-26 03:23:41 +00:00
Author
Owner
Copy Link
Copy Source

Verified w/RAR - this is acceptable. This could be used as a turnout / siding to park cars, even if it doesn't connect to adjacent tracks.

BUT we need to confirm that the switching algorithm doesn't allow moving to an adjacent card if the track doesn't match up.

Verified w/RAR - this is acceptable. This could be used as a turnout / siding to park cars, even if it doesn't connect to adjacent tracks. BUT we need to confirm that the switching algorithm doesn't allow moving to an adjacent card if the track doesn't match up.
Jesse.Markowitz commented 2026-08-26 19:23:45 +00:00
Author
Owner
Copy Link
Copy Source

Closed by v0.7.2 (2ab25e3) and v0.4.9h (e9683cc) — but not the way the issue was
originally filed, so worth stating plainly.

The placement is legal. Your review reversed the original "if a card is placed in that space, it
MUST connect": a rail may stop dead against its neighbour, and a stub like that has a use as a siding
to park cars on. A per-edge placement check had been written by then; it was taken out again, along
with a matching guard on checkTurnoutUpgrade. Both are documented in place as deliberately
absent, because this is exactly the rule someone will "fix" again in six months.

What you asked to confirm holds, and now cannot silently stop holding. exploreMoves gates every
hop on joins, which tests both ports AND that two 45° legs lie on the same diagonal — never a bare
pair of hasPort calls. That was already true and simply unpinned. The reported board is now a test:
the right-hand curve IS placeable, a train running west out of the Office and up the turnout's leg
CANNOT reach it, and — the part that makes the negative test mean anything — it IS reachable from the
east, where the warehouse actually joins. Without that third case the test would pass on a card that
was merely unreachable.

A Modifier is scenery, per your ruling: a rail pointing at a building is fine, and nothing guards
Modifier placement.

One note for future reports: the attached save can no longer be replayed. #14 took the deck from
206 cards to 121 in the same release, so its card ids no longer exist and the history stops at the
first card.play. Every save filed before that is in the same position. The geometry was what
mattered and it is rebuilt directly in the test.

Closed by **v0.7.2** (`2ab25e3`) and **v0.4.9h** (`e9683cc`) — but not the way the issue was originally filed, so worth stating plainly. **The placement is legal.** Your review reversed the original "if a card is placed in that space, it MUST connect": a rail may stop dead against its neighbour, and a stub like that has a use as a siding to park cars on. A per-edge placement check had been written by then; it was taken out again, along with a matching guard on `checkTurnoutUpgrade`. Both are documented in place as **deliberately absent**, because this is exactly the rule someone will "fix" again in six months. **What you asked to confirm holds, and now cannot silently stop holding.** `exploreMoves` gates every hop on `joins`, which tests both ports AND that two 45° legs lie on the same diagonal — never a bare pair of `hasPort` calls. That was already true and simply unpinned. The reported board is now a test: the right-hand curve IS placeable, a train running west out of the Office and up the turnout's leg CANNOT reach it, and — the part that makes the negative test mean anything — it IS reachable from the east, where the warehouse actually joins. Without that third case the test would pass on a card that was merely unreachable. A Modifier is scenery, per your ruling: a rail pointing at a building is fine, and nothing guards Modifier placement. One note for future reports: **the attached save can no longer be replayed.** #14 took the deck from 206 cards to 121 in the same release, so its card ids no longer exist and the history stops at the first `card.play`. Every save filed before that is in the same position. The geometry was what mattered and it is rebuilt directly in the test.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
Jesse.Markowitz
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Jesse.Markowitz/station-master#15