Menu
▾
▴
rails-devel
|
From: Erik V. <eri...@hc...> - 2008-11-29 20:15:46
|
I have (finally) done the main remaining unimplemented 1830 feature: selecting the Erie home base while upgrading to green. To trigger the selection I could have written code to detect the need for it, but for now I have chosen to add a special attribute in TileSet.xml for the preprinted (while/yellow) tile -20. During the upgrade, the same request will pop up as already occurs when laying a token on a multi-station tile. This new feature requires some extra non-transient attributes of LayTile. Normally such an extension makes existing saved files unreadable, as these contain serialized versions of LayTile objects. This time I have tried to achieve backwards compatibility by writing special deserialization code in this class. It seems to work nicely. (Although Erie did not appear in the bug list, I tend to consider it as such, if only for justifying submitting this change during the new features freeze we now have...). Erik |
|
From: Mark S. <mar...@gm...> - 2008-11-29 21:59:59
|
Stumbled on the bug I updated in City class when I was testing out placing a
Token in 1851 for L&N on the 2nd City of L&N Home Hex. The code allowed it
to happen, although the rules specifically state:
No more than one Station Marker of any Corporation may be placed in any hex.
Note, in 1851 it asks which city you want to place the token on BEFORE it
then responds with "Tile {X} already has a base token of company {Y}". When
it should really state this before it gives you a choice of cities.
Is there any 18xx Game that allows one company to place multiple
Tokens/Stations on the same Hex? If so, there will need some more updates to
accommodate.
Also still see the ability for a Token to be placed on a hex that has "no
tile" placed on it. Still the background color.
Mark
On Sat, Nov 29, 2008 at 3:15 PM, Erik Vos <eri...@hc...> wrote:
> I have (finally) done the main remaining unimplemented 1830 feature:
> selecting the Erie home base while upgrading to green. To trigger the
> selection I could have written code to detect the need for it, but for now
> I
> have chosen to add a special attribute in TileSet.xml for the preprinted
> (while/yellow) tile -20. During the upgrade, the same request will pop up
> as
> already occurs when laying a token on a multi-station tile.
>
> This new feature requires some extra non-transient attributes of LayTile.
> Normally such an extension makes existing saved files unreadable, as these
> contain serialized versions of LayTile objects. This time I have tried to
> achieve backwards compatibility by writing special deserialization code in
> this class. It seems to work nicely.
>
> (Although Erie did not appear in the bug list, I tend to consider it as
> such, if only for justifying submitting this change during the new features
> freeze we now have...).
>
> Erik
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
|
|
From: Erik V. <eri...@hc...> - 2008-11-29 22:42:04
|
Stumbled on the bug I updated in City class when I was testing out placing a
Token in 1851 for L&N on the 2nd City of L&N Home Hex. The code allowed it
to happen, although the rules specifically state:
No more than one Station Marker of any Corporation may be placed in any hex.
Note, in 1851 it asks which city you want to place the token on BEFORE it
then responds with "Tile {X} already has a base token of company {Y}". When
it should really state this before it gives you a choice of cities.
Sure. The goal is to gave the game engine select the hexes where tokens can
be laid and pass that list to the UI. But that requires route awareness,
which we don't yet have.
It would be possible now to pass a list of all hexes with open cities,
excluding ones that already have a token of the same company. So far I have
thought we could better wait with setting limitations until we can do it
right.
Is there any 18xx Game that allows one company to place multiple
Tokens/Stations on the same Hex? If so, there will need some more updates to
accommodate.
Yes, in 18EU separate stations (a.k.a. cities) on one hex may have tokens of
the same company (Paris, Berlin, Vienna). [BTW in this game it is pretty
clear that these slots do not represent separate cities but separate
stations in one city. One reason why I prefer the term "station" above
"city" for one or more connected token slots].
Also still see the ability for a Token to be placed on a hex that has "no
tile" placed on it. Still the background color.
In 1830 this should of course not be possible (except home tokens), but I
doubt if this applies to all games. Some games have off-board (red) hexes
with token slots. Many games have preprinted yellow, green or grey hexes
with tokenable cities. In 1841 you can select any open token slot as a home
base for a new (non-historic) company, even if it is an unconnected city on
background colour. Too many exceptions IMHO.
The problems you mention will disappear once we have routes. As long as we
don't have route awareness players have to be honest in tile and token
placement anyway. I'm not too much in favour of partial fixes unless these
are generic and really simple.
Erik.
Mark
On Sat, Nov 29, 2008 at 3:15 PM, Erik Vos <eri...@hc...> wrote:
I have (finally) done the main remaining unimplemented 1830 feature:
selecting the Erie home base while upgrading to green. To trigger the
selection I could have written code to detect the need for it, but for now I
have chosen to add a special attribute in TileSet.xml for the preprinted
(while/yellow) tile -20. During the upgrade, the same request will pop up as
already occurs when laying a token on a multi-station tile.
This new feature requires some extra non-transient attributes of LayTile.
Normally such an extension makes existing saved files unreadable, as these
contain serialized versions of LayTile objects. This time I have tried to
achieve backwards compatibility by writing special deserialization code in
this class. It seems to work nicely.
(Although Erie did not appear in the bug list, I tend to consider it as
such, if only for justifying submitting this change during the new features
freeze we now have...).
Erik
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100
<http://moblin-contest.org/redirect.php?banner_id=100&url=/> &url=/
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: John D. G. <jd...@di...> - 2008-11-29 22:50:49
|
Mark Smith wrote: > Is there any 18xx Game that allows one company to place multiple > Tokens/Stations on the same Hex? If so, there will need some more > updates to accommodate. In 1837 this situation can exist in Vienna or Budapest as a result of minor companies merging into the national railroads. When each of those cities is upgraded to brown, the separate stations with duplicate tokens merge into one station and only one token is retained. > Also still see the ability for a Token to be placed on a hex that has > "no tile" placed on it. Still the background color. This relates to Eric's "bug fix" at the start of this thread. I believe that when it's time to place a company's home token on the board (at the start of its first operating turn in most games, but in the stock round in 1835), the token is placed immediately even if there is no tile and no track in the hex. In the case of the Erie or Badische, if there is no tile, then there is no need to ask the company owner where the token goes, since the two unconnected station circles in that hex are indistinguishable. But when one of those hexes -- or any OO, XX, or similar hex that already has at least one token -- gets a tile laid on it, THEN whoever lays the tile (NOT necessarily the company owner!) should be prompted to choose which station gets which token. I have always played that if these companies have no home tile and don't bother to lay it on their first turn, they give up their right to make this choice. |
|
From: Mark S. <mar...@gm...> - 2008-11-30 00:13:25
|
Erik, With the way the routine I updated was written it was ALWAYS going to return FALSE. The contains would never find the 'PublicCompanyI' in the ArrayList<TokenI>. I did see and understand the bit about making a list of "Available Hexes where a Station could be placed" that requires route awareness. Given the 18EU, and 1841 variations on this, yes, what you explain makes sense. With regards to 1837, I do actually have a copy, but never actually played it with a group. And yes, the separate stations from the minors that upgrade to the major, and merge to a single token when the city is upgraded makes sense. From a programming standpoint, however when the minor is upgraded to the major, the token type is changed, but it is not a user selected action which is what I was attempting to resolve. So the routine I fixed would not be called when that token change is made. As John David Galt pointed out Badishce Eisenbahn in 1835, and THB in 1856 have the same issue as Eire in 1830. Mark |
|
From: Mark S. <mar...@gm...> - 2008-11-30 00:17:58
|
Another note about 1856, per the official map, the Credit Valley (CV) starts in the South Western City of Toronto ALWAYS. However as the map is drawn implies it could start in either location. Mark On Sat, Nov 29, 2008 at 7:13 PM, Mark Smith <mar...@gm...> wrote: > Erik, > > With the way the routine I updated was written it was ALWAYS going to > return FALSE. The contains would never find the 'PublicCompanyI' in the > ArrayList<TokenI>. > > I did see and understand the bit about making a list of "Available Hexes > where a Station could be placed" that requires route awareness. > > Given the 18EU, and 1841 variations on this, yes, what you explain makes > sense. > > With regards to 1837, I do actually have a copy, but never actually played > it with a group. And yes, the separate stations from the minors that upgrade > to the major, and merge to a single token when the city is upgraded makes > sense. From a programming standpoint, however when the minor is upgraded to > the major, the token type is changed, but it is not a user selected action > which is what I was attempting to resolve. So the routine I fixed would not > be called when that token change is made. > > As John David Galt pointed out Badishce Eisenbahn in 1835, and THB in 1856 > have the same issue as Eire in 1830. > > Mark > > > |
|
From: Erik V. <eri...@hc...> - 2008-11-30 14:52:32
|
With the way the routine I updated was written it was ALWAYS going to return FALSE. The contains would never find the 'PublicCompanyI' in the ArrayList<TokenI>. Yes, I should have been more careful when writing that code. Good fix (I had accepted it without any comments - perhaps you had expected some). Erik |
|
From: Mark S. <mar...@gm...> - 2008-11-30 16:11:01
|
You mis-understood... or I mis-understood. I was not really seeking "compliments". With your initial response about limiting hexes to those that are legal with track awareness that was not yet ready, I thought you had not understood why I fixed the code. Part of the reason to code this stuff, as I am sure you agree, is to prevent "honest" mistakes... or even "dis-honest" play by a person. The fix I applied at least prevents the illegal token lay from being performed, even if from a UI standpoint it does the test later than it should. And that reminds me of the other point I failed to mention. WIth 1851, the L&N Home, when I attempted to place the token on the tile, (whether for L&N or another Company), because there were two seperate cities, it asked which did I want to place it on, even though only one (the south western one) had an empty slot. If there is only one empty slot on the tile, the dialog is not necessary. I have updated the ORUIManager.java routine in two places where the SelectStationForToken Text is retrieved to check that more than one item will be displayed. If only one, the dialog is not required, and it will auto-select the first one. Mark On Sun, Nov 30, 2008 at 9:52 AM, Erik Vos <eri...@hc...> wrote: > With the way the routine I updated was written it was ALWAYS going to > return FALSE. The contains would never find the 'PublicCompanyI' in the > ArrayList<TokenI>. > > Yes, I should have been more careful when writing that code. > Good fix (I had accepted it without any comments - perhaps you had expected > some). > > Erik > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Erik V. <eri...@hc...> - 2008-11-30 19:55:07
|
You mis-understood... or I mis-understood. I was not really seeking "compliments". With your initial response about limiting hexes to those that are legal with track awareness that was not yet ready, I thought you had not understood why I fixed the code. I did, but I should have expressed myself more clearly. Part of the reason to code this stuff, as I am sure you agree, is to prevent "honest" mistakes... or even "dis-honest" play by a person. The fix I applied at least prevents the illegal token lay from being performed, even if from a UI standpoint it does the test later than it should. And that reminds me of the other point I failed to mention. WIth 1851, the L&N Home, when I attempted to place the token on the tile, (whether for L&N or another Company), because there were two seperate cities, it asked which did I want to place it on, even though only one (the south western one) had an empty slot. If there is only one empty slot on the tile, the dialog is not necessary. I have updated the ORUIManager.java routine in two places where the SelectStationForToken Text is retrieved to check that more than one item will be displayed. If only one, the dialog is not required, and it will auto-select the first one. OK, thanks. Erik. |
|
From: Erik V. <eri...@hc...> - 2008-11-30 14:46:32
|
> I believe that when it's time to place a company's home token on the > board (at the start of its first operating turn in most games, but in > the stock round in 1835), the token is placed immediately > even if there > is no tile and no track in the hex. In the case of the Erie > or Badische, > if there is no tile, then there is no need to ask the company > owner where > the token goes, since the two unconnected station circles in > that hex are > indistinguishable. Exactly, and the rules of both 1830 and 1835 completely fail to understand that, when these state that "a home token once played cannot be moved". > But when one of those hexes -- or any OO, XX, or similar hex that > already has at least one token -- gets a tile laid on it, THEN whoever > lays the tile (NOT necessarily the company owner!) should be > prompted to > choose which station gets which token. That is how I have implemented it, but I'm having second thoughts about that. In fact I had intended to let the president make the choice, but I overlooked the possibility that another player might update such a OO or XX hex to green. This is rather unlikely, though, so perhaps I'll leave it as is. The rules are completely silent about this question. > I have always played that if these companies have no home > tile and don't > bother to lay it on their first turn, they give up their right to make > this choice. I would rule differently, but I don't know if there is any basis to settle this dispute. Has there ever be a ruling on this matter? Erik. |
|
From: John D. G. <jd...@di...> - 2008-11-30 18:13:30
|
> John David Galt wrote: >> But when one of those hexes -- or any OO, XX, or similar hex that >> already has at least one token -- gets a tile laid on it, THEN whoever >> lays the tile (NOT necessarily the company owner!) should be >> prompted to >> choose which station gets which token. Erik Vos wrote: > That is how I have implemented it, but I'm having second thoughts about > that. In fact I had intended to let the president make the choice, but > I overlooked the possibility that another player might update such a OO > or XX hex to green. This is rather unlikely, though, so perhaps I'll > leave it as is. The rules are completely silent about this question. >> I have always played that if these companies have no home tile and >> don't bother to lay it on their first turn, they give up their right >> to make this choice. > I would rule differently, but I don't know if there is any basis to > settle this dispute. Has there ever be a ruling on this matter? Not that I'm aware of. It was debated a year ago on the 18xx list. The main case where it would come up is when someone opens the Erie or THB just before the permanent trains come out, as a source of capital, and doesn't want it to have to buy a train, so he doesn't build it a route. The other nearby players will want to thwart this tactic by building a route for that company. If (say) the NYC lays Erie's home OO tile after Erie has had two turns, it seems to me it's against the spirit of the game to then allow Erie to say, "my home station is the one your track doesn't connect to." Erie had its chance and passed it. |
|
From: Erik V. <eri...@hc...> - 2008-11-30 20:20:47
|
> Erik Vos wrote: > > That is how I have implemented it, but I'm having second > thoughts about > > that. In fact I had intended to let the president make the > choice, but > > I overlooked the possibility that another player might > update such a OO > > or XX hex to green. This is rather unlikely, though, so perhaps I'll > > leave it as is. The rules are completely silent about this question. > > >> I have always played that if these companies have no home tile and > >> don't bother to lay it on their first turn, they give up > their right > >> to make this choice. > > > I would rule differently, but I don't know if there is any basis to > > settle this dispute. Has there ever be a ruling on this matter? > > Not that I'm aware of. It was debated a year ago on the 18xx list. Found, that was in Feb 2007. > The main case where it would come up is when someone opens the Erie or > THB just before the permanent trains come out, as a source of capital, > and doesn't want it to have to buy a train, so he doesn't build it a > route. The other nearby players will want to thwart this tactic by > building a route for that company. If (say) the NYC lays Erie's home > OO tile after Erie has had two turns, it seems to me it's against the > spirit of the game to then allow Erie to say, "my home station is the > one your track doesn't connect to." Erie had its chance and > passed it. That makes some sense too. In the discussion you refer to, both Wolfram Janich and Steve Thomas concluded that in 1835 the Badische president had the right to place its token (first) when someone else upgraded the tile to green. Steve cited version 1 of the English rules as saying "The home base token of the Baden may be placed in either of the cities found on its home hex after the green tile has been played. No other corporation may play a token on this hex (including through the use of the Pfalzbahnen) until the Baden has placed its home token." The mentioning of "green" seems to settle the issue (at least for 1835), but in my version 2 of these rules the reference to green is missing, putting us back in uncertainty. As said before, I'm not going to change anything now. But I don't consider the issue settled. Erik. |
|
From: John D. G. <jd...@di...> - 2008-12-03 23:10:36
|
>>> John David Galt wrote: >>>> But when one of those hexes -- or any OO, XX, or similar hex that >>>> already has at least one token -- gets a tile laid on it, THEN >>>> whoever lays the tile (NOT necessarily the company owner!) should >>>> be prompted to choose which station gets which token. >> Erik Vos wrote: >>> That is how I have implemented it, but I'm having second thoughts >>> about that. In fact I had intended to let the president make the >>> choice, but I overlooked the possibility that another player might >>> update such a OO or XX hex to green. This is rather unlikely, >>> though, so perhaps I'll leave it as is. The rules are completely >>> silent about this question. I agree, for all three games. >>>> I have always played that if these companies have no home tile >>>> and don't bother to lay it on their first turn, they give up their >>>> right to make this choice. >>> I would rule differently, but I don't know if there is any basis to >>> settle this dispute. Has there ever be a ruling on this matter? > John David Galt wrote: >> Not that I'm aware of. It was debated a year ago on the 18xx list. Erik Vos wrote: > Found, that was in Feb 2007. >> The main case where it would come up is when someone opens the Erie >> or THB just before the permanent trains come out, as a source of >> capital, and doesn't want it to have to buy a train, so he doesn't >> build it a route. The other nearby players will want to thwart this >> tactic by building a route for that company. If (say) the NYC lays >> Erie's home OO tile after Erie has had two turns, it seems to me >> it's against the spirit of the game to then allow Erie to say, "my >> home station is the one your track doesn't connect to." Erie had >> its chance and passed it. > That makes some sense too. I should explain this a little better: I'm reasoning from the general rule (in all 18xx games, I believe) that if you upgrade a tile where token(s) are already present, and there is a choice of which city is which, the person making the upgrade chooses. I believe that in all games except 1835, each company's home token is automatically (and involuntarily) placed in a city circle on its home hex -- even if the hex has no tile and the city has no track connected to it. If this is true, then the general rule applies when the tile is laid afterward, no matter who does it. This, in my view, answers the question for Erie and THB. In 1835, most companies' home tokens are placed immediately upon flotation, during the stock round. But version 1 of the English rules made BA an explicit exception to that timing, saying that its home token is not placed until someone lays a green tile on Ludwigshafen/ Mannheim. If that is true, then BA's owner will always have his choice of those two green cities. But as you say, that exception does not seem to be stated in version 2. Was that deletion an intentional change, or just carelessness? Reasonable people will differ. But if it was an intentional change, then the general rule applies, just as it does to Erie and THB. > As said before, I'm not going to change anything now. But I don't > consider the issue settled. Me neither. Perhaps the best answer is to make it a setting that a GM can change (such as an option in the game definition .xml file). |
|
From: John D. G. <jd...@di...> - 2008-12-03 23:19:24
|
Typo corrected. >>> John David Galt wrote: >>>> But when one of those hexes -- or any OO, XX, or similar hex that >>>> already has at least one token -- gets a tile laid on it, THEN >>>> whoever lays the tile (NOT necessarily the company owner!) should >>>> be prompted to choose which station gets which token. >> Erik Vos wrote: >>> That is how I have implemented it, but I'm having second thoughts >>> about that. In fact I had intended to let the president make the >>> choice, but I overlooked the possibility that another player might >>> update such a OO or XX hex to green. This is rather unlikely, >>> though, so perhaps I'll leave it as is. The rules are completely >>> silent about this question. I agree, for all three games. >>>> I have always played that if these companies have no home tile >>>> and don't bother to lay it on their first turn, they give up their >>>> right to make this choice. >>> I would rule differently, but I don't know if there is any basis to >>> settle this dispute. Has there ever be a ruling on this matter? > John David Galt wrote: >> Not that I'm aware of. It was debated a year ago on the 18xx list. Erik Vos wrote: > Found, that was in Feb 2007. >> The main case where it would come up is when someone opens the Erie >> or THB just before the permanent trains come out, as a source of >> capital, and doesn't want it to have to buy a train, so he doesn't >> build it a route. The other nearby players will want to thwart this >> tactic by building a route for that company. If (say) the NYC lays >> Erie's home OO tile after Erie has had two turns, it seems to me >> it's against the spirit of the game to then allow Erie to say, "my >> home station is the one your track doesn't connect to." Erie had >> its chance and passed it. > That makes some sense too. I should explain this a little better: I'm reasoning from the general rule (in all 18xx games, I believe) that if you upgrade a tile where token(s) are already present, and there is a choice of which city is which, the person making the upgrade chooses. I believe that in all games except 1835, at the start of each company's first operating turn, its home token is automatically (and involuntarily) placed in a city circle on its home hex -- even if the hex has no tile and the city has no track connected to it. If this is true, then the general rule applies when the tile is laid afterward, no matter who does it. This, in my view, answers the question for Erie and THB. In 1835, most companies' home tokens are placed immediately upon flotation, during the stock round. But version 1 of the English rules made BA an explicit exception to that timing, saying that its home token is not placed until someone lays a green tile on Ludwigshafen/ Mannheim. If that is true, then BA's owner will always have his choice of those two green cities. But as you say, that exception does not seem to be stated in version 2. Was that deletion an intentional change, or just carelessness? Reasonable people will differ. But if it was an intentional change, then the general rule applies, just as it does to Erie and THB. > As said before, I'm not going to change anything now. But I don't > consider the issue settled. Me neither. Perhaps the best answer is to make it a setting that a GM can change (such as an option in the game definition .xml file). |
|
From: Erik V. <eri...@hc...> - 2008-11-30 14:36:36
|
Another note about 1856, per the official map, the Credit Valley (CV) starts in the South Western City of Toronto ALWAYS. However as the map is drawn implies it could start in either location. I guess we could print the starting company name in small print in the appropriate token slot. Another TODO. |
|
From: Mark S. <mar...@gm...> - 2008-11-30 14:48:31
|
If I do get finished with integrating my code (which I don't want to check in until after the next release), that will be part of the normal map display. As well as showing destinations. On Sun, Nov 30, 2008 at 9:36 AM, Erik Vos <eri...@hc...> wrote: > > Another note about 1856, per the official map, the Credit Valley (CV) > starts in the South Western City of Toronto ALWAYS. However as the map is > drawn implies it could start in either location. > > I guess we could print the starting company name in small print in the > appropriate token slot. Another TODO. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X