rails-devel — List for discussion of Rails development

Re: [Rails-devel] Another Bug I have found, and worked out a fix for

[Mark S. <mar...@gm...>]

Yes, the simple fix is as you state. However, the purpose for sub-classing
is to use the super-class constructor routines to initialize stuff at that
superclass level, and use the sub-class constructors to call the super class
constructor, and then initialize what the sub-class needs. Without doing
proper constructors, at all levels, you wind up forgetting to initialize
something (as in this case). It may introduce some extra code in some
places, but it reduces errors like this one.

Am I not being clear?

I hate messy code, and would much prefer to follow at least a
pseudo-standard.

I was using "required" and "needed" because when I tried to create just the
super-class constructor, the compiler complained the sub-class did not have
the appropriate constructor. So I created those, and cleaned up stuff as I
saw it needed to be cleaned up.



On Tue, Dec 2, 2008 at 3:13 PM, Erik Vos <eri...@hc...> wrote:

>  I have adjusted my copies of the various classes to resolve this Null
> Pointer Exception, by creating constructors for the Round, StockRound,
> OperatingRound and the sub-classes of StockRound. It does require
> modifications of all of these for the constructors. A total of 8 classes to
> update. (the sub-classes of OperatingRound does not require an update. But
> probably should have constructors created for consistancy's sake.
>
> The simple fix would have been to add
>
> *    this*.companyManager = gameManager.getCompanyManager();
>
> to the ShareSellingRound constructor. That works for me to fix the problem
> (which I have reproduced). Not sure what you are trying to achieve by adding
> all these constructors.
>
> As for the second suggestion, I have indeed implemented the constructors
> such that the super-classes do all the initialization that should, and the
> sub-classes do the initialization they should. In a couple of places I
> needed to create a constructor that simply called the super class
> constructor and nothing more.
>
> I wonder why you are using worls like "required" and "needed": such default
> constructors can be omitted.
>
> I have noticed that XCode does warn about several classes marked as
> deprecated (in your comments) that are still being used. But the deprecation
> comment does not specify what should be used instead. Those might be a
> better item to clean up then simply adding JAVA Docs.
>
> Good point. Thanks.
>
> 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
>
>

[Rails-devel] Cleanups

[Erik V. <eri...@hc...>]

I have noticed that XCode does warn about several classes marked as
deprecated (in your comments) that are still being used. But the deprecation
comment does not specify what should be used instead. Those might be a
better item to clean up then simply adding JAVA Docs.

 
I have cleaned up most of those, but also left in one that is only used in
the external tile XML conversion utilities. Too lazy now to rework that
code.
And cleaned up more code based on the compiler warnings. The remaining
warnings are inevitable, or refer to variables for future use or to the
remaining deprecated method. 
 
Erik.

Re: [Rails-devel] Another Bug I have found, and worked out a fix for

[Erik V. <eri...@hc...>]

I have adjusted my copies of the various classes to resolve this Null
Pointer Exception, by creating constructors for the Round, StockRound,
OperatingRound and the sub-classes of StockRound. It does require
modifications of all of these for the constructors. A total of 8 classes to
update. (the sub-classes of OperatingRound does not require an update. But
probably should have constructors created for consistancy's sake.

The simple fix would have been to add
    this.companyManager = gameManager.getCompanyManager();

to the ShareSellingRound constructor. That works for me to fix the problem
(which I have reproduced). Not sure what you are trying to achieve by adding
all these constructors.

As for the second suggestion, I have indeed implemented the constructors
such that the super-classes do all the initialization that should, and the
sub-classes do the initialization they should. In a couple of places I
needed to create a constructor that simply called the super class
constructor and nothing more.  

I wonder why you are using worls like "required" and "needed": such default
constructors can be omitted.

I have noticed that XCode does warn about several classes marked as
deprecated (in your comments) that are still being used. But the deprecation
comment does not specify what should be used instead. Those might be a
better item to clean up then simply adding JAVA Docs.

Good point. Thanks.
 
Erik.

Re: [Rails-devel] Another Bug I have found, and worked out a fix for

[Mark S. <mar...@gm...>]

My first Suggestion was based upon as you guessed the "Game Specific"
structure you have in place. I have not changed my copy to reflect that.
This was purely a suggestion.

As for the second suggestion, I have indeed implemented the constructors
such that the super-classes do all the initialization that should, and the
sub-classes do the initialization they should. In a couple of places I
needed to create a constructor that simply called the super class
constructor and nothing more.

I will apply the JAVA Docs to the constructors I have created, and check
them in this evening.

I have noticed that XCode does warn about several classes marked as
deprecated (in your comments) that are still being used. But the deprecation
comment does not specify what should be used instead. Those might be a
better item to clean up then simply adding JAVA Docs.

Mark

Re: [Rails-devel] Another Bug I have found, and worked out a fix for

[<eri...@hc...>]

>
> Issues that I see:
> 1. The StartRound_1830.java and StartRound_1835.java should be placed
> under the specific/_1830 and specific/_1835 sub-folders along with the
> other special case classes

Yes and no.
These classes pre-date the introduction of the game.specific package, and
are in fact not really game-specific. The 1830-style auction occurs in
many games, and I believe the 1835-style auction is also used in 1837.
At the time these classes were created I had a brief discussion with Brett
about the naming of such classes, but we couldn't find good generic names
for the different auction types. Perhaps StartRound1830Style would have
been better.

I have no real objection against moving these classes to game.specific,
but the above should be kept in mind.

> 2. The Round, StockRound, OperatingRound, and
> the respective subclasses do not have constructors for no elements, or for
> theStockRound (and sub-classes) an cosntructor with the GameManager  Round
> superclass should have (but doesn't).  The Round superclass does have a
> method 'setGameManager' which assigns gameManager and companyManager.
>
>
> I have adjusted my copies of the various classes to resolve this Null
> Pointer Exception, by creating constructors for the Round, StockRound,
> OperatingRound and the sub-classes of StockRound. It does require
> modifications of all of these for the constructors. A total of 8 classes
> to update. (the sub-classes of OperatingRound does not require an update.
> But
> probably should have constructors created for consistancy's sake.

I don't have the current code handy here at work (just an old version),
but I would think that a Round constructor should do all the common tasks,
and the next lower level (StockRound etc.) any additional tasks specific
to the type of round. So I'm not sure why all these classes need explicit
constructors. But I'll have a look tonight. I'm probably missing some
point.

I know that the whole initialization stuff is somewhat messy, so I am not
at all surprised that you are finding inconsistencies.

> Since I am creating new methods, should I also add in the JavaDocs for
> them as well?

Yes, of course that would be a good thing to do. I know I'm sloppy in
creating Javadocs, perhaps I can spend some time on that before the
upcoming release, if we're running out of bugs.

Erik.

[Rails-devel] Another Bug I have found, and worked out a fix for

[Mark S. <mar...@gm...>]

I found a reasonable quick way in 1830 to force a player to buy a train out
of hand (3 player game, start B&O, PRR, and a 3rd Railroad all $67 per
share. B&O buys four (4) two trains (yes stupid plan, but this is to test
the code), PRR buy four trains, the 3rd Railroad buy the last three trains.
Next Stock Round start company #4 at $67 per share, and then in the next OR,
have that company buy a 4 train - killing the twos before B&O can operate.
Now when B&O operates, no trains, and < $300 in company and hand together
(B&O also needs to build $160 (two tiles), and buy a Token.

Then... we get to a ShareSellingRound launching.

And it goes BOOM!  --- Null Pointer Exception right at the start of
setSellableShares for loop, because companyManager is not set in the
constructor.

Digging into this class structure if find the following:

+ -- Round
      |
      +-- StockRound extends Round
      |    |
      |    +-- ShareSellingRound extends StockRound
      |    |
      |    +-- TreasuryShareRound extends StockRound
      |    |
      |    +-- StockRound_1856 extends StockRound
      |    |
      |    +-- StockRound_1835 extends StockRound
      |    |
      |    +-- StockRound_18EU extends StockRound
      |
      +-- OperatingRound extends Round
      |    |
      |    +-- OperatingRound_1856 extends OperatingRound
      |    |
      |    +-- OperatingRound_18EU extends OperatingRound
      |    |
      |    +-- OperatingRound_18AL extends OperatingRound
      |
      +-- StartRound extends OperatingRound
           |
           +-- StartRound_1830 extends StartRound
           |
           +-- StartRound_1835 extends StartRound
           |
           +-- StartRound_1851 extends StartRound
           |
           +-- StartRound_18EU extends StartRound

Issues that I see:
1. The StartRound_1830.java and StartRound_1835.java should be placed under
the specific/_1830 and specific/_1835 sub-folders along with the other
special case classes
2. The Round, StockRound, OperatingRound, and the respective subclasses do
not have constructors for no elements, or for theStockRound (and
sub-classes) an cosntructor with the GameManager  Round superclass should
have (but doesn't).  The Round superclass does have a method
'setGameManager' which assigns gameManager and companyManager.

I have adjusted my copies of the various classes to resolve this Null
Pointer Exception, by creating constructors for the Round, StockRound,
OperatingRound and the sub-classes of StockRound. It does require
modifications of all of these for the constructors. A total of 8 classes to
update. (the sub-classes of OperatingRound does not require an update. But
probably should have constructors created for consistancy's sake.

Since I am creating new methods, should I also add in the JavaDocs for them
as well?

Mark

[Rails-devel] ORWindow now remembers height

[Erik V. <eri...@hc...>]

I have made ORWindow remember its height between rounds. It was rather
annoying that it resized itself to maximum height each time. 
This problem was reported in the Bugs list. I don't think that the other
windows present such problems, so I have set the bug status to pending.

Erik 

Re: [Rails-devel] Setting Erie home base during green upgrade

[Erik V. <eri...@hc...>]

> 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.

Re: [Rails-devel] Settong Erie home base during green upgrade

[Erik V. <eri...@hc...>]

 

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.
 

Re: [Rails-devel] Settong Erie home base during green upgrade

[John D. G. <jd...@di...>]

> 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.

Re: [Rails-devel] Settong Erie home base during green upgrade

[Mark S. <mar...@gm...>]

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
>
>

Re: [Rails-devel] Settong Erie home base during green upgrade

[Erik V. <eri...@hc...>]

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

Re: [Rails-devel] Settong Erie home base during green upgrade

[Mark S. <mar...@gm...>]

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
>
>

Re: [Rails-devel] Settong Erie home base during green upgrade

[Erik V. <eri...@hc...>]

> 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.

Re: [Rails-devel] Settong Erie home base during green upgrade

[Erik V. <eri...@hc...>]

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.

Re: [Rails-devel] Settong Erie home base during green upgrade

[Mark S. <mar...@gm...>]

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
>
>
>

Re: [Rails-devel] Settong Erie home base during green upgrade

[Mark S. <mar...@gm...>]

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

Re: [Rails-devel] Settong Erie home base during green upgrade

[John D. G. <jd...@di...>]

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.

Re: [Rails-devel] Settong Erie home base during green upgrade

[Erik V. <eri...@hc...>]

 

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

Re: [Rails-devel] Settong Erie home base during green upgrade

[Mark S. <mar...@gm...>]

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
>

[Rails-devel] Settong Erie home base during green upgrade

[Erik V. <eri...@hc...>]

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 

Re: [Rails-devel] OK, Poking around a bit more

[Mark S. <mar...@gm...>]

I will put the Suggestions into the Feature Request Section. I want to
see if I can actually resolve the item I termed a Bug. If I can't get
it over the weekend, I will add it as a Bug on Sunday.

On Fri, Nov 28, 2008 at 3:06 PM, Erik Vos <eri...@hc...> wrote:
> Good suggestions.
>
> However, unless any of these ideas turns out to be easy to implement,
> chances are that I will not get that very soon. In fiddling with the UI I
> tend to be satisfied if things work (rather than look perfect). My focus is
> on other aspects.
>
> It might be a good idea to put such ideas in the bugs or feature requests
> lists.
>
> Erik.
>
>> -----Original Message-----
>> From: Mark Smith [mailto:mar...@gm...]
>> Sent: Friday 28 November 2008 17:13
>> To: Rails Dev Mailing List
>> Subject: Re: [Rails-devel] OK, Poking around a bit more
>>
>> Grr... hit send to soon
>>
>> On Fri, Nov 28, 2008 at 11:05 AM, Mark Smith
>> <mar...@gm...> wrote:
>> > I have come across another Bug, and some suggestions:
>> >
>> > BUG -- When laying a Tile, you select a Hex, and it shows the
>> > Allowable Upgrades. Select an Upgrade Tile, then select a DIFFERENT
>> > Upgrade Tile for the same hex. The list of available Upgrade Tiles
>> > goes blank. If you select a Different Hex, and then re-select the
>> > original Hex the Upgrades re-appear.
>> >
>> > Suggestions:
>> >
>> > 1. If you select a Hex that you cannot lay a tile on, and try to
>> > select a tile to place, the Pop-up Dialog claims "This tile
>> cannot be
>> > laid in a valid orientation". This message is mis-leading because
>> > valid orientations exist, but The company laying the tile is NOT
>> > Allowed to lay due to lack of connection to the hex. And
>> then when you
>> > click OK, the list of available tiles gets cleared. I suggest the
>> > following:
>> >
>>
>> A. If the Tile is a location that can be laid by the company,
>> Highlight in a Green color (Green is good), or a lighter shade of the
>> Green Color. Better still would be a dashed thick Green/Blue to
>> distinguish.
>> B. If the Tile is a location that cannot be laid by the company,
>> Highlight in Red - And show allowed Tiles.
>> C. The Message should state the company cannot Lay Tile in that hex.
>>
>> 2. In the Token Laying Phase, if there is no legal place for the
>> company to lay a token, there is no token available, or not enough
>> money is available (unless the game allows emergency funding/loan
>> acquisition to make up the money), do a pop-up stating reason why
>> token cannot be laid, just like when "No Train means No Revenue".
>>
>> Mark
>>
>> --------------------------------------------------------------
>> -----------
>> 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
>>
>
>
> -------------------------------------------------------------------------
> 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
>

Re: [Rails-devel] Play by email

[Erik V. <eri...@hc...>]

It is perhaps worth noting, that saved game files currently do not contain
the current game state but the sequence of player actions. When a game is
reloaded, it is effectively replayed (without display). This was the easiest
way to implement Save/Load.
I'm not saying that it is impossible to compose a game state: it's the total
of all objects derived from the State class (plus a few more, like the
Players and the game options chosen). But nothing is yet keeping track of
what State objects exist.

Erik.

> -----Original Message-----
> From: brett lentz [mailto:wak...@gm...] 
> Sent: Friday 28 November 2008 20:37
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Play by email
> 
> On Thu, Nov 27, 2008 at 8:44 PM, Dave Mitton <da...@mi...> wrote:
> > Hmm... somehow I broke a filter and these messages were landing in
> > the wrong folder...
> >
> > On 11/25/2008 01:19 PM, brett lentz wrote:
> >>On Mon, Nov 24, 2008 at 6:05 PM, Dave Mitton 
> <da...@mi...> wrote:
> >> > Oh... I don't know about that.
> >> >
> >> > It's not jumping ahead a turn, it would be the ability to
> >> retroactively change
> >> > a turn or an asset that would bother me.  "I should have 
> bought that
> >> > last turn..."
> >>
> >>Until we implement an actual PBEM facility, the undo feature allows
> >>you to do this.
> >>
> >> > I would feel more comfortable in this kind of dynamic if the game
> >> generated a
> >> > crypto hash of the game state and made it visible to all players
> >> in the report.
> >> > And then it should be checked on subsequent turns so 
> that everything
> >> > was consistent with what was before.
> >> >
> >>
> >>
> >>What stops someone from generating that hash after they've saved a
> >>bogus game state?
> >
> > The hash would be generated in the log record between every turn.
> > The hash would reflect the game state, and re-entering the 
> same moves
> > should generate the same hash.
> >
> >
> >>Being an open-source project, there's nothing that prevents someone
> >>from compiling and using their own modified version of the game that
> >>generates correct checksums for invalid data. Being a small project,
> >>we simply don't have anyone volunteering to implement and maintain
> >>additional security mechanisms.
> >
> > I don't think it's really that hard, but I'm just talking 
> aloud here.
> > Indeed the mechanism should not care "how" the move got 
> entered, just
> > that the state of the game is "checksumed" if you will in a 
> manner that is
> > easy to verify and re-check after the fact.
> >
> >
> >>Further, we let the user manually input the value of their 
> train runs.
> >>Not only is this error prone, but it is an easy way for someone to
> >>accidentally give themselves an invalid amount of money. In my
> >>opinion, having someone getting patches in to implement automated
> >>route calculation will reduce a major potential source of 
> error and/or
> >>cheating (depending on your perspective).
> >
> > Another user reality that I came to quickly is that you will have to
> > correct or have users correct their moves.  People will screw up,
> > particularly if they don't have people looking over their shoulder
> > until the move is posting.   An Undo facility is necessary.
> > People make mistakes and I don't expect the game to get the rules
> > exactly correct.
> > Even if does, there will be times to override.
> >
> 
> I'm not sure if we're really understanding each other here.
> 
> I'm not arguing for removing the undo capability.  I'm saying that
> until we automatically calculate the value of the routes, giving the
> user the ability to manually input the value of the route is a far
> greater source of potential exploitation.
> 
> >
> >>I really don't think this should be a big concern. The nice thing
> >>about implementing a board game is that everything the app 
> does can be
> >>done by hand. If you want to validate that the calculations are
> >>correct, the math is fairly basic and well-known. It should 
> be trivial
> >>to find out if something isn't right.
> >
> > The math can be correct and still things go wrong.
> >
> 
> Like what?  I can't really think of anything that isn't easy to
> manually verify. We _are_ talking about a boardgame, after all.
> 
> Now it seems like you're just fear mongering.
> 
> >
> >> > I don't know if your code has this feature, but I put it 
> in my 1830
> >> > program when I was debugging.
> >> > An auditor pass would run between every turn:
> >> >         It would count up all the certificates, tokens, 
> anything I
> >> > could think of
> >> >         (and that should include cash) to make sure 
> everything was
> >> > accounted for
> >> >         and that the program didn't "leak" or "duplicate" any
> >> game materials.
> >> >
> >> >
> >> > Dave.
> >>
> >>We currently do not audit the game to that extent. Patches are
> >>welcome, if you'd like to add it.
> >>
> > Maybe one of these days.... at the moment I've been doing some
> > 10am-11pm hours C++ network authentication programming on 
> Vista.  I'm
> > not the happiest camper.
> >
> 
> Understandable. Just using Vista makes me unhappy, I'd hate to
> actually have to develop for it.
> 
> > Dave.
> >
> >
> 
> ----Brett.
> 
> --------------------------------------------------------------
> -----------
> 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
> 

Re: [Rails-devel] OK, Poking around a bit more

[Erik V. <eri...@hc...>]

Good suggestions. 

However, unless any of these ideas turns out to be easy to implement,
chances are that I will not get that very soon. In fiddling with the UI I
tend to be satisfied if things work (rather than look perfect). My focus is
on other aspects.

It might be a good idea to put such ideas in the bugs or feature requests
lists.

Erik.

> -----Original Message-----
> From: Mark Smith [mailto:mar...@gm...] 
> Sent: Friday 28 November 2008 17:13
> To: Rails Dev Mailing List
> Subject: Re: [Rails-devel] OK, Poking around a bit more
> 
> Grr... hit send to soon
> 
> On Fri, Nov 28, 2008 at 11:05 AM, Mark Smith 
> <mar...@gm...> wrote:
> > I have come across another Bug, and some suggestions:
> >
> > BUG -- When laying a Tile, you select a Hex, and it shows the
> > Allowable Upgrades. Select an Upgrade Tile, then select a DIFFERENT
> > Upgrade Tile for the same hex. The list of available Upgrade Tiles
> > goes blank. If you select a Different Hex, and then re-select the
> > original Hex the Upgrades re-appear.
> >
> > Suggestions:
> >
> > 1. If you select a Hex that you cannot lay a tile on, and try to
> > select a tile to place, the Pop-up Dialog claims "This tile 
> cannot be
> > laid in a valid orientation". This message is mis-leading because
> > valid orientations exist, but The company laying the tile is NOT
> > Allowed to lay due to lack of connection to the hex. And 
> then when you
> > click OK, the list of available tiles gets cleared. I suggest the
> > following:
> >
> 
> A. If the Tile is a location that can be laid by the company,
> Highlight in a Green color (Green is good), or a lighter shade of the
> Green Color. Better still would be a dashed thick Green/Blue to
> distinguish.
> B. If the Tile is a location that cannot be laid by the company,
> Highlight in Red - And show allowed Tiles.
> C. The Message should state the company cannot Lay Tile in that hex.
> 
> 2. In the Token Laying Phase, if there is no legal place for the
> company to lay a token, there is no token available, or not enough
> money is available (unless the game allows emergency funding/loan
> acquisition to make up the money), do a pop-up stating reason why
> token cannot be laid, just like when "No Train means No Revenue".
> 
> Mark
> 
> --------------------------------------------------------------
> -----------
> 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
> 

Re: [Rails-devel] Play by email

[brett l. <wak...@gm...>]

On Thu, Nov 27, 2008 at 8:44 PM, Dave Mitton <da...@mi...> wrote:
> Hmm... somehow I broke a filter and these messages were landing in
> the wrong folder...
>
> On 11/25/2008 01:19 PM, brett lentz wrote:
>>On Mon, Nov 24, 2008 at 6:05 PM, Dave Mitton <da...@mi...> wrote:
>> > Oh... I don't know about that.
>> >
>> > It's not jumping ahead a turn, it would be the ability to
>> retroactively change
>> > a turn or an asset that would bother me.  "I should have bought that
>> > last turn..."
>>
>>Until we implement an actual PBEM facility, the undo feature allows
>>you to do this.
>>
>> > I would feel more comfortable in this kind of dynamic if the game
>> generated a
>> > crypto hash of the game state and made it visible to all players
>> in the report.
>> > And then it should be checked on subsequent turns so that everything
>> > was consistent with what was before.
>> >
>>
>>
>>What stops someone from generating that hash after they've saved a
>>bogus game state?
>
> The hash would be generated in the log record between every turn.
> The hash would reflect the game state, and re-entering the same moves
> should generate the same hash.
>
>
>>Being an open-source project, there's nothing that prevents someone
>>from compiling and using their own modified version of the game that
>>generates correct checksums for invalid data. Being a small project,
>>we simply don't have anyone volunteering to implement and maintain
>>additional security mechanisms.
>
> I don't think it's really that hard, but I'm just talking aloud here.
> Indeed the mechanism should not care "how" the move got entered, just
> that the state of the game is "checksumed" if you will in a manner that is
> easy to verify and re-check after the fact.
>
>
>>Further, we let the user manually input the value of their train runs.
>>Not only is this error prone, but it is an easy way for someone to
>>accidentally give themselves an invalid amount of money. In my
>>opinion, having someone getting patches in to implement automated
>>route calculation will reduce a major potential source of error and/or
>>cheating (depending on your perspective).
>
> Another user reality that I came to quickly is that you will have to
> correct or have users correct their moves.  People will screw up,
> particularly if they don't have people looking over their shoulder
> until the move is posting.   An Undo facility is necessary.
> People make mistakes and I don't expect the game to get the rules
> exactly correct.
> Even if does, there will be times to override.
>

I'm not sure if we're really understanding each other here.

I'm not arguing for removing the undo capability.  I'm saying that
until we automatically calculate the value of the routes, giving the
user the ability to manually input the value of the route is a far
greater source of potential exploitation.

>
>>I really don't think this should be a big concern. The nice thing
>>about implementing a board game is that everything the app does can be
>>done by hand. If you want to validate that the calculations are
>>correct, the math is fairly basic and well-known. It should be trivial
>>to find out if something isn't right.
>
> The math can be correct and still things go wrong.
>

Like what?  I can't really think of anything that isn't easy to
manually verify. We _are_ talking about a boardgame, after all.

Now it seems like you're just fear mongering.

>
>> > I don't know if your code has this feature, but I put it in my 1830
>> > program when I was debugging.
>> > An auditor pass would run between every turn:
>> >         It would count up all the certificates, tokens, anything I
>> > could think of
>> >         (and that should include cash) to make sure everything was
>> > accounted for
>> >         and that the program didn't "leak" or "duplicate" any
>> game materials.
>> >
>> >
>> > Dave.
>>
>>We currently do not audit the game to that extent. Patches are
>>welcome, if you'd like to add it.
>>
> Maybe one of these days.... at the moment I've been doing some
> 10am-11pm hours C++ network authentication programming on Vista.  I'm
> not the happiest camper.
>

Understandable. Just using Vista makes me unhappy, I'd hate to
actually have to develop for it.

> Dave.
>
>

----Brett.