rails-devel — List for discussion of Rails development

Re: [Rails-devel] 1830: Exchange option not offered

[Steve U. <ste...@gm...>]

Actually, I can't find the bug I filed last night.  Unless there's some
delay in bug postings showing up, it must have gone into the bit-bucket.

Steve Undy
st...@ro...


On Thu, Apr 29, 2010 at 8:54 AM, Phil Davies <de...@gm...> wrote:

> That will teach me to check the bug reports before mailing the list :p
>
> On 29 April 2010 15:51, Steve Undy <ste...@gm...> wrote:
> > I filed a bug report last night with another save file that also shows
> this
> > problem.
> >
> > Steve Undy
> > st...@ro...
> >
> >
> > On Thu, Apr 29, 2010 at 2:40 AM, Phil Davies <de...@gm...> wrote:
> >>
> >> It looks like the fix to the trading of second Diesels onwards doesn't
> >> quite work correctly in saved games.  See attached save file (load it
> >> up in rails 1.2.2 - it won't work against current CVS build), on B&O's
> >> last operating turn:
> >>
> >> B&O (Steve) operates.
> >> B&O lays tile #8 at hex I13/SE
> >> B&O earns $200
> >> B&O withholds dividend of $200.
> >> B&O price goes from $142(J1) to $126(I1).
> >> B&O buys a D-train from IPO for $800.
> >>
> >> Key problem being the last line.  When played through, this was an
> >> exchange of the 5 that the B&O currently has, on loading the save
> >> file, it considers the trade to be a purchase, now B&O still has the 5
> >> instead of the 5 being in the pool for purchase.
> >>
> >> Phil
> >>
> >> On 4 February 2010 23:19, Erik Vos <eri...@xs...> wrote:
> >> > Hmm, I had always thought that only the first Diesel could be
> exchanged
> >> > for
> >> > a lesser train, but after rereading the rules I must conclude that I
> was
> >> > misguided. So all Diesels are now available by exchange.
> >> >
> >> > Erik.
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: Phil Davies [mailto:de...@gm...]
> >> > Sent: Thursday 04 February 2010 13:17
> >> > To: Development list for Rails: an 18xx game
> >> > Subject: [Rails-devel] 1830: Exchange option not offered
> >> >
> >> > See the saved game file.  PRR to run, it just bought the 5 train off
> >> > NYC, it should be able to exchange that for a D for $800, yet it isn't
> >> > given the option to do so.  I've tested this on both 1.1.3 and 1.1.2
> >> > and it seems to be an issue in both vesions
> >> >
> >> > Phil
> >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > The Planet: dedicated and managed hosting, cloud storage, colocation
> >> > Stay online with enterprise data centers and the best network in the
> >> > business
> >> > Choose flexible plans and management services without long-term
> >> > contracts
> >> > Personal 24x7 support from experience hosting pros just a phone call
> >> > away.
> >> > http://p.sf.net/sfu/theplanet-com
> >> > _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
>

Re: [Rails-devel] 1830: Exchange option not offered

[Phil D. <de...@gm...>]

That will teach me to check the bug reports before mailing the list :p

On 29 April 2010 15:51, Steve Undy <ste...@gm...> wrote:
> I filed a bug report last night with another save file that also shows this
> problem.
>
> Steve Undy
> st...@ro...
>
>
> On Thu, Apr 29, 2010 at 2:40 AM, Phil Davies <de...@gm...> wrote:
>>
>> It looks like the fix to the trading of second Diesels onwards doesn't
>> quite work correctly in saved games.  See attached save file (load it
>> up in rails 1.2.2 - it won't work against current CVS build), on B&O's
>> last operating turn:
>>
>> B&O (Steve) operates.
>> B&O lays tile #8 at hex I13/SE
>> B&O earns $200
>> B&O withholds dividend of $200.
>> B&O price goes from $142(J1) to $126(I1).
>> B&O buys a D-train from IPO for $800.
>>
>> Key problem being the last line.  When played through, this was an
>> exchange of the 5 that the B&O currently has, on loading the save
>> file, it considers the trade to be a purchase, now B&O still has the 5
>> instead of the 5 being in the pool for purchase.
>>
>> Phil
>>
>> On 4 February 2010 23:19, Erik Vos <eri...@xs...> wrote:
>> > Hmm, I had always thought that only the first Diesel could be exchanged
>> > for
>> > a lesser train, but after rereading the rules I must conclude that I was
>> > misguided. So all Diesels are now available by exchange.
>> >
>> > Erik.
>> >
>> >
>> > -----Original Message-----
>> > From: Phil Davies [mailto:de...@gm...]
>> > Sent: Thursday 04 February 2010 13:17
>> > To: Development list for Rails: an 18xx game
>> > Subject: [Rails-devel] 1830: Exchange option not offered
>> >
>> > See the saved game file.  PRR to run, it just bought the 5 train off
>> > NYC, it should be able to exchange that for a D for $800, yet it isn't
>> > given the option to do so.  I've tested this on both 1.1.3 and 1.1.2
>> > and it seems to be an issue in both vesions
>> >
>> > Phil
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > The Planet: dedicated and managed hosting, cloud storage, colocation
>> > Stay online with enterprise data centers and the best network in the
>> > business
>> > Choose flexible plans and management services without long-term
>> > contracts
>> > Personal 24x7 support from experience hosting pros just a phone call
>> > away.
>> > http://p.sf.net/sfu/theplanet-com
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] 1830: Exchange option not offered

[Steve U. <ste...@gm...>]

I filed a bug report last night with another save file that also shows this
problem.

Steve Undy
st...@ro...


On Thu, Apr 29, 2010 at 2:40 AM, Phil Davies <de...@gm...> wrote:

> It looks like the fix to the trading of second Diesels onwards doesn't
> quite work correctly in saved games.  See attached save file (load it
> up in rails 1.2.2 - it won't work against current CVS build), on B&O's
> last operating turn:
>
> B&O (Steve) operates.
> B&O lays tile #8 at hex I13/SE
> B&O earns $200
> B&O withholds dividend of $200.
> B&O price goes from $142(J1) to $126(I1).
> B&O buys a D-train from IPO for $800.
>
> Key problem being the last line.  When played through, this was an
> exchange of the 5 that the B&O currently has, on loading the save
> file, it considers the trade to be a purchase, now B&O still has the 5
> instead of the 5 being in the pool for purchase.
>
> Phil
>
> On 4 February 2010 23:19, Erik Vos <eri...@xs...> wrote:
> > Hmm, I had always thought that only the first Diesel could be exchanged
> for
> > a lesser train, but after rereading the rules I must conclude that I was
> > misguided. So all Diesels are now available by exchange.
> >
> > Erik.
> >
> >
> > -----Original Message-----
> > From: Phil Davies [mailto:de...@gm...]
> > Sent: Thursday 04 February 2010 13:17
> > To: Development list for Rails: an 18xx game
> > Subject: [Rails-devel] 1830: Exchange option not offered
> >
> > See the saved game file.  PRR to run, it just bought the 5 train off
> > NYC, it should be able to exchange that for a D for $800, yet it isn't
> > given the option to do so.  I've tested this on both 1.1.3 and 1.1.2
> > and it seems to be an issue in both vesions
> >
> > Phil
> >
> >
> >
> ------------------------------------------------------------------------------
> > The Planet: dedicated and managed hosting, cloud storage, colocation
> > Stay online with enterprise data centers and the best network in the
> business
> > Choose flexible plans and management services without long-term contracts
> > Personal 24x7 support from experience hosting pros just a phone call
> away.
> > http://p.sf.net/sfu/theplanet-com
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] 1830: Exchange option not offered

[Phil D. <de...@gm...>]

It looks like the fix to the trading of second Diesels onwards doesn't
quite work correctly in saved games.  See attached save file (load it
up in rails 1.2.2 - it won't work against current CVS build), on B&O's
last operating turn:

B&O (Steve) operates.
B&O lays tile #8 at hex I13/SE
B&O earns $200
B&O withholds dividend of $200.
B&O price goes from $142(J1) to $126(I1).
B&O buys a D-train from IPO for $800.

Key problem being the last line.  When played through, this was an
exchange of the 5 that the B&O currently has, on loading the save
file, it considers the trade to be a purchase, now B&O still has the 5
instead of the 5 being in the pool for purchase.

Phil

On 4 February 2010 23:19, Erik Vos <eri...@xs...> wrote:
> Hmm, I had always thought that only the first Diesel could be exchanged for
> a lesser train, but after rereading the rules I must conclude that I was
> misguided. So all Diesels are now available by exchange.
>
> Erik.
>
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Thursday 04 February 2010 13:17
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] 1830: Exchange option not offered
>
> See the saved game file.  PRR to run, it just bought the 5 train off
> NYC, it should be able to exchange that for a D for $800, yet it isn't
> given the option to do so.  I've tested this on both 1.1.3 and 1.1.2
> and it seems to be an issue in both vesions
>
> Phil
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Implementation details for revenue calculation

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

 
Would it help if I changed the tile description in Tiles.xml accordingly?
(i.e. as you say: "a non-tokenable station in the middle of the hex") 

Erik. 

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Wednesday 28 April 2010 00:37
To: Development list for Rails: an 18xx game
Subject: [Rails-devel] Implementation details for revenue calculation

4) 18EU

Hamburg: I have to admit that I do not like the Hamburg offboard tile: The 
graphical representation does not define exactly, where the value vertex is,

as it does not contain any type of station.
I assume the most natural interpretation is to assume a non-tokenable
station 
in the middle of the hex (similar to tile 12, only that the slot cannot be 
filled). To work with the offboard bonuses, an additional vertex is
connected 
to the station vertex, which acts as a sink (has no neighbors defined, thus 
similar to a tokened out station). All of the bonus combinations for Hamburg

use that vertex to enforce the restriction that the bonus runs have to stop 
in Hamburg. (D)

Re: [Rails-devel] Implementation details for revenue calculation

[Phil D. <de...@gm...>]

On 27 April 2010 23:37, Stefan Frey (web.de) <ste...@we...> wrote:
> Hamburg: I have to admit that I do not like the Hamburg offboard tile: The
> graphical representation does not define exactly, where the value vertex is,
> as it does not contain any type of station.
> I assume the most natural interpretation is to assume a non-tokenable station
> in the middle of the hex (similar to tile 12, only that the slot cannot be
> filled). To work with the offboard bonuses, an additional vertex is connected
> to the station vertex, which acts as a sink (has no neighbors defined, thus
> similar to a tokened out station). All of the bonus combinations for Hamburg
> use that vertex to enforce the restriction that the bonus runs have to stop
> in Hamburg. (D)

Note that 1856 has the Goderich tile which is the same as Hamburg, I
see no reason why this logic should hold up for that as well but it's
worth bearing in mind.  EU of course has the added complication that
if Hamburg starts or ends a run it can be part of the red-red bonus
but again I don't think that causes too many issues

> Pullman: If I understand the 18EU rules correctly, the Pullman is an exception
> to the second sentence under 4.4.3: "... must calculate the maximum possible
> earnings". 4.4.9., second paragraph defines that "... doubles the value of
> any City or Off-Map Location of the President's choice".
> To capture the spirit of the rules and to simplify things the Pullman will not
> be part of the maximization process, but the President will be prompted to
> select one the city values of the runs.

Hmm, not sure I agree, I think this is a case of slightly misleading
rules text.  I think that the 3: "... must calculate the maximum
possible earnings" is always in force and Pullmans must take account
of it.  David Hecht is pretty vocal on the 18XX yahoo list so it's
always worth posting the question if we aren't in agreement on this.
To make the 'must maximise' work for route calculation I would think
that your D approach should work here (I'm beginning to think that
with all these virtual vertices, route bonuses etc. that the EU
revenue calc might take a little while!)

Phil

Re: [Rails-devel] Implementation details for revenue calculation

[alexti <al...@sh...>]

I'm with Stefan on this one. We have rather strictly defined problem. Our  
domain is well-defined - connectivity graph (with weighted vertices), set  
of trains (here "train" is just a convenient term that can stand for  
anything because it's only used to pass to route valuation function) and  
route valuation function. Co-domain is a set of vertex sequences. The goal  
is to find a transformation that has maximal total value of vertex  
sequences. This operator is our optimal route searching algorithm. It does  
not depend on rules from any specific game - in theory it could be applied  
to some completely different domain, not even related to train or games.  
There is nothing to subclass (or specialize) in it really. A common  
analogy would be something like standard sorting algorithm - either you  
use it as given or you use completely different sorting algorithm, perhaps  
specialized for your particular sequence. Getting back to the train games,  
revenue in Chicago Express would be findable by this approach, but much  
simpler and more efficient algorithm can be implemented for that game.

This leaves 2 pieces of code: one to transform game data into the  
connectivity graph and another - to implement route valuation function. I  
think in both cases rather generic algorithm can take care of most cases  
(for route valuation, the method (or some variation of it) proposed by  
Stefan in another message will work). This will simplify implementing  
various games. However, as those are just inputs into a main solver,  
different implementations can be provided for the games that don't fit  
into the common pattern. This is essentially the same principle as  
sub-classing. Whether it's implemented as sub-classing or as function  
arguments is a minor detail.

Alex.

On Tue, 27 Apr 2010 17:22:19 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> Brett:
> the example you gave below is an example of a class that I have created,  
> thus
> I am aware of that ;-)
>
> And I think that is not the path to choose for the cases we are  
> discussing
> here.
>
> Subclassing implies that the interface to the subclasses includes all
> implementation details of the parent class: This is a blessing and a  
> curse at
> the same time. It makes the implementation of the details easy, as you  
> can
> change everything you like. The price to pay is that you cannot change  
> the
> parent class anymore without checking that you do not break any of your  
> (or
> even worse someone else's) subclasses.
>
> For the revenue calculator I prefer an approach similar to the strategy
> pattern to define the different special rules to the subclassing  
> approach.
>
> Another reason is that the revenue calculator itself implements some
> optimizations, that require advanced knowledge of the problem to solve.  
> Thus
> it would be easy to write special rules subclasses, that would not work
> anymore with some of the optimizations. By narrowing the possible  
> extensions
> I keep control of that.
>
> I admit that some of the arguments are also valid for other classes in  
> Rails.
> Many important classes (as for example OR) are available for subclassing.
> This imposes a high risk of breaking something if you change any of those
> classes. But I also admit that those risks are most likely  
> (over)compensated
> by  the easeness to allow the implementation of specific game rules.
>
> Stefan
>
> On Wednesday 28 April 2010 00:52:30 brett lentz wrote:
>>
>> This is probably where you may want to look to the rules-enforcement
>> for guidance.
>>
>> We've tried to create a class hierarchy that allows us to describe
>> objects in the general sense, and then specify game-specific objects
>> that implement specific exceptions when necessary.
>>
>> Example: OperatingRound vs. OperatingRound_1889.
>>
>> In the same way, you'll likely want a generic calculator that covers
>> "normal" cases, and then for games that use special rules, subclass
>> out the specific exceptions they create and override the parent class
>> methods with more specific implementations.
>>
>> ---Brett.
>>
>> ---------------------------------------------------------------------------
>> --- _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Rails-devel] Implementation details for revenue calculation

[alexti <al...@sh...>]

I agree with the general principle of separating revenue calculator from  
game-specific rules. I do some details differently though for various  
reasons. I avoid touching the graph (with any train or company dependent  
information), so instead of (A) I'm using train-specific bonus (which can  
be vertex-specific or route-specific and can be either addition or a  
multiplier). Some of the bonuses may require a company to own a specific  
token to be applicable. The reason I prefer this approach is that for the  
purpose of revenue prediction available nodes (vertices with value) has to  
be processed. If this information is train-independent I don't have to  
re-process it for each train. Train-dependent information is thus moved  
into bonus calculation which is cheaper and faster process.

(C) is essentially a part of 2-phased approach I'm using. The segments  
including mutually exclusive edges (or vertices) due to the game rules are  
marked as such (in additional to the normal exclusions derived from the  
track layout)

Alex.

On Tue, 27 Apr 2010 16:37:17 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> Back after some travel: Fortunately I could assign some travel time (it  
> is
> special fun to work on Rails at times you travel on rails) to think  
> about the
> special rules and prepare some refactoring for it.
> And I thank for all the comments on the revenue details.
>
> Stefan
>
> I assume that the order of games supported will be
> 1. 1830, 1889
> 2. 1856, 18AL
> 3. 1835, 18Kaas
> 4. 18EU, 1851
>
> Most likely only 1830 and 1889 will be supported in the first release of
> revenue calculation.
>
> Some general remark  first:
> The revenue calculator works on a abstract level, where vertexes  
> consists only
> of the numerical id, the value and their neighbors.  The trains are only
> defined by their length and if they count minors(towns).
>
> In a similar fashion bonuses will be defined on the abstract objects.
> The transformation of the specific (and usually more complex) rules is  
> the
> task of the revenue adapter and if the rules are game specific only of
> classes that use defined interfaces of the revenue adapter.
>
> The main idea is to protect the revenue calculator against the specific  
> rules
> of the games which could potentially conflict with the correctness of the
> calculation and to allow refactoring of the calculator without breaking  
> the
> implementation of the specific rules.
>
>
> The general special rules:
>
> A) Vertex value can be train dependent
> For the revenue calculator the vertex value is also dependent on the  
> train
> identifier. This allows to add train dependent bonuses to each vertex.
> Another advantage is that no special properties for trains that for  
> example
> double station values is required anymore. Instead simply the vertex  
> value are
> changed.
>
> B) Bonus combinations
> A bonus combination consists of #N vertexes, if all of them are visited  
> the
> bonus value is added to this train run.
>
> C) Linked vertexes
> If vertex A is visited then vertex B is considered as visited (without
> counting its value).
>
> D) Definition of additional vertexes
> In the xml files additional (virtual) vertexes can be defined.
>
> This should allow to cover many rules, some examples (and an exception)  
> are
> given in the following section.
>
> Specific implementations:
>
> 1) Multi-Hex offboard areas (several games)
> It is an application of linked vertexes (C). Another issue is the  
> definition
> of the offboard city. It is usually a sink, thus I define those as  
> stations
> with zero token slots, thus they are always tokened out. But that will  
> not
> work for Hamburg in 18EU, which is a zero-slot, but run-through station.
>
> 2) 1889
> Offboard hexes have a special value for diesels only. This is done via  
> train
> dependent vertex values (A).
>
> 3) 1835
> Berlin: No revisit of Berlin stations allowed is an example for linked
> vertexes (C).
>
> Hamburg: The reduced value for the Elbe ferry  is defined as several
> (negative) bonus (-10) combinations: Those are all combinations of two  
> hex
> sides of the Hamburg hex, that define a crossing of the Elbe (B).
>
> 4) 18EU
> Offboard-2-Offboard: That is a very long list of all potential  
> combinations of
> the vertexes with station tokens and the offboard vertexes in the reach  
> of
> the running company (B).
> This clearly shows the principle: Instead of implementing the precise  
> rule of
> 18EU in the calculator, a long list of basic bonus types is used.
>
> Paris, Berlin, Vienna: as in 1835 (C).
>
> Hamburg: I have to admit that I do not like the Hamburg offboard tile:  
> The
> graphical representation does not define exactly, where the value vertex  
> is,
> as it does not contain any type of station.
> I assume the most natural interpretation is to assume a non-tokenable  
> station
> in the middle of the hex (similar to tile 12, only that the slot cannot  
> be
> filled). To work with the offboard bonuses, an additional vertex is  
> connected
> to the station vertex, which acts as a sink (has no neighbors defined,  
> thus
> similar to a tokened out station). All of the bonus combinations for  
> Hamburg
> use that vertex to enforce the restriction that the bonus runs have to  
> stop
> in Hamburg. (D)
>
> Pullman: If I understand the 18EU rules correctly, the Pullman is an  
> exception
> to the second sentence under 4.4.3: "... must calculate the maximum  
> possible
> earnings". 4.4.9., second paragraph defines that "... doubles the value  
> of
> any City or Off-Map Location of the President's choice".
> To capture the spirit of the rules and to simplify things the Pullman  
> will not
> be part of the maximization process, but the President will be prompted  
> to
> select one the city values of the runs.
>
> 5) 1851
> Offboard-2-Offboard: see 18EU
>
> 6) 1856
> Bonus tokens: Simple application of (A)
>
> 7) 18AL
> Named trains: Train dependent application of (A)
>
> 8) 18Kaas
> Ruhr: Long list of all cities/value vertexes combined with the Ruhr  
> vertex,
> that doubles the value of each city (B).
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Rails-devel] Implementation details for revenue calculation

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

On Tue, Apr 27, 2010 at 4:22 PM, Stefan Frey (web.de)
<ste...@we...> wrote:
> Brett:
> the example you gave below is an example of a class that I have created, thus
> I am aware of that ;-)

I know. That's why I used it. It proves that you're aware of the
design pattern. ;-)

> And I think that is not the path to choose for the cases we are discussing
> here.
>
> Subclassing implies that the interface to the subclasses includes all
> implementation details of the parent class: This is a blessing and a curse at
> the same time. It makes the implementation of the details easy, as you can
> change everything you like. The price to pay is that you cannot change the
> parent class anymore without checking that you do not break any of your (or
> even worse someone else's) subclasses.
>

This is also an argument for good documentation... ;-)

> For the revenue calculator I prefer an approach similar to the strategy
> pattern to define the different special rules to the subclassing approach.
>
> Another reason is that the revenue calculator itself implements some
> optimizations, that require advanced knowledge of the problem to solve. Thus
> it would be easy to write special rules subclasses, that would not work
> anymore with some of the optimizations. By narrowing the possible extensions
> I keep control of that.
>

See above comment about documentation.  If it requires advanced
knowledge, that advanced knowledge needs to be written down so that
others don't need to gain it through experimentation.

The down side is that you seem to be committing to the "big ball of
mud" development strategy ( http://www.laputan.org/mud/ ). I certainly
could be wrong here, feel free to rebut. :-)

I don't believe it will be possible or, more importantly, maintainable
to have a single set of classes handle all cases for route calculation
across all games. Consider that we do want to support games, such as
2038, that have radically different concepts of "trains" and "routes".

It may be necessary to take a different approach to modularity. The
approach used for "plugging in" different rules exceptions may not
work in the calculator case, but I don't agree that a single
calculator will fit all possibilities.


> I admit that some of the arguments are also valid for other classes in Rails.
> Many important classes (as for example OR) are available for subclassing.
> This imposes a high risk of breaking something if you change any of those
> classes. But I also admit that those risks are most likely (over)compensated
> by  the easeness to allow the implementation of specific game rules.

That's axiomatic in the definition of a subclass.  Changing the parent
*always* runs the risk of breaking the child if the child is depending
on the behavior of non-overridden parent methods, but that's not an
argument for avoiding subclassing altogether. That's simply the cost
of doing object-oriented business.

Judging by RevenueAdapter's addTrainByString() method, you've already
hit cases where subclassing would make sense. Rather than having to do
string parsing, it would seem to make sense to subclass NetworkTrain
into NetworkTrainDiesel, NetworkTrainExpress, etc. and simply have
classes of trains that "know" what parameters to use (or, possibly
better, avoid having this hard-coded and instead have these parameters
defined within a trains.xml...).

In general with Java, if you're doing string parsing and you're not
writing a text or mark-up parser, you're solving the wrong problem.
You should be doing "instanceof", not string matching. This isn't
Perl. ;-)

>
> Stefan
>

---Brett.


> On Wednesday 28 April 2010 00:52:30 brett lentz wrote:
>>
>> This is probably where you may want to look to the rules-enforcement
>> for guidance.
>>
>> We've tried to create a class hierarchy that allows us to describe
>> objects in the general sense, and then specify game-specific objects
>> that implement specific exceptions when necessary.
>>
>> Example: OperatingRound vs. OperatingRound_1889.
>>
>> In the same way, you'll likely want a generic calculator that covers
>> "normal" cases, and then for games that use special rules, subclass
>> out the specific exceptions they create and override the parent class
>> methods with more specific implementations.
>>
>> ---Brett.
>>
>> ---------------------------------------------------------------------------
>>--- _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. (web.de) <ste...@we...>]

Brett:
the example you gave below is an example of a class that I have created, thus 
I am aware of that ;-)

And I think that is not the path to choose for the cases we are discussing 
here.

Subclassing implies that the interface to the subclasses includes all 
implementation details of the parent class: This is a blessing and a curse at 
the same time. It makes the implementation of the details easy, as you can 
change everything you like. The price to pay is that you cannot change the 
parent class anymore without checking that you do not break any of your (or 
even worse someone else's) subclasses. 

For the revenue calculator I prefer an approach similar to the strategy 
pattern to define the different special rules to the subclassing approach.

Another reason is that the revenue calculator itself implements some 
optimizations, that require advanced knowledge of the problem to solve. Thus 
it would be easy to write special rules subclasses, that would not work 
anymore with some of the optimizations. By narrowing the possible extensions 
I keep control of that.

I admit that some of the arguments are also valid for other classes in Rails. 
Many important classes (as for example OR) are available for subclassing. 
This imposes a high risk of breaking something if you change any of those 
classes. But I also admit that those risks are most likely (over)compensated 
by  the easeness to allow the implementation of specific game rules.

Stefan

On Wednesday 28 April 2010 00:52:30 brett lentz wrote:
>
> This is probably where you may want to look to the rules-enforcement
> for guidance.
>
> We've tried to create a class hierarchy that allows us to describe
> objects in the general sense, and then specify game-specific objects
> that implement specific exceptions when necessary.
>
> Example: OperatingRound vs. OperatingRound_1889.
>
> In the same way, you'll likely want a generic calculator that covers
> "normal" cases, and then for games that use special rules, subclass
> out the specific exceptions they create and override the parent class
> methods with more specific implementations.
>
> ---Brett.
>
> ---------------------------------------------------------------------------
>--- _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

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

On Tue, Apr 27, 2010 at 3:37 PM, Stefan Frey (web.de)
<ste...@we...> wrote:
> Back after some travel: Fortunately I could assign some travel time (it is
> special fun to work on Rails at times you travel on rails) to think about the
> special rules and prepare some refactoring for it.
> And I thank for all the comments on the revenue details.
>
> Stefan
>
> I assume that the order of games supported will be
> 1. 1830, 1889
> 2. 1856, 18AL
> 3. 1835, 18Kaas
> 4. 18EU, 1851
>
> Most likely only 1830 and 1889 will be supported in the first release of
> revenue calculation.
>
> Some general remark  first:
> The revenue calculator works on a abstract level, where vertexes consists only
> of the numerical id, the value and their neighbors.  The trains are only
> defined by their length and if they count minors(towns).
>
> In a similar fashion bonuses will be defined on the abstract objects.
> The transformation of the specific (and usually more complex) rules is the
> task of the revenue adapter and if the rules are game specific only of
> classes that use defined interfaces of the revenue adapter.
>
> The main idea is to protect the revenue calculator against the specific rules
> of the games which could potentially conflict with the correctness of the
> calculation and to allow refactoring of the calculator without breaking the
> implementation of the specific rules.
>


This is probably where you may want to look to the rules-enforcement
for guidance.

We've tried to create a class hierarchy that allows us to describe
objects in the general sense, and then specify game-specific objects
that implement specific exceptions when necessary.

Example: OperatingRound vs. OperatingRound_1889.

In the same way, you'll likely want a generic calculator that covers
"normal" cases, and then for games that use special rules, subclass
out the specific exceptions they create and override the parent class
methods with more specific implementations.

---Brett.

Re: [Rails-devel] Rule details for revenue calculation

[Stefan F. (web.de) <ste...@we...>]

Phil,
Sorry for that: I did comitt an only half-finished refactoring of the network 
iterator. Interestingly the implementation of that is completely 
separate from the revenue calculator. This lost the correctly handling
of switches, should work again now.
Stefan

On Friday 23 April 2010 17:26:38 Phil Davies wrote:
> Brief but related point regarding tile placement.  The tile placement
> highlighting logic seems to allow backtracking at junctions, the
> following is a much greater set of tiles than LPS could really upgrade
> since it can't reverse at E16
>
> Phil
>
> On 23 April 2010 03:32, Steve Undy <ste...@gm...> wrote:
> > Not to mention the "named railroad" chits that give a bonus for running a
> > route between specific cities.
> > '
> > Steve Undy
> > st...@ro...
> >
> >
> > On Thu, Apr 22, 2010 at 5:43 PM, Chris Shaffer <chr...@gm...>
> >
> > wrote:
> >> Note that 18AL doesn't count dit-towns for route length (nor the
> >> lumber terminal) but does count them for value.
> >>
> >> --
> >> Chris
> >>
> >> Please consider the environment before printing this e-mail.
> >>
> >>
> >>
> >> On Thu, Apr 22, 2010 at 2:40 PM, Stefan Frey (web.de)
> >>
> >> <ste...@we...> wrote:
> >> > And I promise that this is my last e-mail for today, but I will be
> >> > away for
> >> > some days and I would love to have some feedback on return.
> >> >
> >> > I guess that currently the revenue calculation works for none of the
> >> > games
> >> > 100% correctly.
> >> >
> >> > There are small little details, which still have to be added for
> >> > several other
> >> > games. If you know other details which deviate from the standard
> >> > revenue rules, please add them below, especially for those games,
> >> > which I hardly know
> >> > or even have no rules for.
> >> >
> >> > Train types already supported are: default (including diesel), plus,
> >> > express
> >> > (ignore towns), double (multiply station values).
> >> >
> >> > My plans are to add:
> >> > - Restriction list of vertexes which are mutually exclusive (that
> >> > covers multi-hex offboard areas and multiple stations on one hex,
> >> > which cannot be
> >> > included in one run).
> >> > - Bonus implementation that is general enough to cover as many
> >> > exceptions as
> >> > possible without being too specific nor complex  (that should cover
> >> > everything else...).
> >> >
> >> > Stefan
> >> >
> >> > Several games (including 1830):
> >> > - Multi-Hex offboard areas can only included once.
> >> >
> >> > 1889:
> >> > - The offboard areas change the revenue value for Diesel trains only.
> >> >
> >> > 18EU:
> >> > - Include infinite towns & ports (already implemented, but not
> >> > activated)
> >> > - Pullman trains: Add highest valuable station.
> >> > - Offboard-to-Offboard bonus
> >> > - Hamburg offboard location hex
> >> > - Berlin, Vienna multiple stations, cannot visit several in one run
> >> >
> >> > 1856:
> >> > - Bonus tokens
> >> >
> >> > 1835:
> >> > - Berlin multiple stations
> >> > - Hamburg ferry
> >> >
> >> > 18Kaas:
> >> > - Ruhr offboard (as reported by Phil)
> >> >
> >> > 18AL, 1851:
> >> > ???
> >> >
> >> >
> >> >
> >> >
> >> > ----------------------------------------------------------------------
> >> >-------- _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >> ------------------------------------------------------------------------
> >>------ _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > -------------------------------------------------------------------------
> >-----
> >
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Implementation details for revenue calculation

[Stefan F. (web.de) <ste...@we...>]

Back after some travel: Fortunately I could assign some travel time (it is 
special fun to work on Rails at times you travel on rails) to think about the 
special rules and prepare some refactoring for it. 
And I thank for all the comments on the revenue details.

Stefan

I assume that the order of games supported will be
1. 1830, 1889
2. 1856, 18AL
3. 1835, 18Kaas
4. 18EU, 1851

Most likely only 1830 and 1889 will be supported in the first release of 
revenue calculation.

Some general remark  first:
The revenue calculator works on a abstract level, where vertexes consists only 
of the numerical id, the value and their neighbors.  The trains are only 
defined by their length and if they count minors(towns).

In a similar fashion bonuses will be defined on the abstract objects.
The transformation of the specific (and usually more complex) rules is the 
task of the revenue adapter and if the rules are game specific only of 
classes that use defined interfaces of the revenue adapter. 

The main idea is to protect the revenue calculator against the specific rules 
of the games which could potentially conflict with the correctness of the 
calculation and to allow refactoring of the calculator without breaking the 
implementation of the specific rules.


The general special rules:

A) Vertex value can be train dependent
For the revenue calculator the vertex value is also dependent on the train 
identifier. This allows to add train dependent bonuses to each vertex.
Another advantage is that no special properties for trains that for example
double station values is required anymore. Instead simply the vertex value are 
changed.

B) Bonus combinations
A bonus combination consists of #N vertexes, if all of them are visited the 
bonus value is added to this train run.

C) Linked vertexes
If vertex A is visited then vertex B is considered as visited (without 
counting its value).

D) Definition of additional vertexes
In the xml files additional (virtual) vertexes can be defined.

This should allow to cover many rules, some examples (and an exception) are 
given in the following section. 

Specific implementations:

1) Multi-Hex offboard areas (several games)
It is an application of linked vertexes (C). Another issue is the definition 
of the offboard city. It is usually a sink, thus I define those as stations 
with zero token slots, thus they are always tokened out. But that will not 
work for Hamburg in 18EU, which is a zero-slot, but run-through station.

2) 1889
Offboard hexes have a special value for diesels only. This is done via train 
dependent vertex values (A).

3) 1835
Berlin: No revisit of Berlin stations allowed is an example for linked 
vertexes (C).

Hamburg: The reduced value for the Elbe ferry  is defined as several 
(negative) bonus (-10) combinations: Those are all combinations of two hex 
sides of the Hamburg hex, that define a crossing of the Elbe (B).

4) 18EU
Offboard-2-Offboard: That is a very long list of all potential combinations of 
the vertexes with station tokens and the offboard vertexes in the reach of 
the running company (B).
This clearly shows the principle: Instead of implementing the precise rule of 
18EU in the calculator, a long list of basic bonus types is used.

Paris, Berlin, Vienna: as in 1835 (C).

Hamburg: I have to admit that I do not like the Hamburg offboard tile: The 
graphical representation does not define exactly, where the value vertex is, 
as it does not contain any type of station.
I assume the most natural interpretation is to assume a non-tokenable station 
in the middle of the hex (similar to tile 12, only that the slot cannot be 
filled). To work with the offboard bonuses, an additional vertex is connected 
to the station vertex, which acts as a sink (has no neighbors defined, thus 
similar to a tokened out station). All of the bonus combinations for Hamburg 
use that vertex to enforce the restriction that the bonus runs have to stop 
in Hamburg. (D)

Pullman: If I understand the 18EU rules correctly, the Pullman is an exception 
to the second sentence under 4.4.3: "... must calculate the maximum possible 
earnings". 4.4.9., second paragraph defines that "... doubles the value of 
any City or Off-Map Location of the President's choice".
To capture the spirit of the rules and to simplify things the Pullman will not 
be part of the maximization process, but the President will be prompted to 
select one the city values of the runs. 

5) 1851
Offboard-2-Offboard: see 18EU

6) 1856
Bonus tokens: Simple application of (A)

7) 18AL
Named trains: Train dependent application of (A)

8) 18Kaas
Ruhr: Long list of all cities/value vertexes combined with the Ruhr vertex, 
that doubles the value of each city (B).

Re: [Rails-devel] Usability options for route awareness and revenuecalculation

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

I agree. Keep it simple.
Erik. 

-----Original Message-----
From: brett lentz [mailto:bre...@gm...] 
Sent: Friday 23 April 2010 06:37
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Usability options for route awareness and
revenuecalculation

If it's manual entry, I see no need to waste the processing cycles on
calculating the run.

Automatic/Suggestion should not enforce any minimum/maximum values
either, but instead should just simply say "I see a run of this
value", then allow the user to enter any value as with manual entry.
Ultimately, in Suggesting mode, it's should still be up to all of the
players to cry foul if incorrect/illegal values are entered. We're
just helping make the game go faster by offering up the optimal route
values we can find; this could be likened to a kibitzing player.

Right now, I can't really see a value in developing a more finely
nuanced progression of turning game control over to the algorithm. "On
and enforcing", "On but not enforcing", and "Off" seems sufficient to
me, at least to begin with.  Once we have these three options, it will
be much easier to see if there are midpoints between them that could
benefit from additional options.

---Brett.


On Thu, Apr 22, 2010 at 7:11 PM, Chris Shaffer <chr...@gm...>
wrote:
> For the manual option you need to allow the player to exceed in case
> the program miscalculates.
>
> Also, some people may not want that manual "too much" prompt, as it
> would allow players to enter ridiculously high numbers to effectively
> autocalculate.
>
> --
> Chris Shaffer
>
> Please consider the environment before printing this email.
>
> On Apr 22, 2010, at 7:50 PM, John David Galt
<jd...@di...
>  > wrote:
>
>> Stefan Frey (web.de) wrote:
>>> The idea is similar to  the current implementation that possible
>>> extensions
>>> and token locations are highlighted. You suggest that it should be
>>> active
>>> only after player requesting it: In that sense it would be
>>> something like
>>> a "Hint" button. Is that something players would prefer to an
>>> always on/off
>>> option?
>>
>> I would suggest a choice that looks like this, under Options in the
>> game-start dialog:
>>
>> Revenue calculation
>> * Automatic, forced
>> * Automatic, suggestion
>> * Manual
>>
>> In all three cases the program should calculate the maximum possible
>> run, but
>> it would then behave as follows:
>>
>> Automatic/forced: Use that number as the revenue, with no
>> opportunity to
>> change it.  (But let it be changed from the Moderator menu.)  (This
>> setting
>> should not be allowed for games like 1853 and 1837, where the player
>> can
>> legitimately choose, and may want, a less-than-maximum run in order
>> to put
>> more money into the company treasury from a mail run or coal mine.)
>>
>> Automatic/suggestion: Tell the player the calculated number, then
>> allow him
>> to enter a value as before, which cannot exceed that number.  (Allow
>> this
>> limit to be overridden from the Moderator menu.)
>>
>> Manual: Don't tell the player anything.  Have him enter a value;
>> then if it's
>> less than or equal to the calculated number, use the value entered.
>> If it's
>> more, give an error message and either have him try again or just
>> tell him
>> the calculated number and use that.  (Again the limit can be
>> overridden using
>> the Moderator menu.)
>>
>> If you want to get fancy you might allow each player or company to
>> use a
>> different one of these three choices, and/or to change them during
>> the game.
>>
>> ---
>> ---
>> ---
>> ---------------------------------------------------------------------
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
----------------------------------------------------------------------------
--
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

----------------------------------------------------------------------------
--
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rule details for revenue calculation

[Phil D. <de...@gm...>]

Brief but related point regarding tile placement.  The tile placement
highlighting logic seems to allow backtracking at junctions, the
following is a much greater set of tiles than LPS could really upgrade
since it can't reverse at E16

Phil

On 23 April 2010 03:32, Steve Undy <ste...@gm...> wrote:
> Not to mention the "named railroad" chits that give a bonus for running a
> route between specific cities.
> '
> Steve Undy
> st...@ro...
>
>
> On Thu, Apr 22, 2010 at 5:43 PM, Chris Shaffer <chr...@gm...>
> wrote:
>>
>> Note that 18AL doesn't count dit-towns for route length (nor the
>> lumber terminal) but does count them for value.
>>
>> --
>> Chris
>>
>> Please consider the environment before printing this e-mail.
>>
>>
>>
>> On Thu, Apr 22, 2010 at 2:40 PM, Stefan Frey (web.de)
>> <ste...@we...> wrote:
>> > And I promise that this is my last e-mail for today, but I will be away
>> > for
>> > some days and I would love to have some feedback on return.
>> >
>> > I guess that currently the revenue calculation works for none of the
>> > games
>> > 100% correctly.
>> >
>> > There are small little details, which still have to be added for several
>> > other
>> > games. If you know other details which deviate from the standard revenue
>> > rules, please add them below, especially for those games, which I hardly
>> > know
>> > or even have no rules for.
>> >
>> > Train types already supported are: default (including diesel), plus,
>> > express
>> > (ignore towns), double (multiply station values).
>> >
>> > My plans are to add:
>> > - Restriction list of vertexes which are mutually exclusive (that covers
>> > multi-hex offboard areas and multiple stations on one hex, which cannot
>> > be
>> > included in one run).
>> > - Bonus implementation that is general enough to cover as many
>> > exceptions as
>> > possible without being too specific nor complex  (that should cover
>> > everything else...).
>> >
>> > Stefan
>> >
>> > Several games (including 1830):
>> > - Multi-Hex offboard areas can only included once.
>> >
>> > 1889:
>> > - The offboard areas change the revenue value for Diesel trains only.
>> >
>> > 18EU:
>> > - Include infinite towns & ports (already implemented, but not
>> > activated)
>> > - Pullman trains: Add highest valuable station.
>> > - Offboard-to-Offboard bonus
>> > - Hamburg offboard location hex
>> > - Berlin, Vienna multiple stations, cannot visit several in one run
>> >
>> > 1856:
>> > - Bonus tokens
>> >
>> > 1835:
>> > - Berlin multiple stations
>> > - Hamburg ferry
>> >
>> > 18Kaas:
>> > - Ruhr offboard (as reported by Phil)
>> >
>> > 18AL, 1851:
>> > ???
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Usability options for route awareness and revenue calculation

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

If it's manual entry, I see no need to waste the processing cycles on
calculating the run.

Automatic/Suggestion should not enforce any minimum/maximum values
either, but instead should just simply say "I see a run of this
value", then allow the user to enter any value as with manual entry.
Ultimately, in Suggesting mode, it's should still be up to all of the
players to cry foul if incorrect/illegal values are entered. We're
just helping make the game go faster by offering up the optimal route
values we can find; this could be likened to a kibitzing player.

Right now, I can't really see a value in developing a more finely
nuanced progression of turning game control over to the algorithm. "On
and enforcing", "On but not enforcing", and "Off" seems sufficient to
me, at least to begin with.  Once we have these three options, it will
be much easier to see if there are midpoints between them that could
benefit from additional options.

---Brett.


On Thu, Apr 22, 2010 at 7:11 PM, Chris Shaffer <chr...@gm...> wrote:
> For the manual option you need to allow the player to exceed in case
> the program miscalculates.
>
> Also, some people may not want that manual "too much" prompt, as it
> would allow players to enter ridiculously high numbers to effectively
> autocalculate.
>
> --
> Chris Shaffer
>
> Please consider the environment before printing this email.
>
> On Apr 22, 2010, at 7:50 PM, John David Galt <jd...@di...
>  > wrote:
>
>> Stefan Frey (web.de) wrote:
>>> The idea is similar to  the current implementation that possible
>>> extensions
>>> and token locations are highlighted. You suggest that it should be
>>> active
>>> only after player requesting it: In that sense it would be
>>> something like
>>> a "Hint" button. Is that something players would prefer to an
>>> always on/off
>>> option?
>>
>> I would suggest a choice that looks like this, under Options in the
>> game-start dialog:
>>
>> Revenue calculation
>> * Automatic, forced
>> * Automatic, suggestion
>> * Manual
>>
>> In all three cases the program should calculate the maximum possible
>> run, but
>> it would then behave as follows:
>>
>> Automatic/forced: Use that number as the revenue, with no
>> opportunity to
>> change it.  (But let it be changed from the Moderator menu.)  (This
>> setting
>> should not be allowed for games like 1853 and 1837, where the player
>> can
>> legitimately choose, and may want, a less-than-maximum run in order
>> to put
>> more money into the company treasury from a mail run or coal mine.)
>>
>> Automatic/suggestion: Tell the player the calculated number, then
>> allow him
>> to enter a value as before, which cannot exceed that number.  (Allow
>> this
>> limit to be overridden from the Moderator menu.)
>>
>> Manual: Don't tell the player anything.  Have him enter a value;
>> then if it's
>> less than or equal to the calculated number, use the value entered.
>> If it's
>> more, give an error message and either have him try again or just
>> tell him
>> the calculated number and use that.  (Again the limit can be
>> overridden using
>> the Moderator menu.)
>>
>> If you want to get fancy you might allow each player or company to
>> use a
>> different one of these three choices, and/or to change them during
>> the game.
>>
>> ---
>> ---
>> ---
>> ---------------------------------------------------------------------
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Several answers related to revenue calculation

[alexti <al...@sh...>]

Hi Stefan,

Thanks for the information. I agree that if we want to track down  
evaluation count differences it will be better to start from a single 2 or  
3 train run.

Alex.

On Thu, 22 Apr 2010 14:43:34 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> Hi Alex,
> answers to several raised question in various e-mails.
>
> And btw:
> The calculation class (RevenueCalculator) is plain Java 1.0 and depends  
> on no
> other class (neither Java API, nor JGraph, nor Rails), except the
> RevenueAdapter to allow callbacks for intermediate revenue updates.
>
> Also the data structure is strongly simplified, vertexes, edges and  
> trains are
> stored as their required attributes in int / boolean arrays.
>
> All the setup is down by the  RevenueAdapter.
>
> In fact the process is that first from the Rails classes the already more
> generic classes NetworkVertex, NetworkEdge and NetworkTrain are  
> generated.
> Those are then used to populate the arrays of the RevenueCalculator.
>
> Simply check the latest version at:
> http://rails.cvs.sourceforge.net/viewvc/rails/18xx/rails/algorithms/RevenueCalculator.java
>
> Stefan
>
>> Yeah, I even can construct a case with 4D and 5 train in 18AL where it's
>> better to run 4D only instead of running both trains. I need to add  
>> "null"
>> route into consideration. Stefan, would you implementation be affected  
>> by
>> the same issue?
>
> That is not an issue for my implementation: A route can merely exist on a
> route to the start token only. However the route is considered of value  
> zero,
> unless two stations are included. Steve Undy raised a similar question:
>
>> BTW, in my trying out the CVS version I saw the route calculation  
>> running
>> "excess" trains with a route including just one city.
>>
>
> Currently the route printout does not adjust the value of each station  
> to the
> actual value. This effects express trains and double trains as well.
>
>> I think that I have identical procedure, but when you say you evaluate
>> train set at (4), and let's say you have 2 trains, does it increase
>> evaluation count by 1 or by 2? I count it as 2 evaluations. In practice  
>> I
>> keep results of evaluation of the first train while trying possible  
>> routes
>> for the second train.
>
> I changed my code somewhat that changed all of the numbers a little (at  
> least
> with revenue calculation). It could have changed the number of the brute
> force approach, as I believe I removed one optimization, which would not  
> work
> anymore if general bonus/malus rules are included.
>
>> I've investigated number of evaluations a bit, mostly looking into a
>> single train case as it has few affecting factors. I've confirmed that  
>> all
>> 5601 possible routes in 8 train scan are unique. However, there are only
>> 2460 unique city sequences. Total number (5601) is greater because it's
>> often possible to run exactly the same sequence of cities while using
>> somewhat different track. Of course, neither number matches yours. Do  
>> you
>> have any ideas about the cause of discrepancy?
>
> To be more precise I only evaluate after running the last train and each
> evaluation is single counted, regardless of  the number of trains in the
> train set. My suggestion if we want to really find the difference in the
> counts to start with running a two and/or three train in scenario A,  
> cases
> which are easier to enumerate manually.
>
>> I believe I have both optimizations you mentioned. Just to be clear on  
>> (2)
>> - for example, if the candidate route starts at the station and is 7
>> cities long while only 6-trains are available it won't be evaluated,  
>> right?
>
> Yes that is right.
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Rails-devel] Rule details for revenue calculation

[Steve U. <ste...@gm...>]

Not to mention the "named railroad" chits that give a bonus for running a
route between specific cities.
'
Steve Undy
st...@ro...


On Thu, Apr 22, 2010 at 5:43 PM, Chris Shaffer <chr...@gm...>wrote:

> Note that 18AL doesn't count dit-towns for route length (nor the
> lumber terminal) but does count them for value.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
>
> On Thu, Apr 22, 2010 at 2:40 PM, Stefan Frey (web.de)
> <ste...@we...> wrote:
> > And I promise that this is my last e-mail for today, but I will be away
> for
> > some days and I would love to have some feedback on return.
> >
> > I guess that currently the revenue calculation works for none of the
> games
> > 100% correctly.
> >
> > There are small little details, which still have to be added for several
> other
> > games. If you know other details which deviate from the standard revenue
> > rules, please add them below, especially for those games, which I hardly
> know
> > or even have no rules for.
> >
> > Train types already supported are: default (including diesel), plus,
> express
> > (ignore towns), double (multiply station values).
> >
> > My plans are to add:
> > - Restriction list of vertexes which are mutually exclusive (that covers
> > multi-hex offboard areas and multiple stations on one hex, which cannot
> be
> > included in one run).
> > - Bonus implementation that is general enough to cover as many exceptions
> as
> > possible without being too specific nor complex  (that should cover
> > everything else...).
> >
> > Stefan
> >
> > Several games (including 1830):
> > - Multi-Hex offboard areas can only included once.
> >
> > 1889:
> > - The offboard areas change the revenue value for Diesel trains only.
> >
> > 18EU:
> > - Include infinite towns & ports (already implemented, but not activated)
> > - Pullman trains: Add highest valuable station.
> > - Offboard-to-Offboard bonus
> > - Hamburg offboard location hex
> > - Berlin, Vienna multiple stations, cannot visit several in one run
> >
> > 1856:
> > - Bonus tokens
> >
> > 1835:
> > - Berlin multiple stations
> > - Hamburg ferry
> >
> > 18Kaas:
> > - Ruhr offboard (as reported by Phil)
> >
> > 18AL, 1851:
> > ???
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Usability options for route awareness and revenue calculation

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

For the manual option you need to allow the player to exceed in case  
the program miscalculates.

Also, some people may not want that manual "too much" prompt, as it  
would allow players to enter ridiculously high numbers to effectively  
autocalculate.

--
Chris Shaffer

Please consider the environment before printing this email.

On Apr 22, 2010, at 7:50 PM, John David Galt <jd...@di... 
 > wrote:

> Stefan Frey (web.de) wrote:
>> The idea is similar to  the current implementation that possible  
>> extensions
>> and token locations are highlighted. You suggest that it should be  
>> active
>> only after player requesting it: In that sense it would be  
>> something like
>> a "Hint" button. Is that something players would prefer to an  
>> always on/off
>> option?
>
> I would suggest a choice that looks like this, under Options in the
> game-start dialog:
>
> Revenue calculation
> * Automatic, forced
> * Automatic, suggestion
> * Manual
>
> In all three cases the program should calculate the maximum possible  
> run, but
> it would then behave as follows:
>
> Automatic/forced: Use that number as the revenue, with no  
> opportunity to
> change it.  (But let it be changed from the Moderator menu.)  (This  
> setting
> should not be allowed for games like 1853 and 1837, where the player  
> can
> legitimately choose, and may want, a less-than-maximum run in order  
> to put
> more money into the company treasury from a mail run or coal mine.)
>
> Automatic/suggestion: Tell the player the calculated number, then  
> allow him
> to enter a value as before, which cannot exceed that number.  (Allow  
> this
> limit to be overridden from the Moderator menu.)
>
> Manual: Don't tell the player anything.  Have him enter a value;  
> then if it's
> less than or equal to the calculated number, use the value entered.   
> If it's
> more, give an error message and either have him try again or just  
> tell him
> the calculated number and use that.  (Again the limit can be  
> overridden using
> the Moderator menu.)
>
> If you want to get fancy you might allow each player or company to  
> use a
> different one of these three choices, and/or to change them during  
> the game.
>
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Usability options for route awareness and revenue calculation

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

Stefan Frey (web.de) wrote:
> The idea is similar to  the current implementation that possible extensions 
> and token locations are highlighted. You suggest that it should be active 
> only after player requesting it: In that sense it would be something like 
> a "Hint" button. Is that something players would prefer to an always on/off 
> option?

I would suggest a choice that looks like this, under Options in the
game-start dialog:

Revenue calculation
* Automatic, forced
* Automatic, suggestion
* Manual

In all three cases the program should calculate the maximum possible run, but
it would then behave as follows:

Automatic/forced: Use that number as the revenue, with no opportunity to
change it.  (But let it be changed from the Moderator menu.)  (This setting
should not be allowed for games like 1853 and 1837, where the player can
legitimately choose, and may want, a less-than-maximum run in order to put
more money into the company treasury from a mail run or coal mine.)

Automatic/suggestion: Tell the player the calculated number, then allow him
to enter a value as before, which cannot exceed that number.  (Allow this
limit to be overridden from the Moderator menu.)

Manual: Don't tell the player anything.  Have him enter a value; then if it's
less than or equal to the calculated number, use the value entered.  If it's
more, give an error message and either have him try again or just tell him
the calculated number and use that.  (Again the limit can be overridden using
the Moderator menu.)

If you want to get fancy you might allow each player or company to use a
different one of these three choices, and/or to change them during the game.

Re: [Rails-devel] Rule details for revenue calculation

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

Note that 18AL doesn't count dit-towns for route length (nor the
lumber terminal) but does count them for value.

--
Chris

Please consider the environment before printing this e-mail.



On Thu, Apr 22, 2010 at 2:40 PM, Stefan Frey (web.de)
<ste...@we...> wrote:
> And I promise that this is my last e-mail for today, but I will be away for
> some days and I would love to have some feedback on return.
>
> I guess that currently the revenue calculation works for none of the games
> 100% correctly.
>
> There are small little details, which still have to be added for several other
> games. If you know other details which deviate from the standard revenue
> rules, please add them below, especially for those games, which I hardly know
> or even have no rules for.
>
> Train types already supported are: default (including diesel), plus, express
> (ignore towns), double (multiply station values).
>
> My plans are to add:
> - Restriction list of vertexes which are mutually exclusive (that covers
> multi-hex offboard areas and multiple stations on one hex, which cannot be
> included in one run).
> - Bonus implementation that is general enough to cover as many exceptions as
> possible without being too specific nor complex  (that should cover
> everything else...).
>
> Stefan
>
> Several games (including 1830):
> - Multi-Hex offboard areas can only included once.
>
> 1889:
> - The offboard areas change the revenue value for Diesel trains only.
>
> 18EU:
> - Include infinite towns & ports (already implemented, but not activated)
> - Pullman trains: Add highest valuable station.
> - Offboard-to-Offboard bonus
> - Hamburg offboard location hex
> - Berlin, Vienna multiple stations, cannot visit several in one run
>
> 1856:
> - Bonus tokens
>
> 1835:
> - Berlin multiple stations
> - Hamburg ferry
>
> 18Kaas:
> - Ruhr offboard (as reported by Phil)
>
> 18AL, 1851:
> ???
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Usability options for route awareness and revenuecalculation

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

The other option I would add in my.properties is a color palette for
route highlighting.  This could be useful for people like me who would
prefer garish easy to view colors, people who like pastel palettes and
also for color blind players.

--
Chris

Please consider the environment before printing this e-mail.



On Thu, Apr 22, 2010 at 2:57 PM, Erik Vos <eri...@xs...> wrote:
> Stefan,
>
> I generally agree with the options that you propose.
>
> My suggestion would be to make the options selectable in the GUI, but it
> would be nice if some defaults could be set in my.properties:
> - possible tile/token lay highlighting,
> - possible tile/token lay enforcing,
> - optimal revenue calculation,
> - optimal revenue route display
> all yes/no choices.
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Thursday 22 April 2010 23:24
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Usability options for route awareness and
> revenuecalculation
>
> Hi,
> I would like to focus the discussion on the question in which ways
> the revenue calculation and route awareness should be available to the
> players.
>
> I first start with comments on two recent e-mails on that topic.
>
> I am myself not sure for now, if I will like playing with automatic revenue
> calculation. For sure in the last ORs, but in the beginning of the game?
> And I still like a real map, please someone come up with an implementation
> for
> an observing camera, which generates the according tile lays for Rails ;-)
>
> Jim Black wrote 2010-04-06:
>> I hope that- perhaps, as a preliminary feature to Rails-calculated routes-
>> users will simply be able to outline their routes directly in Rails (by
>> selecting the track, along the way)- 'route specification', if you will.
>>
>> I know automatic calculation is a very popular, heavily requested feature.
>>
>> Still, to me- 'route specification' is probably more important/fundamental
>> than 'automatic route calculation'.
>
> Current status:
> For now the route awareness is only used to highlight potential locations
> for extensions of the routes. It does not enforce anything more than Rails
> already does.
>
> My suggestion is to add a menu-item in the GUI that turns that on/off. See
> an
> different approach at the end of the mail.
>
> Future solution:
> Have a game option for each game that allows to set the route enforcing to
> -> none
> -> permissive
> -> restrictive
> -> semi-restrictive
> with the default option set to the official rule for that game.
> Compare:
> http://www.fwtwr.com/18xx/rules_difference_list/5_3.htm
>>
>> Indeed, I wonder if 'route specification' isn't the extent of 'automatic
>> route calculation' that would be /allowed/, in a conventional,
>> tournament-level 18xx game.  (I would expect that many 18xx experts feel
>> calculating earnings properly is part of the game- not something that's
>> necessarily /desirable/ to automate?)
>
> That is similar to the question of open/closed money. For me revenue
> calculation sometimes is simply annoying, especially in late ORs late at
> night.
> But for others it might be the essential skill of a good 18xx player...
> I admit it is not a particular strength in my own skillset.
>
>>
>> Will automated route calculation be offered as an option?  If users
> /don't/
>> select automatic route calculation, will they still get some of the
>> benefits of this work?  (Eg, specifically, for route-specification?)
>
> Current status:
> An optimal route is automatically calculated and suggested to the player.
>
> But there will be an option for the next release.
> There could be the following settings:
> -> strict (the value is enforced, player can only decide on distribution)
> -> optional (suggests a value, which can be changed or confirmed)
> -> off
> Should there be a possibility to turn it on later in the game?
> I would love an automatic mode: play the game to the end by running maximum
> and payout for all companies.
>
>>
>> Ideally, players could can still outline their own route(s), per-train, in
>> the map view- Rails would then record that, and add-up/record the
>> corresponding earnings precisely.  (And, of course- other users could
>> review the earnings/routes, in the game history.)
>
> Earnings figures are already recorded. I currently do not plan to implement
> the possibility of sketching routes manually.
>
> Aliza Panitz wrote 2010-03-24:
>> (1) Have a button that users can click to highlight every bit of track
>> that their trains can reach from their tokens.  This will be useful
>> even without route calculation, though it will require Rails to learn
>> about track, routes, tokens, etc.
>>
>> The algorithm I'm thinking of would be a simple flood-fill that gets
>> blocked by foreign tokens if the circles are filled.
>>
>> As a second stage it could limit itself to the length of the longest
>> train the company has, though the flood-fill is useful even with
>> imaginary infinite-length Diesels for showing where tokens can legally
>> be placed.
>
> The idea is similar to  the current implementation that possible extensions
> and token locations are highlighted. You suggest that it should be active
> only after player requesting it: In that sense it would be something like
> a "Hint" button. Is that something players would prefer to an always on/off
> option?
>
> Stefan
>
>
>
> ----------------------------------------------------------------------------
> --
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Rule details for revenue calculation

[Phil D. <de...@gm...>]

1851 also has an offboard-offboard bonus, it's +10 for every stop
included on the route (including the offboards).  So a 3T that stops
at 2 offboards and one city in between is +30 revenue

Only example I can curretnly think of for currently implemented games...

Phil

On 22 April 2010 22:40, Stefan Frey (web.de) <ste...@we...> wrote:
> And I promise that this is my last e-mail for today, but I will be away for
> some days and I would love to have some feedback on return.
>
> I guess that currently the revenue calculation works for none of the games
> 100% correctly.
>
> There are small little details, which still have to be added for several other
> games. If you know other details which deviate from the standard revenue
> rules, please add them below, especially for those games, which I hardly know
> or even have no rules for.
>
> Train types already supported are: default (including diesel), plus, express
> (ignore towns), double (multiply station values).
>
> My plans are to add:
> - Restriction list of vertexes which are mutually exclusive (that covers
> multi-hex offboard areas and multiple stations on one hex, which cannot be
> included in one run).
> - Bonus implementation that is general enough to cover as many exceptions as
> possible without being too specific nor complex  (that should cover
> everything else...).
>
> Stefan
>
> Several games (including 1830):
> - Multi-Hex offboard areas can only included once.
>
> 1889:
> - The offboard areas change the revenue value for Diesel trains only.
>
> 18EU:
> - Include infinite towns & ports (already implemented, but not activated)
> - Pullman trains: Add highest valuable station.
> - Offboard-to-Offboard bonus
> - Hamburg offboard location hex
> - Berlin, Vienna multiple stations, cannot visit several in one run
>
> 1856:
> - Bonus tokens
>
> 1835:
> - Berlin multiple stations
> - Hamburg ferry
>
> 18Kaas:
> - Ruhr offboard (as reported by Phil)
>
> 18AL, 1851:
> ???
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Usability options for route awareness and revenuecalculation

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

Stefan,

I generally agree with the options that you propose.

My suggestion would be to make the options selectable in the GUI, but it
would be nice if some defaults could be set in my.properties:
- possible tile/token lay highlighting,
- possible tile/token lay enforcing,
- optimal revenue calculation,
- optimal revenue route display
all yes/no choices.

Erik.

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Thursday 22 April 2010 23:24
To: Development list for Rails: an 18xx game
Subject: [Rails-devel] Usability options for route awareness and
revenuecalculation

Hi,
I would like to focus the discussion on the question in which ways
the revenue calculation and route awareness should be available to the 
players.

I first start with comments on two recent e-mails on that topic.

I am myself not sure for now, if I will like playing with automatic revenue 
calculation. For sure in the last ORs, but in the beginning of the game?
And I still like a real map, please someone come up with an implementation
for
an observing camera, which generates the according tile lays for Rails ;-)

Jim Black wrote 2010-04-06:
> I hope that- perhaps, as a preliminary feature to Rails-calculated routes-
> users will simply be able to outline their routes directly in Rails (by
> selecting the track, along the way)- 'route specification', if you will.
>
> I know automatic calculation is a very popular, heavily requested feature.
>
> Still, to me- 'route specification' is probably more important/fundamental
> than 'automatic route calculation'.

Current status:
For now the route awareness is only used to highlight potential locations
for extensions of the routes. It does not enforce anything more than Rails 
already does.

My suggestion is to add a menu-item in the GUI that turns that on/off. See
an 
different approach at the end of the mail.

Future solution:
Have a game option for each game that allows to set the route enforcing to
-> none
-> permissive
-> restrictive
-> semi-restrictive
with the default option set to the official rule for that game.
Compare:
http://www.fwtwr.com/18xx/rules_difference_list/5_3.htm
>
> Indeed, I wonder if 'route specification' isn't the extent of 'automatic
> route calculation' that would be /allowed/, in a conventional,
> tournament-level 18xx game.  (I would expect that many 18xx experts feel
> calculating earnings properly is part of the game- not something that's
> necessarily /desirable/ to automate?)

That is similar to the question of open/closed money. For me revenue 
calculation sometimes is simply annoying, especially in late ORs late at 
night.
But for others it might be the essential skill of a good 18xx player... 
I admit it is not a particular strength in my own skillset.

>
> Will automated route calculation be offered as an option?  If users
/don't/
> select automatic route calculation, will they still get some of the
> benefits of this work?  (Eg, specifically, for route-specification?)

Current status:
An optimal route is automatically calculated and suggested to the player.

But there will be an option for the next release. 
There could be the following settings:
-> strict (the value is enforced, player can only decide on distribution)
-> optional (suggests a value, which can be changed or confirmed)
-> off
Should there be a possibility to turn it on later in the game?
I would love an automatic mode: play the game to the end by running maximum 
and payout for all companies.

>
> Ideally, players could can still outline their own route(s), per-train, in
> the map view- Rails would then record that, and add-up/record the
> corresponding earnings precisely.  (And, of course- other users could
> review the earnings/routes, in the game history.)

Earnings figures are already recorded. I currently do not plan to implement 
the possibility of sketching routes manually.

Aliza Panitz wrote 2010-03-24:
> (1) Have a button that users can click to highlight every bit of track
> that their trains can reach from their tokens.  This will be useful
> even without route calculation, though it will require Rails to learn
> about track, routes, tokens, etc.
>
> The algorithm I'm thinking of would be a simple flood-fill that gets
> blocked by foreign tokens if the circles are filled.
>
> As a second stage it could limit itself to the length of the longest
> train the company has, though the flood-fill is useful even with
> imaginary infinite-length Diesels for showing where tokens can legally
> be placed.

The idea is similar to  the current implementation that possible extensions 
and token locations are highlighted. You suggest that it should be active 
only after player requesting it: In that sense it would be something like 
a "Hint" button. Is that something players would prefer to an always on/off 
option?

Stefan



----------------------------------------------------------------------------
--
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Rule details for revenue calculation

[Stefan F. (web.de) <ste...@we...>]

And I promise that this is my last e-mail for today, but I will be away for 
some days and I would love to have some feedback on return.

I guess that currently the revenue calculation works for none of the games 
100% correctly.

There are small little details, which still have to be added for several other 
games. If you know other details which deviate from the standard revenue 
rules, please add them below, especially for those games, which I hardly know 
or even have no rules for.

Train types already supported are: default (including diesel), plus, express 
(ignore towns), double (multiply station values).

My plans are to add:
- Restriction list of vertexes which are mutually exclusive (that covers 
multi-hex offboard areas and multiple stations on one hex, which cannot be 
included in one run).
- Bonus implementation that is general enough to cover as many exceptions as 
possible without being too specific nor complex  (that should cover 
everything else...).

Stefan

Several games (including 1830):
- Multi-Hex offboard areas can only included once.

1889:
- The offboard areas change the revenue value for Diesel trains only.

18EU:
- Include infinite towns & ports (already implemented, but not activated)
- Pullman trains: Add highest valuable station.
- Offboard-to-Offboard bonus
- Hamburg offboard location hex
- Berlin, Vienna multiple stations, cannot visit several in one run

1856:
- Bonus tokens

1835:
- Berlin multiple stations
- Hamburg ferry

18Kaas:
- Ruhr offboard (as reported by Phil)

18AL, 1851:
???