rails-devel — List for discussion of Rails development

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

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

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] 18TN Fixes for Bugs reported by Rich

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

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Sunday, October 30, 2011 6:49 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 18TN Fixes for Bugs reported by Rich
> 
> I will create a new release tonight/tomorrow morning with all recent fixes.
> Thanks for the input to all contributors.
> Stefan

I think I'm done with fixes now. So please go ahead.

Erik.

Re: [Rails-devel] Rails

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

Done.

 

From: sco...@gm... [mailto:sco...@gm...] On Behalf
Of Scott Petersen
Sent: Thursday, October 27, 2011 2:43 PM
To: Erik Vos
Subject: Rails

 

Erik,

 

Feel free to remove my 18Jr prototype from Rails.  I never updated to egit
and I probably won't in the near future.

 

Scott

Re: [Rails-devel] 1825 half-tiles

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

Fixed.  The Coalfields cost was not checked against the company cash.

 

(Sorry Stefan, it's OperatingRound again; I have only changed buyRights()).


Erik.

 

From: Charles Strong [mailto:men...@gm...] 
Sent: Saturday, October 29, 2011 6:17 PM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1825 half-tiles

 

Playing a game of 1830 w/ Coalfields. A company was allowed to buy access to
the coal fields without having the full amount of funds in the treasury.
Instead of showing a popup not allowing it, like it does with tokens & paid
tile lays. This pushed the company's treasury into the negative, which also
had the side effect of not allowing a regular tile lay (which showed a cost
of $0). 

Re: [Rails-devel] 18TN Fixes for Bugs reported by Rich

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

I will create a new release tonight/tomorrow morning with all recent fixes.
Thanks for the input to all contributors.
Stefan

On Sunday, October 30, 2011 06:29:46 pm Erik Vos wrote:
> Thanks, Martin, for sorting this one out.
> 
> 
> 
> I didn’t manage to load the git patch, because an error was reported:
> “fatal: corrupt patch at line 25”.  I don’t understand that error message,
> as nothing seems wrong at all.
> 
> Anyway, the old and trusted non-git patch loaded fine via Egit.  And this
> time I did remember to put in the correct author.
> 
> 
> 
> Erik.
> 
> 
> 
> From: Dr....@t-... [mailto:Dr....@t-...]
> Sent: Sunday, October 30, 2011 4:37 PM
> To: Rails Development
> Subject: [Rails-devel] 18TN Fixes for Bugs reported by Rich
> 
> 
> 
> 
> 
> Hi,
> 
> 
> 
> 
> 
> please find enclosed the patch in git and egit for the 18TN problems
> reported last friday.
> 
> 
> 
> The Tile 170 had the wrong quantity.
> 
> The tile 600 wasnt available as the phase definition wasnt using grey tiles
> at all.
> 
> 
> 
> Regards,
> 
> Martin

Re: [Rails-devel] 18TN Fixes for Bugs reported by Rich

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

Thanks, Martin, for sorting this one out.

 

I didn’t manage to load the git patch, because an error was reported: “fatal: corrupt patch at line 25”.  I don’t understand that error message, as nothing seems wrong at all.

Anyway, the old and trusted non-git patch loaded fine via Egit.  And this time I did remember to put in the correct author.

 

Erik.

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Sunday, October 30, 2011 4:37 PM
To: Rails Development
Subject: [Rails-devel] 18TN Fixes for Bugs reported by Rich

 

 

Hi,

 

 

please find enclosed the patch in git and egit for the 18TN problems reported last friday.

 

The Tile 170 had the wrong quantity.

The tile 600 wasnt available as the phase definition wasnt using grey tiles at all.

 

Regards,

Martin

Re: [Rails-devel] 1825 half-tiles

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

I think leaving in Q11 (with an impassibility) and leaving out Q21 is good
enough. 
Sharp-eyed players can indeed detect what access the Unit 2 Q row hexes
would allow.  Whether or not that is relevant, that's the question.
But I have no problem with your view, which amounts to retaining the
existing behaviour, without the 'open' attributes.

Where it really will start looking ugly is on the left-hand side, adjacent
to the R1 and  R2 kits.  Wait and see...

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday, October 29, 2011 4:12 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 half-tiles
> 
> Erik:
> from my point of view it is clear, however I have not checked the rules
again.
> Especially as the 1825 rules are ambiguous in many respect anyway and then
> the
> 1825 Unit 1 some rules are different (at least in wording) to those of
unit 2
> and 3.
> 
> So I would not allow running to Q11 and Q21 even if unit 2 and/or R3 are
not
> present: My main reasoning here is that there are visual clues for both
the
> brown edge without track for Q11/SW and the blue/green sea for Q21.
> 
> Thus I suggest to add both Q11 and make the edge impassable. I would even
> consider adding Q21 and make both edges impassable if this looks better on
> a whole.
> 
> Stefan
> 
> 
> On Saturday, October 29, 2011 03:45:37 pm Erik Vos wrote:
> > Ah yes, of course we could use that.
> > But the question if we *should* do it has not yet been answered.
> >
> > Erik.
> >
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > > Sent: Saturday, October 29, 2011 2:14 PM
> > > To: Development list for Rails: an 18xx game
> > > Subject: Re: [Rails-devel] 1825 half-tiles
> > >
> > > I was under the impression that the "impassable" attribute actually
> > > does exactly that. Or is it not possible to use it in the scenario
> > > below for a
> >
> > different
> >
> > > reason?
> > > Stefan
> > >
> > > On Saturday, October 29, 2011 02:07:00 pm Erik Vos wrote:
> > > > The "existing mechanism" only allows opening hex edges that would
> > > > otherwise be closed, not the other way around.
> > > > Of course we can extend (or replace) that mechanism.  I'm just
> > > > trying to find out if this very minor issue (as JDG correctly
> > > > points out) is really worth it to create an exception for, also in
> > > > the light of the uncertainty about what the rules (as cited) really
say.
> > > >
> > > > BTW: Q11 is Crewe, not Wolverton.
> > > >
> > > > Erik.
> > > >
> > > > > From: Stefan Frey [mailto:ste...@we...]
> > > > >
> > > > > Could you not lay the half tile on Q11 and block the SW side of
> > > > > hex tile
> > > >
> > > > Q11
> > > >
> > > > > using the existing mechanism?
> > > > >
> > > > > On Friday, October 28, 2011 10:22:45 pm Erik Vos wrote:
> > > > > > I'm including these half-tiles into 1825 Unit 1, and it
> > > > > > basically works. As expected, it turns out, that adding these
> > > > > > half-tiles makes the existing "open" attributes redundant.
> > > > > > This attribute achieves the same thing: that track can be laid
> > > > > > towards the board
> >
> > edge.
> >
> > > > > > However, the question arises how to interpret the rule that
> > > > > > "Tiles may be placed so that a railway terminates against the
> > > > > > edge of the board or against the side of an incomplete hexag"
> > > > > > in some specific cases where laying track would not be allowed
> > > > > > if the adjacent board was actually present.  For Unit 1, this
> > > > > > refers to the Q row hexes, of which only the southernmost
> > > > > > corner is just visible on the Unit1 game board.  If taken
> > > > > > literally, the cited rule would allow track lays against all
> > > > > > edges of the Q row hexes if
> > >
> > > Unit2/R3 are absent.
> > >
> > > > > > However, if both Unit2 and Kit R3 are present, hex Q11
> > > > > > (Wolverton) would be only reachable from the SE, and hex Q21
(The
> Wash, i.e.
> > > > > > sea)
> > > >
> > > > not
> > > >
> > > > > at all.
> > > > >
> > > > > > And that is how I had implemented it also for the case that
> > > > > > Unit2/R3 are absent (I only vaguely remember that we might
> > > > > > have had some discussion about this issue).
> > > > > >
> > > > > > My current preference is to use a half-tile on hex Q11 (to
> > > > > > which therefore track can be laid from both the SW and SE
> > > > > > directions), and to omit it on hex Q21 (which therefore cannot
> > > > > > be laid any track against).  To replicate the current
> > > > > > behaviour, I would have to omit the half-tile from Q11, and keep
> using the existing 'open'
> > > > > > attribute instead, so that Q11 can only be laid track against
> > > > > > from
> >
> > the SE.
> >
> > > > > > Any opinions?
> > > > > >
> > > > > > Erik.
> > > >
> > > > ------------------------------------------------------------------
> > > > ----
> > > > -----
> > > > --- Get your Android app more play: Bring it to the BlackBerry
> > > > PlayBook in minutes. BlackBerry App World™ now supports
> > > > Android™ Apps for the BlackBerry® PlayBook™.
> > > > 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™ now supports Android™
> > > Apps for the BlackBerry® PlayBook™. 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™ now supports
> > Android™ Apps for the BlackBerry® PlayBook™. 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™ now supports Android™ Apps for
> the BlackBerry® PlayBook™. 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] 1825 half-tiles

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

Martin,

Your remark is about *how* the map variations are configured; I don't see a
major problem with how that is done currently.

But the issue is *what* we need to configure (i.e. how do we interpret the
rules).

Erik.

> -----Original Message-----
> From: Dr. Martin Brumm [mailto:Dr....@t-...]
> Sent: Saturday, October 29, 2011 4:28 PM
> To: Development list for Rails: an 18xx game
> Cc: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 half-tiles
> 
> Hi all,
> 
> Maybe a dumb suggestion, but cant we fix it with different submaps for the
> respective variants and the half tiles ?
> 
> Currently you cant define complete maps for variants might that be a way
to
> solve that problem ?
> 
> Von meinem iPad gesendet
> 
> Am 29.10.2011 um 16:11 schrieb Stefan Frey <ste...@we...>:
> 
> > Erik:
> > from my point of view it is clear, however I have not checked the rules
> again.
> > Especially as the 1825 rules are ambiguous in many respect anyway and
> > then the
> > 1825 Unit 1 some rules are different (at least in wording) to those of
> > unit 2 and 3.
> >
> > So I would not allow running to Q11 and Q21 even if unit 2 and/or R3
> > are not
> > present: My main reasoning here is that there are visual clues for
> > both the brown edge without track for Q11/SW and the blue/green sea for
> Q21.
> >
> > Thus I suggest to add both Q11 and make the edge impassable. I would
> > even consider adding Q21 and make both edges impassable if this looks
> > better on a whole.
> >
> > Stefan
> >
> >
> > On Saturday, October 29, 2011 03:45:37 pm Erik Vos wrote:
> >> Ah yes, of course we could use that.
> >> But the question if we *should* do it has not yet been answered.
> >>
> >> Erik.
> >>
> >>> -----Original Message-----
> >>> From: Stefan Frey [mailto:ste...@we...]
> >>> Sent: Saturday, October 29, 2011 2:14 PM
> >>> To: Development list for Rails: an 18xx game
> >>> Subject: Re: [Rails-devel] 1825 half-tiles
> >>>
> >>> I was under the impression that the "impassable" attribute actually
> >>> does exactly that. Or is it not possible to use it in the scenario
> >>> below for a
> >>
> >> different
> >>
> >>> reason?
> >>> Stefan
> >>>
> >>> On Saturday, October 29, 2011 02:07:00 pm Erik Vos wrote:
> >>>> The "existing mechanism" only allows opening hex edges that would
> >>>> otherwise be closed, not the other way around.
> >>>> Of course we can extend (or replace) that mechanism.  I'm just
> >>>> trying to find out if this very minor issue (as JDG correctly
> >>>> points out) is really worth it to create an exception for, also in
> >>>> the light of the uncertainty about what the rules (as cited) really
say.
> >>>>
> >>>> BTW: Q11 is Crewe, not Wolverton.
> >>>>
> >>>> Erik.
> >>>>
> >>>>> From: Stefan Frey [mailto:ste...@we...]
> >>>>>
> >>>>> Could you not lay the half tile on Q11 and block the SW side of
> >>>>> hex tile
> >>>>
> >>>> Q11
> >>>>
> >>>>> using the existing mechanism?
> >>>>>
> >>>>> On Friday, October 28, 2011 10:22:45 pm Erik Vos wrote:
> >>>>>> I'm including these half-tiles into 1825 Unit 1, and it basically
> >>>>>> works. As expected, it turns out, that adding these half-tiles
> >>>>>> makes the existing "open" attributes redundant. This attribute
> >>>>>> achieves the same thing: that track can be laid towards the board
> >>
> >> edge.
> >>
> >>>>>> However, the question arises how to interpret the rule that
> >>>>>> "Tiles may be placed so that a railway terminates against the
> >>>>>> edge of the board or against the side of an incomplete hexag"  in
> >>>>>> some specific cases where laying track would not be allowed if
> >>>>>> the adjacent board was actually present.  For Unit 1, this refers
> >>>>>> to the Q row hexes, of which only the southernmost corner is just
> >>>>>> visible on the Unit1 game board.  If taken literally, the cited
> >>>>>> rule would allow track lays against all edges of the Q row hexes
> >>>>>> if
> >>>
> >>> Unit2/R3 are absent.
> >>>
> >>>>>> However, if both Unit2 and Kit R3 are present, hex Q11
> >>>>>> (Wolverton) would be only reachable from the SE, and hex Q21 (The
> Wash, i.e.
> >>>>>> sea)
> >>>>
> >>>> not
> >>>>
> >>>>> at all.
> >>>>>
> >>>>>> And that is how I had implemented it also for the case that
> >>>>>> Unit2/R3 are absent (I only vaguely remember that we might have
> >>>>>> had some discussion about this issue).
> >>>>>>
> >>>>>> My current preference is to use a half-tile on hex Q11 (to which
> >>>>>> therefore track can be laid from both the SW and SE directions),
> >>>>>> and to omit it on hex Q21 (which therefore cannot be laid any
> >>>>>> track against).  To replicate the current behaviour, I would have
> >>>>>> to omit the half-tile from Q11, and keep using the existing 'open'
> >>>>>> attribute instead, so that Q11 can only be laid track against
> >>>>>> from
> >>
> >> the SE.
> >>
> >>>>>> Any opinions?
> >>>>>>
> >>>>>> Erik.
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> ---
> >>>> -----
> >>>> --- 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
> >>
> >> ---------------------------------------------------------------------
> >> ------
> >> --- 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
> 
>
----------------------------------------------------------------------------
--
> 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] 18TN -- tile problems

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

I have implemented 18TN to the extent that I have committed XML files
received from Scott Petersen, and wrote some required extra code.

The reported tile laying problem is most likely an XML bug.  I will look
into this and some other outstanding problems, but it will take a few more
days.

> Next, I'll do reports on 1870, which still has quite a bit to do.

1870 development has not really started yet. Most of the XML exists, and the
ledge should work, but all other aspects in which 1870 differs from 1830
still haven't been touched yet.

Erik.

Re: [Rails-devel] 18TN -- tile problems

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

On 2011-10-29 07:13, Stefan Frey wrote:
> Erik:
> most likely you have implemented 18TN: Have you looked into this.
> After this got fixed I will release another bug-fix Rails version 1.5.2. soon.
> Stefan

I can't wait!  With Erik's fixes of 10/14, I would say 1835 is now fully playable.

Next, I'll do reports on 1870, which still has quite a bit to do.

Re: [Rails-devel] 1825 half-tiles

[Charles S. <men...@gm...>]

Playing a game of 1830 w/ Coalfields. A company was allowed to buy access to
the coal fields without having the full amount of funds in the treasury.
Instead of showing a popup not allowing it, like it does with tokens & paid
tile lays. This pushed the company's treasury into the negative, which also
had the side effect of not allowing a regular tile lay (which showed a cost
of $0).

Re: [Rails-devel] 1825 half-tiles

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

Hi all,

Maybe a dumb suggestion, but cant we fix it with different submaps for the respective variants and the half tiles ?

Currently you cant define complete maps for variants might that be a way to solve that problem ?

Von meinem iPad gesendet

Am 29.10.2011 um 16:11 schrieb Stefan Frey <ste...@we...>:

> Erik:
> from my point of view it is clear, however I have not checked the rules again. 
> Especially as the 1825 rules are ambiguous in many respect anyway and then the 
> 1825 Unit 1 some rules are different (at least in wording) to those of unit 2 
> and 3.
> 
> So I would not allow running to Q11 and Q21 even if unit 2 and/or R3 are not 
> present: My main reasoning here is that there are visual clues for both the 
> brown edge without track for Q11/SW and the blue/green sea for Q21.
> 
> Thus I suggest to add both Q11 and make the edge impassable. I would even 
> consider adding Q21 and make both edges impassable if this looks better on a 
> whole.
> 
> Stefan
> 
> 
> On Saturday, October 29, 2011 03:45:37 pm Erik Vos wrote:
>> Ah yes, of course we could use that.
>> But the question if we *should* do it has not yet been answered.
>> 
>> Erik.
>> 
>>> -----Original Message-----
>>> From: Stefan Frey [mailto:ste...@we...]
>>> Sent: Saturday, October 29, 2011 2:14 PM
>>> To: Development list for Rails: an 18xx game
>>> Subject: Re: [Rails-devel] 1825 half-tiles
>>> 
>>> I was under the impression that the "impassable" attribute actually does
>>> exactly that. Or is it not possible to use it in the scenario below for a
>> 
>> different
>> 
>>> reason?
>>> Stefan
>>> 
>>> On Saturday, October 29, 2011 02:07:00 pm Erik Vos wrote:
>>>> The "existing mechanism" only allows opening hex edges that would
>>>> otherwise be closed, not the other way around.
>>>> Of course we can extend (or replace) that mechanism.  I'm just trying
>>>> to find out if this very minor issue (as JDG correctly points out) is
>>>> really worth it to create an exception for, also in the light of the
>>>> uncertainty about what the rules (as cited) really say.
>>>> 
>>>> BTW: Q11 is Crewe, not Wolverton.
>>>> 
>>>> Erik.
>>>> 
>>>>> From: Stefan Frey [mailto:ste...@we...]
>>>>> 
>>>>> Could you not lay the half tile on Q11 and block the SW side of hex
>>>>> tile
>>>> 
>>>> Q11
>>>> 
>>>>> using the existing mechanism?
>>>>> 
>>>>> On Friday, October 28, 2011 10:22:45 pm Erik Vos wrote:
>>>>>> I'm including these half-tiles into 1825 Unit 1, and it basically
>>>>>> works. As expected, it turns out, that adding these half-tiles
>>>>>> makes the existing "open" attributes redundant. This attribute
>>>>>> achieves the same thing: that track can be laid towards the board
>> 
>> edge.
>> 
>>>>>> However, the question arises how to interpret the rule that "Tiles
>>>>>> may be placed so that a railway terminates against the edge of the
>>>>>> board or against the side of an incomplete hexag"  in some
>>>>>> specific cases where laying track would not be allowed if the
>>>>>> adjacent board was actually present.  For Unit 1, this refers to
>>>>>> the Q row hexes, of which only the southernmost corner is just
>>>>>> visible on the Unit1 game board.  If taken literally, the cited
>>>>>> rule would allow track lays against all edges of the Q row hexes if
>>> 
>>> Unit2/R3 are absent.
>>> 
>>>>>> However, if both Unit2 and Kit R3 are present, hex Q11 (Wolverton)
>>>>>> would be only reachable from the SE, and hex Q21 (The Wash, i.e.
>>>>>> sea)
>>>> 
>>>> not
>>>> 
>>>>> at all.
>>>>> 
>>>>>> And that is how I had implemented it also for the case that
>>>>>> Unit2/R3 are absent (I only vaguely remember that we might have
>>>>>> had some discussion about this issue).
>>>>>> 
>>>>>> My current preference is to use a half-tile on hex Q11 (to which
>>>>>> therefore track can be laid from both the SW and SE directions),
>>>>>> and to omit it on hex Q21 (which therefore cannot be laid any
>>>>>> track against).  To replicate the current behaviour, I would have
>>>>>> to omit the half-tile from Q11, and keep using the existing 'open'
>>>>>> attribute instead, so that Q11 can only be laid track against from
>> 
>> the SE.
>> 
>>>>>> Any opinions?
>>>>>> 
>>>>>> Erik.
>>>> 
>>>> ----------------------------------------------------------------------
>>>> -----
>>>> --- 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
>> 
>> ---------------------------------------------------------------------------
>> --- 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] 18TN -- tile problems

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

Erik:
most likely you have implemented 18TN: Have you looked into this.
After this got fixed I will release another bug-fix Rails version 1.5.2. soon.
Stefan

On Friday, October 28, 2011 04:20:32 pm Rick Westerman wrote:
> My gaming buddy and I are just finishing our first game of 18TN.  We notice
> that the grey tile (#600) can not be laid; it is an upgrade from tile
> #170.  Also tile #170 is showing 168 available tiles with 2 on the board.
> 
> 
> -- Rick
> 
> ---------------------------------------------------------------------------
> --- The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1825 half-tiles

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

Erik:
from my point of view it is clear, however I have not checked the rules again. 
Especially as the 1825 rules are ambiguous in many respect anyway and then the 
1825 Unit 1 some rules are different (at least in wording) to those of unit 2 
and 3.

So I would not allow running to Q11 and Q21 even if unit 2 and/or R3 are not 
present: My main reasoning here is that there are visual clues for both the 
brown edge without track for Q11/SW and the blue/green sea for Q21.

Thus I suggest to add both Q11 and make the edge impassable. I would even 
consider adding Q21 and make both edges impassable if this looks better on a 
whole.

Stefan


On Saturday, October 29, 2011 03:45:37 pm Erik Vos wrote:
> Ah yes, of course we could use that.
> But the question if we *should* do it has not yet been answered.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Saturday, October 29, 2011 2:14 PM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 1825 half-tiles
> > 
> > I was under the impression that the "impassable" attribute actually does
> > exactly that. Or is it not possible to use it in the scenario below for a
> 
> different
> 
> > reason?
> > Stefan
> > 
> > On Saturday, October 29, 2011 02:07:00 pm Erik Vos wrote:
> > > The "existing mechanism" only allows opening hex edges that would
> > > otherwise be closed, not the other way around.
> > > Of course we can extend (or replace) that mechanism.  I'm just trying
> > > to find out if this very minor issue (as JDG correctly points out) is
> > > really worth it to create an exception for, also in the light of the
> > > uncertainty about what the rules (as cited) really say.
> > > 
> > > BTW: Q11 is Crewe, not Wolverton.
> > > 
> > > Erik.
> > > 
> > > > From: Stefan Frey [mailto:ste...@we...]
> > > > 
> > > > Could you not lay the half tile on Q11 and block the SW side of hex
> > > > tile
> > > 
> > > Q11
> > > 
> > > > using the existing mechanism?
> > > > 
> > > > On Friday, October 28, 2011 10:22:45 pm Erik Vos wrote:
> > > > > I'm including these half-tiles into 1825 Unit 1, and it basically
> > > > > works. As expected, it turns out, that adding these half-tiles
> > > > > makes the existing "open" attributes redundant. This attribute
> > > > > achieves the same thing: that track can be laid towards the board
> 
> edge.
> 
> > > > > However, the question arises how to interpret the rule that "Tiles
> > > > > may be placed so that a railway terminates against the edge of the
> > > > > board or against the side of an incomplete hexag"  in some
> > > > > specific cases where laying track would not be allowed if the
> > > > > adjacent board was actually present.  For Unit 1, this refers to
> > > > > the Q row hexes, of which only the southernmost corner is just
> > > > > visible on the Unit1 game board.  If taken literally, the cited
> > > > > rule would allow track lays against all edges of the Q row hexes if
> > 
> > Unit2/R3 are absent.
> > 
> > > > > However, if both Unit2 and Kit R3 are present, hex Q11 (Wolverton)
> > > > > would be only reachable from the SE, and hex Q21 (The Wash, i.e.
> > > > > sea)
> > > 
> > > not
> > > 
> > > > at all.
> > > > 
> > > > > And that is how I had implemented it also for the case that
> > > > > Unit2/R3 are absent (I only vaguely remember that we might have
> > > > > had some discussion about this issue).
> > > > > 
> > > > > My current preference is to use a half-tile on hex Q11 (to which
> > > > > therefore track can be laid from both the SW and SE directions),
> > > > > and to omit it on hex Q21 (which therefore cannot be laid any
> > > > > track against).  To replicate the current behaviour, I would have
> > > > > to omit the half-tile from Q11, and keep using the existing 'open'
> > > > > attribute instead, so that Q11 can only be laid track against from
> 
> the SE.
> 
> > > > > Any opinions?
> > > > > 
> > > > > Erik.
> > > 
> > > ----------------------------------------------------------------------
> > > -----
> > > --- Get your Android app more play: Bring it to the BlackBerry
> > > PlayBook in minutes. BlackBerry App World™ now supports
> > > Android™ Apps for the BlackBerry® PlayBook™. 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™ now supports Android™ Apps for
> > the BlackBerry® PlayBook™. 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™ now supports Android™ Apps for
> the BlackBerry® PlayBook™. 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] Problem with Revenue Calculation

[Bob P. <bob...@gm...>]

Thank you all for your continued help.  A little sleep brought some clarity.
 And things do seem to be working as intended.

I do have a 18xx.log file!  It's being created a couple directories up from
my install directory "/home/bobprobst" instead of
"/home/bobprobst/Apps/rails-1.5.1".  Can anyone tell me how to change its
save location?

I'm afraid I preemptively acted before considering the implications to
debugging the problem.  I looked in my 18xx.log file and did not see and
entry for RevenueCalculation.  That's when I deleted all of the rails
related files in my home directory.

I fired up a new version of rails and calculations worked correctly!  I'm
quite certain I tried this a few times yesterday and it did not work.

However, when I loaded my current game, it was not working.  I looked at the
18xx.log file and saw that the person who started it had disabled those
options.  Problem solved!

Still curious why I was having problems with new games last night, I tried
starting another game to see if the setting in one could influence another.
 I could not reproduce the problem!

I wonder now, if deleting the rails files in my home directory (some from
older versions of rails no doubt) fixed some conflict that was taking place.

Or maybe it's a case of IAK.

Thanks anyway for the time you spent addressing my non-problem problem.
 Sorry for any trouble.

On Sat, Oct 29, 2011 at 1:10 AM, Stefan Frey <ste...@we...> wrote:

> Both of you are correct: Revenue Calculation does not and will never have
> an
> effect on the payout decision. However it has three effects:
> A) Show the calculation results in the info-panel.
> B) Change the revenue field to the suggested result.
> C) Show the paths run
>
> As neither occurs it is either possible that revenue calculation is
> switched
> off or stopped because of an error (unlikely given the setting).
>
> The easiest way to decide that is that Bob please send either a save game
> file
> of that situation to the list or try to start a new game and make sure that
> you have set the revenue calculation to suggest. Sending the 18xx.log would
> have worked too, but that seems not possible.
>
> The 18xx.log file is created in the current working directory that is set
> at
> the start of Rails (I do not know exactly where this is by default on a
> windows os - others might be able to help here).
>
> On Saturday, October 29, 2011 06:32:50 am Chris Shaffer wrote:
> > But the suggested earnings shouldn't be zero, and you can see thee isn't
> a
> > colorful track display.
> >
> > --
> > Chris
> >
> > Please consider the environment before printing this e-mail.
> >
> >
> > On Fri, Oct 28, 2011 at 5:44 PM, John David Galt <
> >
> > jd...@di...> wrote:
> > > On 2011-10-28 16:08, Bob Probst wrote:
> > > > If you see the attached screenshot, you'll see that B&O has 2 trains
> > > > and
> > >
> > > legal runs but the Maps panel shows Revenue set to $0 and the Payout
> > > reads "No Trains".
> > >
> > > The payout *should* read "No train" (assuming that's what it was last
> > > round)
> > > until you click "Pay Out" or "Withhold" for the current turn.
> > >
> > >
> > >
> -------------------------------------------------------------------------
> > > ----- 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] 1825 half-tiles

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

Ah yes, of course we could use that.
But the question if we *should* do it has not yet been answered.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday, October 29, 2011 2:14 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 half-tiles
> 
> I was under the impression that the "impassable" attribute actually does
> exactly that. Or is it not possible to use it in the scenario below for a
different
> reason?
> Stefan
> 
> On Saturday, October 29, 2011 02:07:00 pm Erik Vos wrote:
> > The "existing mechanism" only allows opening hex edges that would
> > otherwise be closed, not the other way around.
> > Of course we can extend (or replace) that mechanism.  I'm just trying
> > to find out if this very minor issue (as JDG correctly points out) is
> > really worth it to create an exception for, also in the light of the
> > uncertainty about what the rules (as cited) really say.
> >
> > BTW: Q11 is Crewe, not Wolverton.
> >
> > Erik.
> >
> > > From: Stefan Frey [mailto:ste...@we...]
> > >
> > > Could you not lay the half tile on Q11 and block the SW side of hex
> > > tile
> >
> > Q11
> >
> > > using the existing mechanism?
> > >
> > > On Friday, October 28, 2011 10:22:45 pm Erik Vos wrote:
> > > > I'm including these half-tiles into 1825 Unit 1, and it basically
> > > > works. As expected, it turns out, that adding these half-tiles
> > > > makes the existing "open" attributes redundant. This attribute
> > > > achieves the same thing: that track can be laid towards the board
edge.
> > > >
> > > > However, the question arises how to interpret the rule that "Tiles
> > > > may be placed so that a railway terminates against the edge of the
> > > > board or against the side of an incomplete hexag"  in some
> > > > specific cases where laying track would not be allowed if the
> > > > adjacent board was actually present.  For Unit 1, this refers to
> > > > the Q row hexes, of which only the southernmost corner is just
> > > > visible on the Unit1 game board.  If taken literally, the cited
> > > > rule would allow track lays against all edges of the Q row hexes if
> Unit2/R3 are absent.
> > > >
> > > > However, if both Unit2 and Kit R3 are present, hex Q11 (Wolverton)
> > > > would be only reachable from the SE, and hex Q21 (The Wash, i.e.
> > > > sea)
> >
> > not
> >
> > > at all.
> > >
> > > > And that is how I had implemented it also for the case that
> > > > Unit2/R3 are absent (I only vaguely remember that we might have
> > > > had some discussion about this issue).
> > > >
> > > > My current preference is to use a half-tile on hex Q11 (to which
> > > > therefore track can be laid from both the SW and SE directions),
> > > > and to omit it on hex Q21 (which therefore cannot be laid any
> > > > track against).  To replicate the current behaviour, I would have
> > > > to omit the half-tile from Q11, and keep using the existing 'open'
> > > > attribute instead, so that Q11 can only be laid track against from
the SE.
> > > >
> > > > Any opinions?
> > > >
> > > > Erik.
> >
> > ----------------------------------------------------------------------
> > -----
> > --- Get your Android app more play: Bring it to the BlackBerry
> > PlayBook in minutes. BlackBerry App World™ now supports
> > Android™ Apps for the BlackBerry® PlayBook™. 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™ now supports Android™ Apps for
> the BlackBerry® PlayBook™. 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] Problem with Revenue Calculation

[Rick W. <wes...@pu...>]

Apologies to the rest of you for the large msg.

 Hi Bob.  I went to bed before getting your request last night.

Enclosed are 3 screen shots plus the 18xx.log.  Picture 'Directory' shows my rails folder before and after starting a 1830 game.  Note that the 18xx.log is created.





Second is starting up the game.  Note that I choose the 'suggest' option for revenue calculation.





Third is the game.  For this test game I only started up the B&O.  Note that the route calculation is being suggested.





Lastly the full 18xx.log is enclosed.





On Oct 28, 2011, at 10:30 PM, Bob Probst wrote:

> Thanks Rick.  I don't have that file in 1.4.2 or 1.5.1 then.  Could you send me yours and I'll see if that makes a difference?  
> 
> I noticed that i have a file, my.properties with the lines:
> 
> # Log file properties
> log4j.appender.F.File=18xx.log
> log4j.appender.F.append=false
> 
> but no 18xx.log anywhere.
> 
> On Fri, Oct 28, 2011 at 10:24 PM, Rick Westerman <wes...@pu...> wrote:
> 
> On Oct 28, 2011, at 9:36 PM, Bob Probst wrote:
> 
>> Sorry if I'm not replying to the list correctly.
>> 
>> 
>> 
>> I don't have a 18xx.log file.  
>> 
>> 
>> At least not that I can find.  Where would I expect to find it?
> 
> My 18xx.log file is located in the same directory as my jar file and the rails.sh file.
> 
> No matter what the XML files inside the jar say, it is what option you chose when you started the game that matters.  The 18xx.log file might say something in this regard.
> 
>> 
>> I found a couple XML files packaged in the jar files that have a setting like that.  One, Games.xml was set with this option deactivated but it came 
>> with a notice that the file wasn't used.  The file it referenced (GamesList.xml) had the values set to Highlight and Suggest.
>> 
>> 		<!-- The options in Game.xml are not currently used.
>> 			 See GamesList.xml for the real ones.
>> 		--> 
>> 
>> 		<GameOption name="RouteAwareness" values="Highlight,Deactivate" default="Deactivate" />
>> 		<GameOption name="RevenueCalculation" values="Suggest,Deactivate" default="Deactivate" />
>> ------------------------------------------------------------------------------
>> 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
> 
> 
> ------------------------------------------------------------------------------
> 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] 1825 half-tiles

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

I was under the impression that the "impassable" attribute actually does 
exactly that. Or is it not possible to use it in the scenario below for a 
different reason?
Stefan

On Saturday, October 29, 2011 02:07:00 pm Erik Vos wrote:
> The "existing mechanism" only allows opening hex edges that would otherwise
> be closed, not the other way around.
> Of course we can extend (or replace) that mechanism.  I'm just trying to
> find out if this very minor issue (as JDG correctly points out) is really
> worth it to create an exception for, also in the light of the uncertainty
> about what the rules (as cited) really say.
> 
> BTW: Q11 is Crewe, not Wolverton.
> 
> Erik.
> 
> > From: Stefan Frey [mailto:ste...@we...]
> > 
> > Could you not lay the half tile on Q11 and block the SW side of hex tile
> 
> Q11
> 
> > using the existing mechanism?
> > 
> > On Friday, October 28, 2011 10:22:45 pm Erik Vos wrote:
> > > I'm including these half-tiles into 1825 Unit 1, and it basically
> > > works. As expected, it turns out, that adding these half-tiles makes
> > > the existing "open" attributes redundant. This attribute achieves the
> > > same thing: that track can be laid towards the board edge.
> > > 
> > > However, the question arises how to interpret the rule that "Tiles may
> > > be placed so that a railway terminates against the edge of the board
> > > or against the side of an incomplete hexag"  in some specific cases
> > > where laying track would not be allowed if the adjacent board was
> > > actually present.  For Unit 1, this refers to the Q row hexes, of
> > > which only the southernmost corner is just visible on the Unit1 game
> > > board.  If taken literally, the cited rule would allow track lays
> > > against all edges of the Q row hexes if Unit2/R3 are absent.
> > > 
> > > However, if both Unit2 and Kit R3 are present, hex Q11 (Wolverton)
> > > would be only reachable from the SE, and hex Q21 (The Wash, i.e. sea)
> 
> not
> 
> > at all.
> > 
> > > And that is how I had implemented it also for the case that Unit2/R3
> > > are absent (I only vaguely remember that we might have had some
> > > discussion about this issue).
> > > 
> > > My current preference is to use a half-tile on hex Q11 (to which
> > > therefore track can be laid from both the SW and SE directions), and
> > > to omit it on hex Q21 (which therefore cannot be laid any track
> > > against).  To replicate the current behaviour, I would have to omit
> > > the half-tile from Q11, and keep using the existing 'open' attribute
> > > instead, so that Q11 can only be laid track against from the SE.
> > > 
> > > Any opinions?
> > > 
> > > Erik.
> 
> ---------------------------------------------------------------------------
> --- Get your Android app more play: Bring it to the BlackBerry PlayBook in
> minutes. BlackBerry App World™ now supports Android™ Apps for
> the BlackBerry® PlayBook™. 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] 1825 half-tiles

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

The "existing mechanism" only allows opening hex edges that would otherwise
be closed, not the other way around.
Of course we can extend (or replace) that mechanism.  I'm just trying to
find out if this very minor issue (as JDG correctly points out) is really
worth it to create an exception for, also in the light of the uncertainty
about what the rules (as cited) really say.

BTW: Q11 is Crewe, not Wolverton.  

Erik.


> From: Stefan Frey [mailto:ste...@we...]
> 
> Could you not lay the half tile on Q11 and block the SW side of hex tile
Q11
> using the existing mechanism?
> 
> On Friday, October 28, 2011 10:22:45 pm Erik Vos wrote:
> > I'm including these half-tiles into 1825 Unit 1, and it basically works.
> > As expected, it turns out, that adding these half-tiles makes the
> > existing "open" attributes redundant. This attribute achieves the same
> > thing: that track can be laid towards the board edge.
> >
> > However, the question arises how to interpret the rule that "Tiles may
> > be placed so that a railway terminates against the edge of the board
> > or against the side of an incomplete hexag"  in some specific cases
> > where laying track would not be allowed if the adjacent board was
> > actually present.  For Unit 1, this refers to the Q row hexes, of
> > which only the southernmost corner is just visible on the Unit1 game
> > board.  If taken literally, the cited rule would allow track lays
> > against all edges of the Q row hexes if Unit2/R3 are absent.
> >
> > However, if both Unit2 and Kit R3 are present, hex Q11 (Wolverton)
> > would be only reachable from the SE, and hex Q21 (The Wash, i.e. sea)
not
> at all.
> > And that is how I had implemented it also for the case that Unit2/R3
> > are absent (I only vaguely remember that we might have had some
> > discussion about this issue).
> >
> > My current preference is to use a half-tile on hex Q11 (to which
> > therefore track can be laid from both the SW and SE directions), and
> > to omit it on hex Q21 (which therefore cannot be laid any track
> > against).  To replicate the current behaviour, I would have to omit
> > the half-tile from Q11, and keep using the existing 'open' attribute
> > instead, so that Q11 can only be laid track against from the SE.
> >
> > Any opinions?
> >
> > Erik.

Re: [Rails-devel] Problem with Revenue Calculation

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

Both of you are correct: Revenue Calculation does not and will never have an 
effect on the payout decision. However it has three effects:
A) Show the calculation results in the info-panel.
B) Change the revenue field to the suggested result.
C) Show the paths run

As neither occurs it is either possible that revenue calculation is switched 
off or stopped because of an error (unlikely given the setting).

The easiest way to decide that is that Bob please send either a save game file 
of that situation to the list or try to start a new game and make sure that 
you have set the revenue calculation to suggest. Sending the 18xx.log would 
have worked too, but that seems not possible.

The 18xx.log file is created in the current working directory that is set at 
the start of Rails (I do not know exactly where this is by default on a 
windows os - others might be able to help here).

On Saturday, October 29, 2011 06:32:50 am Chris Shaffer wrote:
> But the suggested earnings shouldn't be zero, and you can see thee isn't a
> colorful track display.
> 
> --
> Chris
> 
> Please consider the environment before printing this e-mail.
> 
> 
> On Fri, Oct 28, 2011 at 5:44 PM, John David Galt <
> 
> jd...@di...> wrote:
> > On 2011-10-28 16:08, Bob Probst wrote:
> > > If you see the attached screenshot, you'll see that B&O has 2 trains
> > > and
> > 
> > legal runs but the Maps panel shows Revenue set to $0 and the Payout
> > reads "No Trains".
> > 
> > The payout *should* read "No train" (assuming that's what it was last
> > round)
> > until you click "Pay Out" or "Withhold" for the current turn.
> > 
> > 
> > -------------------------------------------------------------------------
> > ----- 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] 1825 half-tiles

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

Could you not lay the half tile on Q11 and block the SW side
of hex tile Q11 using the existing mechanism?

On Friday, October 28, 2011 10:22:45 pm Erik Vos wrote:
> I'm including these half-tiles into 1825 Unit 1, and it basically works.
> As expected, it turns out, that adding these half-tiles makes the existing
> "open" attributes redundant. This attribute achieves the same thing: that
> track can be laid towards the board edge.
> 
> However, the question arises how to interpret the rule that "Tiles may be
> placed so that a railway terminates against the edge of the board or
> against the side of an incomplete hexag"  in some specific cases where
> laying track would not be allowed if the adjacent board was actually
> present.  For Unit 1, this refers to the Q row hexes, of which only the
> southernmost corner is just visible on the Unit1 game board.  If taken
> literally, the cited rule would allow track lays against all edges of the
> Q row hexes if Unit2/R3 are absent.
> 
> However, if both Unit2 and Kit R3 are present, hex Q11 (Wolverton) would be
> only reachable from the SE, and hex Q21 (The Wash, i.e. sea) not at all.
> And that is how I had implemented it also for the case that Unit2/R3 are
> absent (I only vaguely remember that we might have had some discussion
> about this issue).
> 
> My current preference is to use a half-tile on hex Q11 (to which therefore
> track can be laid from both the SW and SE directions), and to omit it on
> hex Q21 (which therefore cannot be laid any track against).  To replicate
> the current behaviour, I would have to omit the half-tile from Q11, and
> keep using the existing 'open' attribute instead, so that Q11 can only be
> laid track against from the SE.
> 
> Any opinions?
> 
> Erik.
> 
> > -----Original Message-----
> > From: Erik Vos [mailto:eri...@xs...]
> > Sent: Friday, October 28, 2011 12:52 PM
> > To: 'Development list for Rails: an 18xx game'
> > Subject: Re: [Rails-devel] 1825 half-tiles
> > 
> > Thanks, Stefan. As you say, a visual cue might be helpful.
> > 
> > There hasn't been any significant development on 1825 after I created the
> > maps.  Most of the XML (except for Unit 1) still has to be done.
> > I did already prepare that to some extent by adding quantity increments
> > as
> 
> a
> 
> > configuration option.
> > 
> > Erik.
> > 
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > > Sent: Friday, October 28, 2011 10:39 AM
> > > To: 'Development list for Rails: an 18xx game'
> > > Subject: [Rails-devel] 1825 half-tiles
> > > 
> > > Actually I found this mail sitting in my draft folder.
> > > It intended to provide half hexes for 1825.
> > > I do not know if this is still required, I lost track on the progress
> > > of
> > 
> > 1825 lately
> > 
> > > (if there has been any).
> > > Stefan
> > > 
> > > 
> > > Some time ago I edited the SVG files of the empty hex to create the
> > > half
> > 
> > hex,
> > 
> > > but forgot to send them out. I know that the current support of 1825
> > 
> > already
> > 
> > > allows to lay track off the map, but there is no visual hint, where
> > > this
> > 
> > is
> > 
> > > possible. So I wonder if they could be added.
> > > My experience now that for small changes it is actually much easier to
> > 
> > edit
> > 
> > > the SVG directly than using Inkscape (the edit took hardly more time
> > > than writing this mail)
> 
> ---------------------------------------------------------------------------
> - --
> 
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Cisco Self-Assessment and learn about
> > Cisco certifications, training, and career opportunities.
> > http://p.sf.net/sfu/cisco-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Problem with Revenue Calculation

[Chris S. <chr...@gm...>]

But the suggested earnings shouldn't be zero, and you can see thee isn't a
colorful track display.

--
Chris

Please consider the environment before printing this e-mail.


On Fri, Oct 28, 2011 at 5:44 PM, John David Galt <
jd...@di...> wrote:

> On 2011-10-28 16:08, Bob Probst wrote:
> > If you see the attached screenshot, you'll see that B&O has 2 trains and
> legal runs but the Maps panel shows Revenue set to $0 and the Payout reads
> "No Trains".
>
> The payout *should* read "No train" (assuming that's what it was last
> round)
> until you click "Pay Out" or "Withhold" for the current turn.
>
>
> ------------------------------------------------------------------------------
> 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] Problem with Revenue Calculation

[Bob P. <bob...@gm...>]

Thanks Rick.  I don't have that file in 1.4.2 or 1.5.1 then.  Could you send
me yours and I'll see if that makes a difference?

I noticed that i have a file, my.properties with the lines:

# Log file properties
log4j.appender.F.File=18xx.log
log4j.appender.F.append=false

but no 18xx.log anywhere.

On Fri, Oct 28, 2011 at 10:24 PM, Rick Westerman <wes...@pu...>wrote:

>
> On Oct 28, 2011, at 9:36 PM, Bob Probst wrote:
>
> Sorry if I'm not replying to the list correctly.
>
> I don't have a 18xx.log file.
>
> At least not that I can find. Where would I expect to find it?
>
>
> My 18xx.log file is located in the same directory as my jar file and the
> rails.sh file.
>
> No matter what the XML files inside the jar say, it is what option you
> chose when you started the game that matters.  The 18xx.log file might say
> something in this regard.
>
>
> I found a couple XML files packaged in the jar files that have a setting
> like that. One, Games.xml was set with this option deactivated but it came
> with a notice that the file wasn't used. The file it referenced
> (GamesList.xml) had the values set to Highlight and Suggest.
>
> <!-- The options in Game.xml are not currently used. See GamesList.xml for
> the real ones. --> <GameOption name="RouteAwareness"
> values="Highlight,Deactivate" default="Deactivate" /> <GameOption
> name="RevenueCalculation" values="Suggest,Deactivate" default="Deactivate"
> />
>
> ------------------------------------------------------------------------------
> 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] Problem with Revenue Calculation

[Rick W. <wes...@pu...>]

On Oct 28, 2011, at 9:36 PM, Bob Probst wrote:

> Sorry if I'm not replying to the list correctly.
> 
> 
> I don't have a 18xx.log file.  
> 
> 
> At least not that I can find.  Where would I expect to find it?

My 18xx.log file is located in the same directory as my jar file and the rails.sh file.

No matter what the XML files inside the jar say, it is what option you chose when you started the game that matters.  The 18xx.log file might say something in this regard.

> 
> I found a couple XML files packaged in the jar files that have a setting like that.  One, Games.xml was set with this option deactivated but it came 
> with a notice that the file wasn't used.  The file it referenced (GamesList.xml) had the values set to Highlight and Suggest.
> 
> 		<!-- The options in Game.xml are not currently used.
> 			 See GamesList.xml for the real ones.
> 		--> 
> 
> 		<GameOption name="RouteAwareness" values="Highlight,Deactivate" default="Deactivate" />
> 		<GameOption name="RevenueCalculation" values="Suggest,Deactivate" default="Deactivate" />
> ------------------------------------------------------------------------------
> 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

[Rails-devel] Problem with Revenue Calculation

[Bob P. <bob...@gm...>]

Sorry if I'm not replying to the list correctly.

I don't have a 18xx.log file.

At least not that I can find. Where would I expect to find it?

I found a couple XML files packaged in the jar files that have a setting
like that. One, Games.xml was set with this option deactivated but it came
with a notice that the file wasn't used. The file it referenced
(GamesList.xml) had the values set to Highlight and Suggest.

<!-- The options in Game.xml are not currently used. See GamesList.xml for
the real ones. --> <GameOption name="RouteAwareness"
values="Highlight,Deactivate" default="Deactivate" /> <GameOption
name="RevenueCalculation" values="Suggest,Deactivate" default="Deactivate"
/>