From: Stefan F. <ste...@we...> - 2011-06-08 19:02:50
|
On the specific issue: I am responding as I am the one to blame for 1889: Indeed the method getSpecialTileLays in OperatingRound is the critical one. This was a caused by a recent change by Erik, as he cleaned up the Special Tile Lay code at several places in the codebase. As he was (most likely) not aware of the D property of being able to lay any tile, he assumed that a tile id would always be specified. I would add a check to your fix to capture this case and otherwise keep with the old flow, unless Erik has a better idea/other opinion? In general: There are two things we could improve to avoid such issues: A) Better documentation of the XML methods (for example which attributes are mandatory or optional and would an omission implies). B) This problem would have been captured in principle by my automated testing of existing game files. However it seems (to me) that those tests got a little sidetracked, since the time I got sidetracked by real world issues ;-) I will update the test settings and include more docs on them in the wiki (by collecting my information sent out to the mailing list). Stefan On Monday, June 06, 2011 10:28:29 am Bill Rosgen wrote: > In a game I am playing, we encountered a bug in 1.4.2 that is not in 1.4.1. > Specifically, there is a company with the D private, which allows free > tiles to be laid in the mountains (in rails XML, these tile lays are > free="yes" and extra="no"). The attached .rails file exhibits the > problem: Brad's TR does not get offered a free tile lay in F5. > > Tracking the problem down lead to the method getSpecialTileLays in > OperatingRound: when testing to see if special tile lays with extra="no" > are possible, this method checks to see if the tile specified in the > SpecialTileLay can be laid. Unfortunately in the 1889 Private D is not > restricted to a specific tile, so the action wasn't being added to the > list. The attached patch changes this to a different (and I think > equivalent?) method of testing if normal tile lays are still available -- > I check that the map tileLaysPerColour is not empty (as is done by the > method areTileLaysPossible when it tests if normal tile lays are > available). > > It is not clear to me that this is the best solution. Other solutions > might be: > > 1) Add three SpecialTileLays to Private D in 1889, one for each available > tile (7,8,9, in this case) 2) Change SpecialTileLay to keep a list of > available tiles, with corresponding changes to OperatingRound and LayTile > 3) If the tile in SpecialTileLay is null, treat this as no restriction: > get the lists of all available tiles in the restricted hexes and check to > see if any of them are valid, adding LayTile actions as appropriate. > > Bill Rosgen |