From: Bill R. <ro...@gm...> - 2011-09-30 08:58:10
|
Playing forward an 1856 game I am in, I have encountered a bug: when a railroad's home hex has multiple cities (THB in 1856), and there is already track in the hex before it operates for the first time, rails does not know how to lay the home token. This is only a problem if there is a choice: if one of the cities is tokened out, Rails correctly deduces that the home token is force into the other city. Erik has left a comment in layHomeBaseTokens() in PublicCompany that indicates this should be fixed in some clever way, but there seems to be a slightly newer comment in setPossibleActions() of OperatingRound with a work-around for this situation (when a company gets to the lay track step and doesn't yet have a home token, it is forced to lay one). Unfortunately, in at least the instance I encountered, this workaround doesn't seem to work. The problem is that the layBaseToken action that would force the company to lay the home token is created as a 'LOCATION_SPECIFIC' layToken and not a 'HOME_CITY' layToken. This causes the action not to be presented to the user, as regular (i.e. 'LOCATION_SPECIFIC') token lays are not allowed during the LayTile step of the operating round. I've attached a patch that fixes this: it's a matter of passing only one hex to the constructor of LayBaseToken, so that the resulting action has the right type. I've tried to handle the case where there are multiple home hexes, but I'm not sure that it will work, and I'm not sure what game I could test this with. It at least resolves the problem with 1856. I've also attached a savegame that demonstrates the problem: the THB can't act, which stops the game from continuing. Using the patched version of the code, Rails correctly asks the user which city the THB wants to lay a home station on. Bill |
From: Erik V. <eri...@xs...> - 2011-09-30 12:02:22
|
I have applied this fix. Thanks, Bill, for catching and fixing this problem. Later on, when time permits, I will run some other cases to check if all is still fine. This is a complex case that has already been updated several times now, so we need to be careful. I will also have another deep look at the code (and hopefully not spoil it again...). Erik. > -----Original Message----- > From: Bill Rosgen [mailto:ro...@gm...] > Sent: Friday, September 30, 2011 10:58 AM > To: Development list for Rails: an 18xx game > Subject: [Rails-devel] Bug (and patch): THB cannot lay home token with track > already in hex > > Playing forward an 1856 game I am in, I have encountered a bug: when a > railroad's home hex has multiple cities (THB in 1856), and there is already > track in the hex before it operates for the first time, rails does not know how > to lay the home token. This is only a problem if there is a choice: if one of the > cities is tokened out, Rails correctly deduces that the home token is force > into the other city. > > Erik has left a comment in layHomeBaseTokens() in PublicCompany that > indicates this should be fixed in some clever way, but there seems to be a > slightly newer comment in setPossibleActions() of OperatingRound with a > work-around for this situation (when a company gets to the lay track step > and doesn't yet have a home token, it is forced to lay one). > > Unfortunately, in at least the instance I encountered, this workaround > doesn't seem to work. The problem is that the layBaseToken action that > would force the company to lay the home token is created as a > 'LOCATION_SPECIFIC' layToken and not a 'HOME_CITY' layToken. This causes > the action not to be presented to the user, as regular (i.e. > 'LOCATION_SPECIFIC') token lays are not allowed during the LayTile step of > the operating round. > > I've attached a patch that fixes this: it's a matter of passing only one hex to > the constructor of LayBaseToken, so that the resulting action has the right > type. I've tried to handle the case where there are multiple home hexes, but > I'm not sure that it will work, and I'm not sure what game I could test this > with. It at least resolves the problem with 1856. > > I've also attached a savegame that demonstrates the problem: the THB can't > act, which stops the game from continuing. Using the patched version of the > code, Rails correctly asks the user which city the THB wants to lay a home > station on. > > Bill |
From: Stefan F. <ste...@we...> - 2011-09-30 20:58:53
|
I have added the save file to the suite of test cases and started a table for those bug fix test games in the wiki. Over time I will add some more test games of recent bug fixes. As soon as Erik give his go that the patch does not other side-effects, I will publish 1.5.1 with this fix. Stefan On Friday, September 30, 2011 02:02:15 pm Erik Vos wrote: > I have applied this fix. Thanks, Bill, for catching and fixing this > problem. > > Later on, when time permits, I will run some other cases to check if all is > still fine. This is a complex case that has already been updated several > times now, so we need to be careful. > I will also have another deep look at the code (and hopefully not spoil it > again...). > > Erik. > > > -----Original Message----- > > From: Bill Rosgen [mailto:ro...@gm...] > > Sent: Friday, September 30, 2011 10:58 AM > > To: Development list for Rails: an 18xx game > > Subject: [Rails-devel] Bug (and patch): THB cannot lay home token with > > track > > > already in hex > > > > Playing forward an 1856 game I am in, I have encountered a bug: when a > > railroad's home hex has multiple cities (THB in 1856), and there is > > already > > > track in the hex before it operates for the first time, rails does not > > know how > > > to lay the home token. This is only a problem if there is a choice: if > > one of the > > > cities is tokened out, Rails correctly deduces that the home token is > > force > > > into the other city. > > > > Erik has left a comment in layHomeBaseTokens() in PublicCompany that > > indicates this should be fixed in some clever way, but there seems to be > > a slightly newer comment in setPossibleActions() of OperatingRound with > > a work-around for this situation (when a company gets to the lay track > > step and doesn't yet have a home token, it is forced to lay one). > > > > Unfortunately, in at least the instance I encountered, this workaround > > doesn't seem to work. The problem is that the layBaseToken action that > > would force the company to lay the home token is created as a > > 'LOCATION_SPECIFIC' layToken and not a 'HOME_CITY' layToken. This causes > > the action not to be presented to the user, as regular (i.e. > > 'LOCATION_SPECIFIC') token lays are not allowed during the LayTile step > > of the operating round. > > > > I've attached a patch that fixes this: it's a matter of passing only one > > hex to > > > the constructor of LayBaseToken, so that the resulting action has the > > right > > > type. I've tried to handle the case where there are multiple home hexes, > > but > > > I'm not sure that it will work, and I'm not sure what game I could test > > this > > > with. It at least resolves the problem with 1856. > > > > I've also attached a savegame that demonstrates the problem: the THB > > can't act, which stops the game from continuing. Using the patched > > version of > > the > > > code, Rails correctly asks the user which city the THB wants to lay a > > home station on. > > > > Bill > > --------------------------------------------------------------------------- > --- All of the data generated in your IT infrastructure is seriously > valuable. Why? It contains a definitive record of application performance, > security threats, fraudulent activity, and more. Splunk takes this data > and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2dcopy2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Erik V. <eri...@xs...> - 2011-10-03 09:52:08
|
> -----Original Message----- > From: Stefan Frey [mailto:ste...@we...] > > As soon as Erik give his go that the patch does not other side-effects, I will > publish 1.5.1 with this fix. Yes, I'm fine with this patch. I have considered to decouple location multiplicity from action type in the LayBaseToken constructors, by adding a second 'type' argument, but I have finally decided to leave it as is, in order to maintain consistency with the superclass constructors. To clarify usage, I have added Javadoc comments to the three LayBaseToken constructors. Erik. |