search

Rails-18xx / Rails

Rails 18xx Java Application Main Repository
GNU General Public License v2.0
36 stars 22 forks source link

18Chesapeake hex F2 tile laying bug #435

Open svoboda77 opened 2 years ago

svoboda77 commented 2 years ago

Initial yellow tile (#57) on hex F2 for PRR home is only allowed in one rotation (connecting track to G1). It should also allow another rotation connecting to the existing track on hex E1.

svoboda77 commented 2 years ago

Multiple invalid rotations of green OO tiles are allowed by the app. H6 Baltimore allows connecting to H8 water, J4 Philadelphia allows green tile not connecting to any existing track.

Screenshot 2021-11-09 at 14 58 17
erik-vos commented 2 years ago

I can confirm the PRR home issue.

I did not test the Baltimore issue, but I suspect that the "water" hex is not seen as an off-board (preprinted) tile by the code, because it is not configured like that. I'll check what can be done here.

@neutronc, can you look into the rotation problem, or shall I pick it up too? I would like to finish 1837...

neutronc commented 2 years ago

I'll check 18 Chesapeake. But the northern OO Tile can be laid without connection to the south, of course not from a company coming from the southern hex.

svoboda77 commented 2 years ago

Since the original (preprinted) yellow tile has connections to both south and north, the upgrade tile should keep these connections. And yes, that green tile on the screenshot was laid by C&A. That's why I think it is a bug.

erik-vos commented 2 years ago

I have checked the water tile, but it has the correct specification colour="fixed", so that cannot be the cause. It's clearly another manifestation of an apparently widespread failure of finding correct rotations in 18Ches. I'll leave that to Martin for now.

erik-vos commented 2 years ago

I think I have found another case where a valid rotation is not allowed. It is in 1826 that I'm now working on. 1825-Rotation-problem The green tile 23 that I'm trying to lay on the hex NW of Paris is only allowed in this rotation, not in the equally valid 180° rotated one.

Muddling through the rotation code jungle, the root cause seems to be that the SE side of that hex is marked as "GREEDY".* Does that really mean that no token is present behind that side (i.e. in Paris NW)? Well, that token is there, and the train routing code finds it well enough, see the pink line.

Is there anyone around who can explain this?

Talking about greediness, there are four possible enum values for that field: SEEN, DONE, GREEDY and NOT_GREEDY. No documentation, of course. Can anyone explain the meaning of these values to me?

This all looks needlessly complicated. I'm thinking of replacing the code to find valid tile rotations by just a simple check: is there a token in any given direction, or not.

I don't know if the Chesapeake problem has the same cause, perhaps it is worth a check.

* See NetworkGraph.getReachableSides().126

EDIT: I have moved this 1826 issue to #478; it appears to be unrelated to the problems discussed here.