rails-devel — List for discussion of Rails development

Re: [Rails-devel] Half-hexes for 1825

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

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]

> As a proposal I have attached new tiles that show a double hatch pattern
> over the standard colors to indicate that this a tile that allows laying
against,
> but not laying into.
> 
> I have attached both half-tiles and a full tile.
> In addition there is a snapshot showing your current setup with half-tiles
with
> the pattern added.

Very good!  I'm going to finish the 1825 map borders with these tiles.

> I would even recommend adding a full or half-tile with a blue (maritime)
> background to show that at the south/eastern edge a tile lay against the
> border is not possible. I know that this is the current default (laying
against
> the border is forbidden), but I would prefer having more visual clues for
that
> as long as we do not have background maps as default for all games.

Yes, I agree.  We already have a blue tile for the 18EU ports, I would
propose to align with that colour.

Erik.

Re: [Rails-devel] Background maps

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

> > Zooming now works fine (except the first time, strange enough, for
> > both 18EU and 18GA).
> 
> I have not experienced the effect: What exactly is the bug (not zooming,
> background and tile have deviate in zoom) and is it reproducible at any
start-
> up or was it really only the first time you have started a game of 18GA
and
> 18EU?

Before your changes it went wrong consistently and (I think) in a
reproducible way.  
I don't understand why it still went wrong the first time after I pulled
your changes; it was as if Rails was still running without these changes.

Anyway, what happened in the past was, that when I reversed the zooming
direction (from in to out or vice versa), the map did not change scale once
(or maybe twice).
Something like:
1. Zoom in: all OK.
2. Zoom in: still OK.
3. Zoom out: tiles zoom out, map unchanged.
4 (or 5). Zoom out: both zoom out, but remain out of sync.

That misbehaviour seems to have been fixed now.

On your other remarks on SVG: obviously, the current code is a klu(d)ge.  I
can't really comment on the best way to approach it, as I have no experience
with real SVG programming, and very little with graphics programming in
general. I'm leaving that to Adam and you (and Brett, if he feels up to it).

Erik.

Re: [Rails-devel] Half-hexes for 1825

[Stefan F. <ste...@we...>]

Erik:
As a proposal I have attached new tiles that show a double hatch pattern
over the standard colors to indicate that this a tile that allows laying 
against, but not laying into.

I have attached both half-tiles and a full tile.
In addition there is a snapshot showing your current setup with half-tiles
with the pattern added.

I would even recommend adding a full or half-tile with a blue (maritime) 
background to show that at the south/eastern edge a tile lay against the 
border is not possible. I know that this is the current default (laying 
against the border is forbidden), but I would prefer having more visual clues 
for that as long as we do not have background maps as default for all games.
Stefan



On Wednesday, November 09, 2011 10:10:36 pm Erik Vos wrote:
> A while ago, Stefan sent me some half-hex tiles for use at the borders
> between of 1825 units.  It is allowed to lay track against such borders,
> but there was no visual cue that it was allowed.
> 
> I have now updated Unit 1 to use these half-tiles. It's still experimental.
> At the top border (with Unit 2 and R3) it looks fine, but at the left
> border (with kits R1 and R2) it doesn't look very pretty.  Try it and
> you'll see what I mean.  Or check the attached image.
> 
> To improve this, I think we need a duplicate of the empty hex tile #0
> (numbered e.g. #-25000), i.e. a full hex. The sole difference with #0 would
> be that it cannot be upgraded.
> The downside would be that now users would see full normally-looking hexes
> that yet cannot be upgraded.  So I wonder if we shouldn't give such tiles
> (and also the half-tiles)  a different background colour, such as the
> "buff" colour that is in fact used in 1825 for empty hexes.
> 
> Erik.

Re: [Rails-devel] Background maps

[Stefan F. <ste...@we...>]

On Wednesday, November 09, 2011 12:08:09 am Erik Vos wrote:
> That's a big achievement!   Thanks, Stefan.
> 
> Erik.
> 

Thanks to your preparations, but my contribution was merely to fix some bugs: 
Main issues were that the scale variable was defined as an integer, so that 
rounding errors occurred and the an assignment of a Dimension object variable 
where in reality a cloning was required.

To state my level of happiness for this code: 
The combination of a SVG canvas for the background map in a layer behind a 
Swing Canvas, which are aligned by manual calibration, acts only as a work-
around solution. 
Especially as tiles are SVG themselves but they get converted to 
BufferedImages and then painted on the Swing Canvas.

In the long run I suggest to follow the approach that Adam Badura suggested 
with his patch recently: A joint SVG document is manipulated to combine all 
graphic elements and is rendered by batik. A possible alternative is to paint 
everything on one or two instances of JSVGCanvas.

> Zooming now works fine (except the first time, strange enough, for both
> 18EU and 18GA).

I have not experienced the effect: What exactly is the bug (not zooming, 
background and tile have deviate in zoom) and is 
it reproducible at any start-up or was it really only the first time you have 
started a game of 18GA and 18EU?

> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Tuesday, November 08, 2011 11:58 PM
> > To: Development list for Rails: an 18xx game
> > Subject: [Rails-devel] Background maps
> > 
> > I have fixed several issues in the code to display SVG background maps.
> > 
> > To test if SVG maps are a possible solution for Rails I have asked Peter
> > Mumford for his 18GA map, which is available on boardgamegeek.
> > Fortunately he provided a SVG conversion that I have added to the
> > repository.
> > 
> > The other map that was already available, but was not usable to the code
> > issues, is for 18EU.
> > 
> > Anyone who want to test background maps in development has to activate
> > the configuration setting in the configuration menu in the Map panel =>
> > Display Background map.
> > 
> > I would be glad to get some feedback for different hardware. On my large
> > external TFT monitor everything is perfect readable, however the fonts of
> > the 18GA map on my notebook display are somehow small.
> > 
> > Stefan
> 
> ---------------------------------------------------------------------------
> - --
> 
> > RSA(R) Conference 2012
> > Save $700 by Nov 18
> > Register now
> > http://p.sf.net/sfu/rsa-sfdev2dev1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Half-hexes for 1825

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

A while ago, Stefan sent me some half-hex tiles for use at the borders
between of 1825 units.  It is allowed to lay track against such borders, but
there was no visual cue that it was allowed.

I have now updated Unit 1 to use these half-tiles. It's still experimental.
At the top border (with Unit 2 and R3) it looks fine, but at the left border
(with kits R1 and R2) it doesn't look very pretty.  Try it and you'll see
what I mean.  Or check the attached image.

To improve this, I think we need a duplicate of the empty hex tile #0
(numbered e.g. #-25000), i.e. a full hex. The sole difference with #0 would
be that it cannot be upgraded.  
The downside would be that now users would see full normally-looking hexes
that yet cannot be upgraded.  So I wonder if we shouldn't give such tiles
(and also the half-tiles)  a different background colour, such as the "buff"
colour that is in fact used in 1825 for empty hexes.

Erik.

Re: [Rails-devel] [Rails-commits] .settings/org.eclipse.core.resources.prefs .settings/org.eclipse.core.runtime.prefs data/18EU

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

For 18EU, I have changed the remaining two 'entities' in company names to
UTF-8-encoded characters. I did this on Stefan's suggestion, but somewhat
reluctantly, as entities (like Ö) are safer (encoding-independent low
ASCII) than the actual characters (Ö in this case).  But such decimal or
hexadecimal entities are badly readable.

I also have set the Eclipse text file encoding setting to UTF-8.  On my
Windows 7 PC, it was previously set to Cp1252, which caused problems in
JUnit testing: the 'standard' report files were not parsed as an UTF-8 file
but as Windows-encoded files.

This setting made Eclipse to update my version of file
.settings/org.eclipse.core.resources.prefs  by adding the encoding setting.
The repo already contained an empty version of this file, and so I have
pushed this setting now to the central repo.
I have also added file .settings/org.eclipse.core.runtime.prefs, which sets
the line separator to newline only.

I'm not sure, though, if it is necessary (or even useful) to put such
Eclipse-specific encoding standards into the repository.

Erik.

> -----Original Message-----
> From: Erik Vos [mailto:ev...@us...]
> Sent: Wednesday, November 09, 2011 4:30 PM
> To: rai...@li...
> Subject: [Rails-commits] .settings/org.eclipse.core.resources.prefs
> .settings/org.eclipse.core.runtime.prefs data/18EU
> 
>  .settings/org.eclipse.core.resources.prefs |    3 +++
>  .settings/org.eclipse.core.runtime.prefs   |    3 +++
>  data/18EU/CompanyManager.xml               |    4 ++--
>  3 files changed, 8 insertions(+), 2 deletions(-)
> 
> New commits:
> commit 6ca045795458ba9c3a9d8e14451bde3dbfaad23e
> Author: Erik Vos <eri...@xs...>
> Date:   Wed Nov 9 16:29:17 2011 +0100
> 
>     18EU: entities in company names changed to Unicode characters.
> 
>     Actually, entities are safer, as these are encoding-independent.
>     Characters (like C) require file encoding to be understood as UTF-8.

Here we go, I meant: Ö.

>     To ensure this, added Eclipse preference to encode/decode fiels as
UTF-8
>     (this affects reading/writing non-java and non-XML files).
>     Also set line delimiter to newline only.
> 

Re: [Rails-devel] 18EU bug in 1.5.2

[Stefan F. <ste...@we...>]

Erik,
I do not think it is a perfect solution and I do not feel happy about the 
current implementation. However I do not think that the code not only works 
correct accidentally, but there was a little consideration and some testing 
involved. Automatically choosing pass if pass is the only option is not a bad 
solution and the request in 18EU as well as the renewed request for 1835 by 
John David Galt showed that a silent pass in those cases is actually favored 
by most players.

And given my e-mail at the time of implementation in 2010 shows that I have 
not sneaked that feature into our code base.

However if you have a better solution I am more than happy to implement that 
and I could also add an additional check that it only silently passes in 
StartRounds and exclude all other RoundTypes. I have to admit that to me this 
seems more like an additional dependency, but this is based on my opinion that 
automatic (silent) passes is not a bad thing even outside of StartRounds.

Another idea would be to make this a Configuration option to allow Novice 
Players to be not surprised by automatic passes.

Stefan

On Tuesday, November 08, 2011 11:57:01 pm Erik Vos wrote:
> > > 2. I understood this code was intended to autopass in start rounds
> > > only, but nothing in that code restricts its working to start rounds.
> > > I would expect a condition like ' if (getCurrentRound() instanceof
> > 
> > StartRound) '.
> > 
> > I was undecided if it should cover also other cases. However in all other
> > Rounds it is never the case that the sole action is a pass: In
> > StockRounds there is always the AutoPass action available, in
> > OperatingRounds Pass is never the sole action too (here Skip or Done is
> > used). So pragmatically
> 
> there
> 
> > was no need for an additional restriction and no one ever commented if it
> > would be nice to extend it to the other cases, so I never followed up.
> 
> So correct working is dependent on unrelated circumstances accidentally
> being the case in other round types.
> 
> > > 3. The code claims to check that there is only a Pass in the possible
> > > actions, but in fact it only checks that the first action is a Pass.
> > > In practice that might be equivalent, at least in the current code,
> > > but it creates a dependency that I would rather avoid.  What you really
> > 
> > mean is:
> > > there is a pass and there isn't a bid or buy, i.e. no StartItemAction.
> > > Why not implement it that way?
> > 
> > Please refer to the implementation inside
> 
> PossibleAction.containsOnlyPass():
> > The code checks two conditions:
> > a) There is only one action and b) this action is a pass.
> > If both conditions are true the pass action is selected automatically.
> 
> And it works as long as this check is done before adding correction and
> undo/redo actions.
> 
> Well, if you feel happy with such dependencies, what can I say?  I'm not.
> 
> Erik.
> 
> 
> ---------------------------------------------------------------------------
> --- RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Background maps

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

That's a big achievement!   Thanks, Stefan.
Zooming now works fine (except the first time, strange enough, for both 18EU
and 18GA).  

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Tuesday, November 08, 2011 11:58 PM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Background maps
> 
> I have fixed several issues in the code to display SVG background maps.
> 
> To test if SVG maps are a possible solution for Rails I have asked Peter
> Mumford for his 18GA map, which is available on boardgamegeek.
> Fortunately he provided a SVG conversion that I have added to the
> repository.
> 
> The other map that was already available, but was not usable to the code
> issues, is for 18EU.
> 
> Anyone who want to test background maps in development has to activate
> the configuration setting in the configuration menu in the Map panel =>
> Display Background map.
> 
> I would be glad to get some feedback for different hardware. On my large
> external TFT monitor everything is perfect readable, however the fonts of
> the 18GA map on my notebook display are somehow small.
> 
> Stefan
> 
>
----------------------------------------------------------------------------
--
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU bug in 1.5.2

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

> > 2. I understood this code was intended to autopass in start rounds
> > only, but nothing in that code restricts its working to start rounds.
> > I would expect a condition like ' if (getCurrentRound() instanceof
> StartRound) '.
> 
> I was undecided if it should cover also other cases. However in all other
> Rounds it is never the case that the sole action is a pass: In StockRounds
> there is always the AutoPass action available, in OperatingRounds Pass is
> never the sole action too (here Skip or Done is used). So pragmatically
there
> was no need for an additional restriction and no one ever commented if it
> would be nice to extend it to the other cases, so I never followed up.

So correct working is dependent on unrelated circumstances accidentally
being the case in other round types.
 
> > 3. The code claims to check that there is only a Pass in the possible
> > actions, but in fact it only checks that the first action is a Pass.
> > In practice that might be equivalent, at least in the current code,
> > but it creates a dependency that I would rather avoid.  What you really
> mean is:
> > there is a pass and there isn't a bid or buy, i.e. no StartItemAction.
> > Why not implement it that way?
> 
> Please refer to the implementation inside
PossibleAction.containsOnlyPass():
> 
> The code checks two conditions:
> a) There is only one action and b) this action is a pass.
> If both conditions are true the pass action is selected automatically.

And it works as long as this check is done before adding correction and
undo/redo actions. 

Well, if you feel happy with such dependencies, what can I say?  I'm not.

Erik.

[Rails-devel] Background maps

[Stefan F. <ste...@we...>]

I have fixed several issues in the code to display SVG background maps.

To test if SVG maps are a possible solution for Rails I have asked Peter 
Mumford for his 18GA map, which is available on boardgamegeek.
Fortunately he provided a SVG conversion that I have added to the repository.

The other map that was already available, but was not usable to the code 
issues, is for 18EU. 

Anyone who want to test background maps in development has to activate the 
configuration setting in the configuration menu in the Map panel => Display 
Background map.

I would be glad to get some feedback for different hardware. On my large 
external TFT monitor everything is perfect readable, however the fonts of the 
18GA map on my notebook display are somehow small.

Stefan

Re: [Rails-devel] 18EU bug in 1.5.2

[Stefan F. <ste...@we...>]

Answers see below.
Stefan

On Tuesday, November 08, 2011 11:34:01 pm Erik Vos wrote:
> Stefan,
> 
> The reasons why I removed this code were:
> 1. I thought it was redundant, but apparently is does something that isn't
> done elsewhere, so I was wrong.  Sorry for that.

> 2. I understood this code was intended to autopass in start rounds only,
> but nothing in that code restricts its working to start rounds.  I would
> expect a condition like ' if (getCurrentRound() instanceof StartRound) '.

I was undecided if it should cover also other cases. However in all other 
Rounds it is never the case that the sole action is a pass: In StockRounds 
there is always the AutoPass action available, in OperatingRounds Pass is 
never the sole action too (here Skip or Done is used). So pragmatically there 
was no need for an additional restriction and no one ever commented if it 
would be nice to extend it to the other cases, so I never followed up.

> 3. The code claims to check that there is only a Pass in the possible
> actions, but in fact it only checks that the first action is a Pass.  In
> practice that might be equivalent, at least in the current code, but it
> creates a dependency that I would rather avoid.  What you really mean is:
> there is a pass and there isn't a bid or buy, i.e. no StartItemAction. 
> Why not implement it that way?

Please refer to the implementation inside PossibleAction.containsOnlyPass():

The code checks two conditions: 
a) There is only one action and b) this action is a pass. 
If both conditions are true the pass action is selected automatically.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Tuesday, November 08, 2011 10:54 PM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 18EU bug in 1.5.2
> > 
> > Erik:
> > I do not really understand your concerns here: This feature to silently
> 
> choose
> 
> > the pass action if it is the only available action was implemented on
> > 10/Jul/2010 (Commit 38a485) and released with version 1.4. in August
> > 2010.
> > 
> > As there have been no bugs reported so far on the list, I wonder why you
> > consider it likely that it will break some Stock Rounds.
> > 
> > Reverting your comments around the code fixes the issue and should not
> > raise any new issues, except that there is a dependency of 1835 on the
> > removal of that code. However from you commit message it seems that you
> > simply thought my code is redundant/obsolete, which was not the case.
> > 
> > Stefan
> > 
> > I dug up my e-mail that described the changes at the time of the
> > implementation, attached for reference here:
> > 
> > The pass option at the beginning of the 18EU minor initial sale round is
> > renamed to "decline to bid" for the first action of each player after the
> 
> minor
> 
> > selection. After that "pass" is active (implying "decline to buy").
> > 
> > I took the opportunity to implement the long-standing feature-request for
> > an autopass in the 18EU start round:
> > Anytime a player has not enough money to bid or buy, he passes
> > automatically (or declines to bid or declines to increase his bid).
> > Exception is the player after the selection of a minor as the first bid
> > is processed by the user interface instead of the backend. Here the
> > player
> 
> still
> 
> > has to select NoBid.
> > 
> > This fix covers all game situations, where a player has only the option
> > to
> 
> pass.
> 
> > The other occasion I have tested is the 1830 type StartRound. The general
> > StockRound is not effected (it allows both pass and autopass).
> > And it does not effect those cases, where players/companies have to
> > choose "Done" (e.g. after an action in the StockRound or during ORs).
> > 
> > In principle this behavior could be generalized to those occasions above,
> 
> but
> 
> > it might surprise players if their turn is skipped outside of the
> 
> StartRounds.
> 
> > The 1835 StartRound has its own autopass method implemented, which has a
> > pop-up message supplied.
> > So far I have not added a pop-up message box. It can be easily added, but
> > this works a little bit against the intention of a game speed up.
> > (Here and in some other occasions it would be nice to have a non-blocking
> > information panel).
> > 
> > On Tuesday, November 08, 2011 10:07:01 pm Erik Vos wrote:
> > > IIRC, the problem was that, although it might do some good for
> > > StartRounds, it did break some StockRounds.  For all I know, in
> > > StockRounds passing is only automatic if Autopass is set.
> > > 
> > > Feel free to try it out, but in any case I would like to do additional
> > > testing before it is released.  Such a change may (and I fear, will)
> > > have side effects.
> > > 
> > > Erik.
> > > 
> > > > -----Original Message-----
> > > > From: Stefan Frey [mailto:ste...@we...]
> > > > Sent: Tuesday, November 08, 2011 4:11 PM
> > > > To: Development list for Rails: an 18xx game
> > > > Subject: Re: [Rails-devel] 18EU bug in 1.5.2
> > > > 
> > > > Bill,
> > > > I will respond on behave and in addition to Erik (see below).
> > > > 
> > > > It seems that Erik thought at that time of his bug fix that the code
> > > > for automatic passes was out of date/ineffective and simply commented
> > 
> > it out.
> > 
> > > > However this is something that I introduced because of a feature
> > > > request especially for those occasions in 18EU. It took me some time
> > > > to fix side- effects that the next player was not chosen in the
> > > > correct sequence after
> > > 
> > > an
> > > 
> > > > automatic pass. I considered the 18EU StartRound to be quite a beast
> > > > ;-) (please no offense taken - Erik).
> > > > 
> > > >  This did not occur for the standard StartRound (1830 style). I
> > > > 
> > > > cannot
> > > > 
> > > > remember if I have checked 1835 StartRound at that time.
> > > > 
> > > > Unfortunately this is a UI function and thus cannot be tested by the
> > > 
> > > current
> > > 
> > > > automatic game tests.
> > > > 
> > > > My preferred solution is to fix that by uncommenting the code and
> > > > publish
> > > 
> > > a
> > > 
> > > > new Release 1.5.3, but I want Erik's opinion first, if this has any
> > > > impact
> > > 
> > > on
> > > 
> > > > 1835 or other games.
> > > > 
> > > > Stefan
> > > > 
> > > > On Tuesday, November 08, 2011 03:44:44 pm Bill Rosgen wrote:
> > > > > Erik,
> > > > > 
> > > > > As far as I can tell, a bug was introduced in commit 1893c3 that
> > > > > makes the 18EU minor auction unplayable in certain circumstances.
> > > > > This is the commit with message: "In 1835 Start Round, removed
> > > > > popups that reported forced passes.  Also removed some
> > 
> > redundant/ineffective code."
> > 
> > > > > Specifically, I think the problem occurs whenever a player is
> > > > > forced to pass in an auction due to a lack of funds.
> > > > > 
> > > > > It seems like the 18EU Starting Round depended on exactly how
> > > > > forced-passes were being implemented.  In the attached savegame,
> > > > > Carol has spent all of her money and so must pass on the minor
> > > > > being auctioned, but instead of this happening, the Starting Round
> > > > > window vanishes and Rails becomes non-functional.
> > > > > 
> > > > > Digging further, the commented out code on lines 897-9 of
> > > > > rails/GameManager.java seems to be the source of this behaviour.
> > > > > Uncommenting it (as well as the function it calls in
> > > > > PossibleActions) fixes 18EU, but it presumably will cause breakage
> > > > > elsewhere.  I suspect that StartRound_18EU.java has somehow
> > 
> > become
> > 
> > > > > obsolete, but after spending a while going through the various
> > > > > StartRound and GameManager classes, I can't find the problem.
> > > > > 
> > > > > Bill
> > > 
> > > ----------------------------------------------------------------------
> > > -----
> > > - --
> > > 
> > > > RSA(R) Conference 2012
> > > > Save $700 by Nov 18
> > > > Register now
> > > > http://p.sf.net/sfu/rsa-sfdev2dev1
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > 
> > > ----------------------------------------------------------------------
> > > -----
> > > --- RSA(R) Conference 2012
> > > Save $700 by Nov 18
> > > Register now
> > > http://p.sf.net/sfu/rsa-sfdev2dev1
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> - --
> 
> > RSA(R) Conference 2012
> > Save $700 by Nov 18
> > Register now
> > http://p.sf.net/sfu/rsa-sfdev2dev1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU bug in 1.5.2

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

Stefan,

The reasons why I removed this code were:
1. I thought it was redundant, but apparently is does something that isn't
done elsewhere, so I was wrong.  Sorry for that.
2. I understood this code was intended to autopass in start rounds only, but
nothing in that code restricts its working to start rounds.  I would expect
a condition like ' if (getCurrentRound() instanceof StartRound) '.
3. The code claims to check that there is only a Pass in the possible
actions, but in fact it only checks that the first action is a Pass.  In
practice that might be equivalent, at least in the current code, but it
creates a dependency that I would rather avoid.  What you really mean is:
there is a pass and there isn't a bid or buy, i.e. no StartItemAction.  Why
not implement it that way?

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Tuesday, November 08, 2011 10:54 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 18EU bug in 1.5.2
> 
> Erik:
> I do not really understand your concerns here: This feature to silently
choose
> the pass action if it is the only available action was implemented on
> 10/Jul/2010 (Commit 38a485) and released with version 1.4. in August 2010.
> 
> As there have been no bugs reported so far on the list, I wonder why you
> consider it likely that it will break some Stock Rounds.
> 
> Reverting your comments around the code fixes the issue and should not
> raise any new issues, except that there is a dependency of 1835 on the
> removal of that code. However from you commit message it seems that you
> simply thought my code is redundant/obsolete, which was not the case.
> 
> Stefan
> 
> I dug up my e-mail that described the changes at the time of the
> implementation, attached for reference here:
> 
> The pass option at the beginning of the 18EU minor initial sale round is
> renamed to "decline to bid" for the first action of each player after the
minor
> selection. After that "pass" is active (implying "decline to buy").
> 
> I took the opportunity to implement the long-standing feature-request for
> an autopass in the 18EU start round:
> Anytime a player has not enough money to bid or buy, he passes
> automatically (or declines to bid or declines to increase his bid).
> Exception is the player after the selection of a minor as the first bid is
> processed by the user interface instead of the backend. Here the player
still
> has to select NoBid.
> 
> This fix covers all game situations, where a player has only the option to
pass.
> The other occasion I have tested is the 1830 type StartRound. The general
> StockRound is not effected (it allows both pass and autopass).
> And it does not effect those cases, where players/companies have to choose
> "Done" (e.g. after an action in the StockRound or during ORs).
> 
> In principle this behavior could be generalized to those occasions above,
but
> it might surprise players if their turn is skipped outside of the
StartRounds.
> 
> The 1835 StartRound has its own autopass method implemented, which has a
> pop-up message supplied.
> So far I have not added a pop-up message box. It can be easily added, but
> this works a little bit against the intention of a game speed up.
> (Here and in some other occasions it would be nice to have a non-blocking
> information panel).
> 
> 
> 
> On Tuesday, November 08, 2011 10:07:01 pm Erik Vos wrote:
> > IIRC, the problem was that, although it might do some good for
> > StartRounds, it did break some StockRounds.  For all I know, in
> > StockRounds passing is only automatic if Autopass is set.
> >
> > Feel free to try it out, but in any case I would like to do additional
> > testing before it is released.  Such a change may (and I fear, will)
> > have side effects.
> >
> > Erik.
> >
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > > Sent: Tuesday, November 08, 2011 4:11 PM
> > > To: Development list for Rails: an 18xx game
> > > Subject: Re: [Rails-devel] 18EU bug in 1.5.2
> > >
> > > Bill,
> > > I will respond on behave and in addition to Erik (see below).
> > >
> > > It seems that Erik thought at that time of his bug fix that the code
> > > for automatic passes was out of date/ineffective and simply commented
> it out.
> > >
> > > However this is something that I introduced because of a feature
> > > request especially for those occasions in 18EU. It took me some time
> > > to fix side- effects that the next player was not chosen in the
> > > correct sequence after
> >
> > an
> >
> > > automatic pass. I considered the 18EU StartRound to be quite a beast
> > > ;-) (please no offense taken - Erik).
> > >
> > >  This did not occur for the standard StartRound (1830 style). I
> > > cannot
> > >
> > > remember if I have checked 1835 StartRound at that time.
> > >
> > > Unfortunately this is a UI function and thus cannot be tested by the
> >
> > current
> >
> > > automatic game tests.
> > >
> > > My preferred solution is to fix that by uncommenting the code and
> > > publish
> >
> > a
> >
> > > new Release 1.5.3, but I want Erik's opinion first, if this has any
> > > impact
> >
> > on
> >
> > > 1835 or other games.
> > >
> > > Stefan
> > >
> > > On Tuesday, November 08, 2011 03:44:44 pm Bill Rosgen wrote:
> > > > Erik,
> > > >
> > > > As far as I can tell, a bug was introduced in commit 1893c3 that
> > > > makes the 18EU minor auction unplayable in certain circumstances.
> > > > This is the commit with message: "In 1835 Start Round, removed
> > > > popups that reported forced passes.  Also removed some
> redundant/ineffective code."
> > > > Specifically, I think the problem occurs whenever a player is
> > > > forced to pass in an auction due to a lack of funds.
> > > >
> > > > It seems like the 18EU Starting Round depended on exactly how
> > > > forced-passes were being implemented.  In the attached savegame,
> > > > Carol has spent all of her money and so must pass on the minor
> > > > being auctioned, but instead of this happening, the Starting Round
> > > > window vanishes and Rails becomes non-functional.
> > > >
> > > > Digging further, the commented out code on lines 897-9 of
> > > > rails/GameManager.java seems to be the source of this behaviour.
> > > > Uncommenting it (as well as the function it calls in
> > > > PossibleActions) fixes 18EU, but it presumably will cause breakage
> > > > elsewhere.  I suspect that StartRound_18EU.java has somehow
> become
> > > > obsolete, but after spending a while going through the various
> > > > StartRound and GameManager classes, I can't find the problem.
> > > >
> > > > Bill
> >
> > ----------------------------------------------------------------------
> > -----
> > - --
> >
> > > RSA(R) Conference 2012
> > > Save $700 by Nov 18
> > > Register now
> > > http://p.sf.net/sfu/rsa-sfdev2dev1
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > --- RSA(R) Conference 2012
> > Save $700 by Nov 18
> > Register now
> > http://p.sf.net/sfu/rsa-sfdev2dev1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU bug in 1.5.2

[Stefan F. <ste...@we...>]

Erik:
I do not really understand your concerns here: This feature to silently 
choose the pass action if it is the only available action was implemented
on 10/Jul/2010 (Commit 38a485) and released with version 1.4. in August 2010.

As there have been no bugs reported so far on the list, I wonder why you 
consider it likely that it will break some Stock Rounds.

Reverting your comments around the code fixes the issue and should not raise 
any new issues, except that there is a dependency of 1835 on the removal of 
that code. However from you commit message it seems that you simply thought my 
code is redundant/obsolete, which was not the case.

Stefan

I dug up my e-mail that described the changes at the time of the 
implementation, attached for reference here:

The pass option at the beginning of the 18EU minor initial sale round is 
renamed to "decline to bid" for the first action of each player after the 
minor selection. After that "pass" is active (implying "decline to buy").

I took the opportunity to implement the long-standing feature-request for an 
autopass in the 18EU start round:
Anytime a player has not enough money to bid or buy, he passes automatically 
(or declines to bid or declines to increase his bid). 
Exception is the player after the selection of a minor as the first bid is 
processed by the user interface instead of the backend. Here the player still 
has to select NoBid.

This fix covers all game situations, where a player has only the option to 
pass. The other occasion I have tested is the 1830 type StartRound. The 
general StockRound is not effected (it allows both pass and autopass).
And it does not effect those cases, where players/companies have to  
choose "Done" (e.g. after an action in the StockRound or during ORs).

In principle this behavior could be generalized to those occasions above, but 
it might surprise players if their turn is skipped outside of the 
StartRounds.

The 1835 StartRound has its own autopass method implemented, which has a 
pop-up message supplied. 
So far I have not added a pop-up message box. It can be easily added, but this 
works a little bit against the intention of a game speed up. 
(Here and in some other occasions it would be nice to have a non-blocking 
information panel).



On Tuesday, November 08, 2011 10:07:01 pm Erik Vos wrote:
> IIRC, the problem was that, although it might do some good for StartRounds,
> it did break some StockRounds.  For all I know, in StockRounds passing is
> only automatic if Autopass is set.
> 
> Feel free to try it out, but in any case I would like to do additional
> testing before it is released.  Such a change may (and I fear, will) have
> side effects.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Tuesday, November 08, 2011 4:11 PM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 18EU bug in 1.5.2
> > 
> > Bill,
> > I will respond on behave and in addition to Erik (see below).
> > 
> > It seems that Erik thought at that time of his bug fix that the code for
> > automatic passes was out of date/ineffective and simply commented it out.
> > 
> > However this is something that I introduced because of a feature request
> > especially for those occasions in 18EU. It took me some time to fix side-
> > effects that the next player was not chosen in the correct sequence after
> 
> an
> 
> > automatic pass. I considered the 18EU StartRound to be quite a beast ;-)
> > (please no offense taken - Erik).
> > 
> >  This did not occur for the standard StartRound (1830 style). I cannot
> > 
> > remember if I have checked 1835 StartRound at that time.
> > 
> > Unfortunately this is a UI function and thus cannot be tested by the
> 
> current
> 
> > automatic game tests.
> > 
> > My preferred solution is to fix that by uncommenting the code and publish
> 
> a
> 
> > new Release 1.5.3, but I want Erik's opinion first, if this has any
> > impact
> 
> on
> 
> > 1835 or other games.
> > 
> > Stefan
> > 
> > On Tuesday, November 08, 2011 03:44:44 pm Bill Rosgen wrote:
> > > Erik,
> > > 
> > > As far as I can tell, a bug was introduced in commit 1893c3 that makes
> > > the 18EU minor auction unplayable in certain circumstances.  This is
> > > the commit with message: "In 1835 Start Round, removed popups that
> > > reported forced passes.  Also removed some redundant/ineffective code."
> > > Specifically, I think the problem occurs whenever a player is forced
> > > to pass in an auction due to a lack of funds.
> > > 
> > > It seems like the 18EU Starting Round depended on exactly how
> > > forced-passes were being implemented.  In the attached savegame, Carol
> > > has spent all of her money and so must pass on the minor being
> > > auctioned, but instead of this happening, the Starting Round window
> > > vanishes and Rails becomes non-functional.
> > > 
> > > Digging further, the commented out code on lines 897-9 of
> > > rails/GameManager.java seems to be the source of this behaviour.
> > > Uncommenting it (as well as the function it calls in PossibleActions)
> > > fixes 18EU, but it presumably will cause breakage elsewhere.  I
> > > suspect that StartRound_18EU.java has somehow become obsolete, but
> > > after spending a while going through the various StartRound and
> > > GameManager classes, I can't find the problem.
> > > 
> > > Bill
> 
> ---------------------------------------------------------------------------
> - --
> 
> > RSA(R) Conference 2012
> > Save $700 by Nov 18
> > Register now
> > http://p.sf.net/sfu/rsa-sfdev2dev1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU bug in 1.5.2

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

IIRC, the problem was that, although it might do some good for StartRounds,
it did break some StockRounds.  For all I know, in StockRounds passing is
only automatic if Autopass is set.

Feel free to try it out, but in any case I would like to do additional
testing before it is released.  Such a change may (and I fear, will) have
side effects.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Tuesday, November 08, 2011 4:11 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 18EU bug in 1.5.2
> 
> Bill,
> I will respond on behave and in addition to Erik (see below).
> 
> It seems that Erik thought at that time of his bug fix that the code for
> automatic passes was out of date/ineffective and simply commented it out.
> 
> However this is something that I introduced because of a feature request
> especially for those occasions in 18EU. It took me some time to fix side-
> effects that the next player was not chosen in the correct sequence after
an
> automatic pass. I considered the 18EU StartRound to be quite a beast ;-)
> (please no offense taken - Erik).
> 
>  This did not occur for the standard StartRound (1830 style). I cannot
> remember if I have checked 1835 StartRound at that time.
> 
> Unfortunately this is a UI function and thus cannot be tested by the
current
> automatic game tests.
> 
> My preferred solution is to fix that by uncommenting the code and publish
a
> new Release 1.5.3, but I want Erik's opinion first, if this has any impact
on
> 1835 or other games.
> 
> Stefan
> 
> 
> On Tuesday, November 08, 2011 03:44:44 pm Bill Rosgen wrote:
> > Erik,
> >
> > As far as I can tell, a bug was introduced in commit 1893c3 that makes
> > the 18EU minor auction unplayable in certain circumstances.  This is
> > the commit with message: "In 1835 Start Round, removed popups that
> > reported forced passes.  Also removed some redundant/ineffective code."
> > Specifically, I think the problem occurs whenever a player is forced
> > to pass in an auction due to a lack of funds.
> >
> > It seems like the 18EU Starting Round depended on exactly how
> > forced-passes were being implemented.  In the attached savegame, Carol
> > has spent all of her money and so must pass on the minor being
> > auctioned, but instead of this happening, the Starting Round window
> > vanishes and Rails becomes non-functional.
> >
> > Digging further, the commented out code on lines 897-9 of
> > rails/GameManager.java seems to be the source of this behaviour.
> > Uncommenting it (as well as the function it calls in PossibleActions)
> > fixes 18EU, but it presumably will cause breakage elsewhere.  I
> > suspect that StartRound_18EU.java has somehow become obsolete, but
> > after spending a while going through the various StartRound and
> > GameManager classes, I can't find the problem.
> >
> > Bill
> 
>
----------------------------------------------------------------------------
--
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU bug in 1.5.2

[<Dr....@t-...>]

Hi Stefan, 

	it probably will effect all games that have an Bid Mechanismus aside
from the normal Startround Behaviour. 

	I'll recheck the behaviour for 1880 on Thursday as i am traveling
right now and dont have access to the code. 

	Regards, 

	Martin  

	  Von: Stefan Frey <ste...@we...>
 An: "Development list for Rails: an 18xx game"
<rai...@li...>
 Betreff: Re: [Rails-devel] 18EU bug in 1.5.2
 Datum: Tue, 08 Nov 2011 16:10:45 +0100

 Bill,
 I will respond on behave and in addition to Erik (see below).

 It seems that Erik thought at that time of his bug fix that the code
for 
 automatic passes was out of date/ineffective and simply commented it
out. 

 However this is something that I introduced because of a feature
request 
 especially for those occasions in 18EU. It took me some time to fix
side-
 effects that the next player was not chosen in the correct sequence
after an 
 automatic pass. I considered the 18EU StartRound to be quite a beast
;-) 
 (please no offense taken - Erik).

 This did not occur for the standard StartRound (1830 style). I cannot

 remember if I have checked 1835 StartRound at that time.

 Unfortunately this is a UI function and thus cannot be tested by the
current
 automatic game tests.

 My preferred solution is to fix that by uncommenting the code and
publish a
 new Release 1.5.3, but I want Erik's opinion first, if this has any
impact on 
 1835 or other games.

 Stefan

 On Tuesday, November 08, 2011 03:44:44 pm Bill Rosgen wrote:
 > Erik,
 > 
 > As far as I can tell, a bug was introduced in commit 1893c3 that
makes the
 > 18EU minor auction unplayable in certain circumstances.  This is
the
 > commit with message: "In 1835 Start Round, removed popups that
reported
 > forced passes.  Also removed some redundant/ineffective code." 
 > Specifically, I think the problem occurs whenever a player is
forced to
 > pass in an auction due to a lack of funds.
 > 
 > It seems like the 18EU Starting Round depended on exactly how
forced-passes
 > were being implemented.  In the attached savegame, Carol has spent
all of
 > her money and so must pass on the minor being auctioned, but
instead of
 > this happening, the Starting Round window vanishes and Rails
becomes
 > non-functional.
 > 
 > Digging further, the commented out code on lines 897-9 of
 > rails/GameManager.java seems to be the source of this behaviour. 
 > Uncommenting it (as well as the function it calls in
PossibleActions)
 > fixes 18EU, but it presumably will cause breakage elsewhere.  I
suspect
 > that StartRound_18EU.java has somehow become obsolete, but after
spending
 > a while going through the various StartRound and GameManager
classes, I
 > can't find the problem.
 > 
 > Bill

 ------------------------------------------------------------------------------
 RSA(R) Conference 2012
 Save $700 by Nov 18
 Register now
 http://p.sf.net/sfu/rsa-sfdev2dev1
 _______________________________________________
 Rails-devel mailing list
 Rai...@li...
 https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU bug in 1.5.2

[Stefan F. <ste...@we...>]

Bill,
I will respond on behave and in addition to Erik (see below).

It seems that Erik thought at that time of his bug fix that the code for 
automatic passes was out of date/ineffective and simply commented it out. 

However this is something that I introduced because of a feature request 
especially for those occasions in 18EU. It took me some time to fix side-
effects that the next player was not chosen in the correct sequence after an 
automatic pass. I considered the 18EU StartRound to be quite a beast ;-) 
(please no offense taken - Erik).

 This did not occur for the standard StartRound (1830 style). I cannot 
remember if I have checked 1835 StartRound at that time.

Unfortunately this is a UI function and thus cannot be tested by the current
automatic game tests.

My preferred solution is to fix that by uncommenting the code and publish a
new Release 1.5.3, but I want Erik's opinion first, if this has any impact on 
1835 or other games.

Stefan


On Tuesday, November 08, 2011 03:44:44 pm Bill Rosgen wrote:
> Erik,
> 
> As far as I can tell, a bug was introduced in commit 1893c3 that makes the
> 18EU minor auction unplayable in certain circumstances.  This is the
> commit with message: "In 1835 Start Round, removed popups that reported
> forced passes.  Also removed some redundant/ineffective code." 
> Specifically, I think the problem occurs whenever a player is forced to
> pass in an auction due to a lack of funds.
> 
> It seems like the 18EU Starting Round depended on exactly how forced-passes
> were being implemented.  In the attached savegame, Carol has spent all of
> her money and so must pass on the minor being auctioned, but instead of
> this happening, the Starting Round window vanishes and Rails becomes
> non-functional.
> 
> Digging further, the commented out code on lines 897-9 of
> rails/GameManager.java seems to be the source of this behaviour. 
> Uncommenting it (as well as the function it calls in PossibleActions)
> fixes 18EU, but it presumably will cause breakage elsewhere.  I suspect
> that StartRound_18EU.java has somehow become obsolete, but after spending
> a while going through the various StartRound and GameManager classes, I
> can't find the problem.
> 
> Bill

[Rails-devel] 18EU bug in 1.5.2

[Bill R. <ro...@gm...>]

Erik,

As far as I can tell, a bug was introduced in commit 1893c3 that makes the 18EU minor auction unplayable in certain circumstances.  This is the commit with message: "In 1835 Start Round, removed popups that reported forced passes.  Also removed some redundant/ineffective code."  Specifically, I think the problem occurs whenever a player is forced to pass in an auction due to a lack of funds.

It seems like the 18EU Starting Round depended on exactly how forced-passes were being implemented.  In the attached savegame, Carol has spent all of her money and so must pass on the minor being auctioned, but instead of this happening, the Starting Round window vanishes and Rails becomes non-functional.

Digging further, the commented out code on lines 897-9 of rails/GameManager.java seems to be the source of this behaviour.  Uncommenting it (as well as the function it calls in PossibleActions) fixes 18EU, but it presumably will cause breakage elsewhere.  I suspect that StartRound_18EU.java has somehow become obsolete, but after spending a while going through the various StartRound and GameManager classes, I can't find the problem.

Bill

[Rails-devel] Rails 1.5.2 available

[Stefan F. <ste...@we...>]

A new bug-fix release 1.5.2 for Rails is available.

Downloads are available at http://rails.sourceforge.net/ or by the
direct link https://sourceforge.net/projects/rails/files/Rails/1.5.2/

It should fix all known bugs for 1830 Coalfields, 1835, 18EU, 18GA and 18TN.

Stefan

Detailed list of fixes:

- Fixed wrong revenue value (20) of NW city on tile -803 (1835 Hamburg)
- Fixed 1835 bug: Hangs in first OR if Start Packet not sold.
- Fixed 1835 bug: Crash in final PR formation round.
- Removed pop-ups for forced passes during start-round.
- Fixed 18GA stock market value of square M3 from 100 to 190
- Fixed 18GA: missing cost of hex J10
- Fixed 18TN grey tile being not available due to error in phase definition
- Fix: Buying Coalfields right is now refused if the company does not have 
enough cash.
- 18EU: fixed wrong train limit step from phase 5.

- Trainlist field now auto-wraps
- Fixed display of operating companies in networkinfo menu

Re: [Rails-devel] 18EU: Two remaining bugs related to train limit.

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

I said: the train limit *step*, which increases 1,2,3.
The actual major company train limits for these steps are 4,3,2 (and the
minor limits are 2,1 - the third value is omitted because it doesn't
matter).

Erik


> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> Sent: Wednesday, November 02, 2011 7:12 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 18EU: Two remaining bugs related to train
limit.
> 
> On 2011-11-01 06:25, Erik Vos wrote:
> > It turned out to be a typo in the (new) 18EU phase configuration.  The
> > train limit step for phase 5 and beyond was incorrectly specified as
> > "2", it should have been "3".  My bad.
> 
> You mean the other way around, right?
> 
>
----------------------------------------------------------------------------
--
> RSA® Conference 2012
> Save $700 by Nov 18
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU: Two remaining bugs related to train limit.

[Dr. M. B. <dr....@t-...>]

No :)

Ist not the limit itself but the steps regarding the limit.

So step 1 is Train limit 4
Step 2 is train limit 3
Step 3 is train limit 2 

Regards,
Martin

-----Ursprüngliche Nachricht-----
Von: John David Galt [mailto:jd...@di...] 
Gesendet: Mittwoch, 2. November 2011 19:12
An: Development list for Rails: an 18xx game
Betreff: Re: [Rails-devel] 18EU: Two remaining bugs related to train limit.

On 2011-11-01 06:25, Erik Vos wrote:
> It turned out to be a typo in the (new) 18EU phase configuration.  The 
> train limit step for phase 5 and beyond was incorrectly specified as 
> "2", it should have been "3".  My bad.

You mean the other way around, right?

----------------------------------------------------------------------------
--
RSA® Conference 2012
Save $700 by Nov 18
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU: Two remaining bugs related to train limit.

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

On 2011-11-01 06:25, Erik Vos wrote:
> It turned out to be a typo in the (new) 18EU phase configuration.  The train
> limit step for phase 5 and beyond was incorrectly specified as "2", it
> should have been "3".  My bad.

You mean the other way around, right?

Re: [Rails-devel] 18EU: Two remaining bugs related to train limit.

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

It turned out to be a typo in the (new) 18EU phase configuration.  The train
limit step for phase 5 and beyond was incorrectly specified as "2", it
should have been "3".  My bad.

I have added the train limits to Info|Company (per company), and the train
limit steps to Info|Phase (per phase).
I have also fixed the allowed tile lay colours for phases where that info
was the same as for previous phases, where it was reported as "null".

I see no great need for refactoring.  Train limits are defined per
PublicCompany, so there is nothing wrong with the current high-level call
getCurrentTrainLimit().
The number of calls could be reduced by one by merging it with getTrainLimit
(index). 
It's mainly the new train limit *step* mechanism that has made getting the
train limit a bit more complex than it was before.

Erik.

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Monday, October 31, 2011 12:40 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] 18EU: Two remaining bugs related to train
limit.
> 
> Stefan,
> 
> Thanks for your analysis.
> Today I don't have much time, but tomorrow I'll try to sort out where we
are
> and what I can do about it.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Monday, October 31, 2011 12:11 PM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 18EU: Two remaining bugs related to train
> limit.
> >
> > Thanks for that bug report.
> >
> > Some notes for Erik:
> >
> > I do not consider this error as minor, it seems to be a more general
> issue.
> >
> > I had a quick look at this at seems that this goes back to the methods
> > getCurrentTrainLimit and getTrainLimit(int index) inside PublicCompany
> >
> > It seems that your changes of the PhaseManagement got this out of synch.
> > Maybe this could refactored a little bit, as it requires many steps of
> function
> > forwarding to get to those methods and involves some conversion to
> > integer and using that as an array index, which most likely  is the
> > reason for
> that
> > problem.
> >
> > I believe a method with something like getTrainLimit(Phase phase,
> > PublicCompany company) would be much safer. If this is located in
> > Phase, PhaseManager or PublicCompany is a matter of taste. Another
> > possibility is to have the phase change trigger a change of an integer
> > state variable
> that
> > stores the number of trains available for each company.
> >
> > This problem could potentially arise in other games than 18EU.
> Unfortunately
> > the reduction of the train limit seems to be unreported in the game
> report,
> > thus it is not covered by our automated tests, so maybe this could be
> added
> > too.
> >
> > During debugging I realized that the train limit is not shown in the
> > Phase menu, so it appears that is shown nowhere. A (minor) bug is that
> > the tile colors are shown as null for those phases, where the tile
> > laying does not change.
> >
> > I will wait with the new release for a fix from your side, unless you
> > tell
> me
> > that this bug will require a substantial amount of work and would
> > delay a
> new
> > release for several days.
> >
> > Stefan
> >
> > Methods Quoted here:
> >
> >     /** Get the current maximum number of trains got a given limit
index.
> >      * @parm index The index of the train limit step as defined for
> > the
> current
> > phase. Values start at 0.
> >      * <p>N.B. the new style limit steps per phase start at 1,
> >      * so one must be subtracted before calling this method.
> >      */
> >     protected int getTrainLimit(int index) {
> >         return trainLimit[Math.min(index, trainLimit.length - 1)];
> >     }
> >
> >     public int getCurrentTrainLimit() {
> >         return
> > getTrainLimit(gameManager.getCurrentPhase().getTrainLimitIndex());
> >     }
> >
> >
> >
> >
> >
> > On Monday, October 31, 2011 02:14:03 am John David Galt wrote:
> > > In a three-player game of 18EU under Rails 1.5.1 (save file
> > > attached), I found two minor bugs.
> > >
> > > 1) The train limit is not reduced to two until a 6-train is
> > > purchased (should happen when the 5-train is purchased).
> > >
> > > 2) A company that has a Pullman and hits the limit is given a choice
> > > of which train to discard (it's supposed to automatically be the
Pullman).
> >
> >
>
----------------------------------------------------------------------------
> --
> > Get your Android app more play: Bring it to the BlackBerry PlayBook in
> > minutes. BlackBerry App World&#153; now supports Android&#153; Apps
> > for the BlackBerry&reg; PlayBook&#153;. Discover just how easy and
> > simple it is! http://p.sf.net/sfu/android-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
>
----------------------------------------------------------------------------
--
> Get your Android app more play: Bring it to the BlackBerry PlayBook in
> minutes. BlackBerry App World&#153; now supports Android&#153; Apps for
> the BlackBerry&reg; PlayBook&#153;. Discover just how easy and simple it
is!
> http://p.sf.net/sfu/android-dev2dev
> 
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU: Two remaining bugs related to train limit.

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

Stefan,

Thanks for your analysis.
Today I don't have much time, but tomorrow I'll try to sort out where we are
and what I can do about it.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, October 31, 2011 12:11 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 18EU: Two remaining bugs related to train
limit.
> 
> Thanks for that bug report.
> 
> Some notes for Erik:
> 
> I do not consider this error as minor, it seems to be a more general
issue.
> 
> I had a quick look at this at seems that this goes back to the methods
> getCurrentTrainLimit and getTrainLimit(int index) inside PublicCompany
> 
> It seems that your changes of the PhaseManagement got this out of synch.
> Maybe this could refactored a little bit, as it requires many steps of
function
> forwarding to get to those methods and involves some conversion to integer
> and using that as an array index, which most likely  is the reason for
that
> problem.
> 
> I believe a method with something like getTrainLimit(Phase phase,
> PublicCompany company) would be much safer. If this is located in Phase,
> PhaseManager or PublicCompany is a matter of taste. Another possibility is
> to have the phase change trigger a change of an integer state variable
that
> stores the number of trains available for each company.
> 
> This problem could potentially arise in other games than 18EU.
Unfortunately
> the reduction of the train limit seems to be unreported in the game
report,
> thus it is not covered by our automated tests, so maybe this could be
added
> too.
> 
> During debugging I realized that the train limit is not shown in the Phase
> menu, so it appears that is shown nowhere. A (minor) bug is that the tile
> colors are shown as null for those phases, where the tile laying does not
> change.
> 
> I will wait with the new release for a fix from your side, unless you tell
me
> that this bug will require a substantial amount of work and would delay a
new
> release for several days.
> 
> Stefan
> 
> Methods Quoted here:
> 
>     /** Get the current maximum number of trains got a given limit index.
>      * @parm index The index of the train limit step as defined for the
current
> phase. Values start at 0.
>      * <p>N.B. the new style limit steps per phase start at 1,
>      * so one must be subtracted before calling this method.
>      */
>     protected int getTrainLimit(int index) {
>         return trainLimit[Math.min(index, trainLimit.length - 1)];
>     }
> 
>     public int getCurrentTrainLimit() {
>         return
> getTrainLimit(gameManager.getCurrentPhase().getTrainLimitIndex());
>     }
> 
> 
> 
> 
> 
> On Monday, October 31, 2011 02:14:03 am John David Galt wrote:
> > In a three-player game of 18EU under Rails 1.5.1 (save file attached), I
> > found two minor bugs.
> >
> > 1) The train limit is not reduced to two until a 6-train is purchased
> > (should happen when the 5-train is purchased).
> >
> > 2) A company that has a Pullman and hits the limit is given a choice of
> > which train to discard (it's supposed to automatically be the Pullman).
> 
>
----------------------------------------------------------------------------
--
> Get your Android app more play: Bring it to the BlackBerry PlayBook
> in minutes. BlackBerry App World&#153; now supports Android&#153; Apps
> for the BlackBerry&reg; PlayBook&#153;. Discover just how easy and simple
> it is! http://p.sf.net/sfu/android-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU: Two remaining bugs related to train limit.

[Stefan F. <ste...@we...>]

Thanks for that bug report.

Some notes for Erik:

I do not consider this error as minor, it seems to be a more general issue.

I had a quick look at this at seems that this goes back to the methods 
getCurrentTrainLimit and getTrainLimit(int index) inside PublicCompany

It seems that your changes of the PhaseManagement got this out of synch. 
Maybe this could refactored a little bit, as it requires many steps of 
function forwarding to get to those methods and involves some conversion to 
integer and using that as an array index, which most likely  is the reason for 
that problem.

I believe a method with something like getTrainLimit(Phase phase, 
PublicCompany company) would be much safer. If this is located in Phase, 
PhaseManager or PublicCompany is a matter of taste. Another possibility is to 
have the phase change trigger a change of an integer state variable that 
stores the number of trains available for each company.

This problem could potentially arise in other games than 18EU. Unfortunately 
the reduction of the train limit seems to be unreported in the game report, 
thus it is not covered by our automated tests, so maybe this could be added 
too.

During debugging I realized that the train limit is not shown in the Phase 
menu, so it appears that is shown nowhere. A (minor) bug is that the tile 
colors are shown as null for those phases, where the tile laying does not 
change. 

I will wait with the new release for a fix from your side, unless you tell me 
that this bug will require a substantial amount of work and would delay a new 
release for several days.

Stefan

Methods Quoted here:

    /** Get the current maximum number of trains got a given limit index.
     * @parm index The index of the train limit step as defined for the 
current phase. Values start at 0.
     * <p>N.B. the new style limit steps per phase start at 1,
     * so one must be subtracted before calling this method.
     */
    protected int getTrainLimit(int index) {
        return trainLimit[Math.min(index, trainLimit.length - 1)];
    }

    public int getCurrentTrainLimit() {
        return 
getTrainLimit(gameManager.getCurrentPhase().getTrainLimitIndex());
    }





On Monday, October 31, 2011 02:14:03 am John David Galt wrote:
> In a three-player game of 18EU under Rails 1.5.1 (save file attached), I
> found two minor bugs.
> 
> 1) The train limit is not reduced to two until a 6-train is purchased
> (should happen when the 5-train is purchased).
> 
> 2) A company that has a Pullman and hits the limit is given a choice of
> which train to discard (it's supposed to automatically be the Pullman).

Re: [Rails-devel] 18EU: Two remaining bugs related to train limit.

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

This has worked in the past, so I suppose that the phase management changes
have had some yet undetected side effects.

Stefan, if you can wait for a few more days, I'll try to fix these problems
for the new release.

Erik.

> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> Sent: Monday, October 31, 2011 2:14 AM
> To: rai...@li...
> Subject: [Rails-devel] 18EU: Two remaining bugs related to train limit.
> 
> In a three-player game of 18EU under Rails 1.5.1 (save file attached), I
found
> two minor bugs.
> 
> 1) The train limit is not reduced to two until a 6-train is purchased
(should
> happen when the 5-train is purchased).
> 
> 2) A company that has a Pullman and hits the limit is given a choice of
which
> train to discard (it's supposed to automatically be the Pullman).