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

[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

[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

[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

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

yes that helps, otherwise it would not be scored. The same is true for the 
equivalent tile in 1856.

The (additional) virtual vertex takes care of the bonus condition to end the 
run at the off-board location and is thus only required for 18EU.

On Wednesday 28 April 2010 21:41:08 Erik Vos wrote:
> 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)
>
>
>
> ---------------------------------------------------------------------------
>--- _______________________________________________
> 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...>]

OK, I have replaced tile -939 in Tiles.xml by a handmade version.
This applies to the generic Tiles.xml and to 1856 (Goderich) and 18EU
(Hamburg).
The extra element is a "City" type station, with zero slots.
The tile is still recognizable as an off-board tile by its colour ("red").

Please check if this works for you.

There is now a new XML file called HandmadeTiles.xml.
During running the XML conversion tool ConvertTilesXML, 
tile entries in this file are used; the corresponding
tiles in TileDictionary.xml are not converted but skipped.

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Thursday 29 April 2010 21:58
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

yes that helps, otherwise it would not be scored. The same is true for the 
equivalent tile in 1856.

The (additional) virtual vertex takes care of the bonus condition to end the

run at the off-board location and is thus only required for 18EU.

On Wednesday 28 April 2010 21:41:08 Erik Vos wrote:
> 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)
>
>
>
>
---------------------------------------------------------------------------
>--- _______________________________________________
> 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. <ste...@we...>]

Phil:
I was more making fun (of myself) after rereading the rules for the Pullman, 
but it is good to see that others read my proposals carefully ;-)

My suggestion below is more against the spirit of the rules than according to 
it, but thanks for recommending to ask the 18xx yahoo group, which I believe 
is not needed, as I suspect that everyone agrees that it should be part of 
maximization process.

And reading your mail carefully, I learn that the plural of vertex is 
vertices ;-)
Stefan

>
> > 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
>
> ---------------------------------------------------------------------------
>--- _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

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

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

Glad to help with spreading the insidious invasion of my language to
the rest of the world :)

On 29 April 2010 21:04, Stefan Frey <ste...@we...> wrote:
> Phil:
> I was more making fun (of myself) after rereading the rules for the Pullman,
> but it is good to see that others read my proposals carefully ;-)
>
> My suggestion below is more against the spirit of the rules than according to
> it, but thanks for recommending to ask the 18xx yahoo group, which I believe
> is not needed, as I suspect that everyone agrees that it should be part of
> maximization process.
>
> And reading your mail carefully, I learn that the plural of vertex is
> vertices ;-)
> Stefan
>
>>
>> > 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
>>
>> ---------------------------------------------------------------------------
>>--- _______________________________________________
>> 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. <ste...@we...>]

Erik:
thanks, it is moving in the right direction, but it is still not on the 
target: Having zero slots it evaluates as fully tokened, thus no one can run 
through. Setting slots to one, it would allow tokening :-(

For solving the whole variety of possible off-map locations we need more 
flexibility and generality as outlined by the new attributes. But you are 
right, we should think that through carefully to both add enough flexibility 
and not breaking any of the old code. For the time being I will simply ignore 
the track structure in tile.xml for the off-map locations and rely on a 
separate defined graph structure, where no side-effects are possible.

In any case the new functionality can come in handy at times.

At tests for revenue calculation on a 1835 map I ran into the following bugs 
quickly:

A) Hamburg north (base of 6) has a value of 20, instead of the correct 40.
B) Upgrades to green Berlin are not allowed (no valid orientation).

I can provide save files if required.

Stefan



On Friday 30 April 2010 17:32:04 Erik Vos wrote:
> OK, I have replaced tile -939 in Tiles.xml by a handmade version.
> This applies to the generic Tiles.xml and to 1856 (Goderich) and 18EU
> (Hamburg).
> The extra element is a "City" type station, with zero slots.
> The tile is still recognizable as an off-board tile by its colour ("red").
>
> Please check if this works for you.
>
> There is now a new XML file called HandmadeTiles.xml.
> During running the XML conversion tool ConvertTilesXML,
> tile entries in this file are used; the corresponding
> tiles in TileDictionary.xml are not converted but skipped.
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday 29 April 2010 21:58
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Implementation details for revenue calculation
>
> yes that helps, otherwise it would not be scored. The same is true for the
> equivalent tile in 1856.
>
> The (additional) virtual vertex takes care of the bonus condition to end
> the
>
> run at the off-board location and is thus only required for 18EU.
>
> On Wednesday 28 April 2010 21:41:08 Erik Vos wrote:
> > 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)
>
> ---------------------------------------------------------------------------
>
> >--- _______________________________________________
> > 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] Implementation details for revenue calculation

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

 

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Saturday 01 May 2010 20:58
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

Erik:
thanks, it is moving in the right direction, but it is still not on the 
target: Having zero slots it evaluates as fully tokened, thus no one can run

through. Setting slots to one, it would allow tokening :-(

[EV] Zero slots should be interpreted as: everybody can run through.
I think such a rule would be generic enough, not needing additional
attributes for *this* purpose.

For solving the whole variety of possible off-map locations we need more 
flexibility and generality as outlined by the new attributes. 

[EV] Yes, but attributes of what?
I think we basically have two dimensions: StationType and TrainType. 
The intersection (matrix) of these types needs properties that define
the behaviour towards revenue calculation; I think we can assign 
such properties to either one. 
TrainType already exists, StationType would be a new class
(already proposed by you), defined in some ConfigurableComponent.


At tests for revenue calculation on a 1835 map I ran into the following bugs

quickly:

A) Hamburg north (base of 6) has a value of 20, instead of the correct 40.

[EV] Correct. Fixed.

B) Upgrades to green Berlin are not allowed (no valid orientation).

I can provide save files if required.

[EV] Yes please, for case B. I'm hitting on another bug when trying to get
there... :-(

Erik.

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

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

> [EV] Zero slots should be interpreted as: everybody can run through.
> I think such a rule would be generic enough, not needing additional
> attributes for *this* purpose.
>

Sure you can encode some of boolean attributes into the numerical attribute of 
slots.

Another extension allows the pattern:
slots = 0 => always run through 
slots = -1 => never run through (as standard off-map areas)

I personally favor defining more variables and prefer not encode several 
dimensions into one variable.

In your defintiion e.g. a Station is fully tokened if number of slots == 
number of tokens or number of slots equals zero.

In my definition a Station is fully tokened if (number of slots == numer of 
tokens). I would first check if the station is fully tokened and then the 
different booleans define what companies can if they have or have not an own 
token.

But in fact your are right: it is matter of preference.


> For solving the whole variety of possible off-map locations we need more
> flexibility and generality as outlined by the new attributes.
>
> [EV] Yes, but attributes of what?
> I think we basically have two dimensions: StationType and TrainType.
> The intersection (matrix) of these types needs properties that define
> the behaviour towards revenue calculation; I think we can assign
> such properties to either one.
> TrainType already exists, StationType would be a new class
> (already proposed by you), defined in some ConfigurableComponent.

Attributes of stations as outlined below. I hope that the question how tokens 
influence the running of train is not train dependent.

> B) Upgrades to green Berlin are not allowed (no valid orientation).
>
> I can provide save files if required.
>
> [EV] Yes please, for case B. I'm hitting on another bug when trying to get
> there... :-(
>

Attached. Hope you can open it, if you have changed anything already.

I have attached another one: At least on my laptop the southern part of the 
map is not shown anymore when Bay is active, as they have several special 
lays available. And no scrollbar shows up to scroll down.

Stefan

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

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

 


Another extension allows the pattern:
slots = 0 => always run through 
slots = -1 => never run through (as standard off-map areas)

[EV] Not needed. Normal off-board areas have an OffMapCity type station, 
which should have the not-run-through property built in.
But here we were talking about City type stations.

I personally favor defining more variables and prefer not encode several 
dimensions into one variable.

[EV] Agreed, but, as said, that was not needed.

In your defintion e.g. a Station is fully tokened if number of slots == 
number of tokens or number of slots equals zero.

In my definition a Station is fully tokened if (number of slots == numer of 
tokens). I would first check if the station is fully tokened and then the 
different booleans define what companies can if they have or have not an own

token.

[EV] "Fully tokened" is not a very interesting property or state. 
"Runnable-through" is what we are interested in. And my definitions are:
(a) a City type Station can be run through if there is at least one free
slot
(i.e. not "fully tokened") or the number of slots is zero. It is a variable
state.
(b) an OffMapCity type Station can never be run through. This is a fixed
property.

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

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

Erik:

The difference is minor: You define the station types  first  and then define 
the properties by coding methods that check the types, I would define the 
properties first and then define station types accordingly.

As I think we are going in circles here, I will use your 
solution to keep the peace ;-) 

What is your suggestion then to model the off-board stations in 18Scan, where 
only the token-owner can run to? "Off-board destinations"?

Kiruna is a (standard) town on a off-board map tile, that is simple.

Stefan


On Saturday 01 May 2010 22:21:34 Erik Vos wrote:
> Another extension allows the pattern:
> slots = 0 => always run through
> slots = -1 => never run through (as standard off-map areas)
>
> [EV] Not needed. Normal off-board areas have an OffMapCity type station,
> which should have the not-run-through property built in.
> But here we were talking about City type stations.
>
> I personally favor defining more variables and prefer not encode several
> dimensions into one variable.
>
> [EV] Agreed, but, as said, that was not needed.
>
> In your defintion e.g. a Station is fully tokened if number of slots ==
> number of tokens or number of slots equals zero.
>
> In my definition a Station is fully tokened if (number of slots == numer of
> tokens). I would first check if the station is fully tokened and then the
> different booleans define what companies can if they have or have not an
> own
>
> token.
>
> [EV] "Fully tokened" is not a very interesting property or state.
> "Runnable-through" is what we are interested in. And my definitions are:
> (a) a City type Station can be run through if there is at least one free
> slot
> (i.e. not "fully tokened") or the number of slots is zero. It is a variable
> state.
> (b) an OffMapCity type Station can never be run through. This is a fixed
> property.
>
>
> ---------------------------------------------------------------------------
>--- _______________________________________________
> 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...>]

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Saturday 01 May 2010 21:54
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

> B) Upgrades to green Berlin are not allowed (no valid orientation).

[EV] Was caused by the OO tile laying fix. Green Berlin was subjected to the
same kind of check.
The OO-check is now only done if the number of cities on a tile remains the
same.

I have attached another one: At least on my laptop the southern part of the 
map is not shown anymore when Bay is active, as they have several special 
lays available. And no scrollbar shows up to scroll down.

[EV] I don't see this problem with this saved file.
Did you see any exceptions in the window where Rails is started?

Erik.

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

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

What is your suggestion then to model the off-board stations in 18Scan,
where 
only the token-owner can run to? "Off-board destinations"?

[EV] Those tiles haven't been defined yet, and I'm not even sure if
TileDesigner can do that, so these might need special treatment (i.e.
handcrafting) anyway. 
I'd say: either some property in the hex definition in Map.xml, or (indeed)
a special name in Tiles.xml. I guess the former would be easier.

It's usually impossible to tell beforehand if some special case can be
handled by a generic property, or needs special code (in a game-specific
subclass). I usually try to find out how it can be done with minimal code.
In this case I gladly leave it to you how to model all of this. I only got a
(perhaps unjustified) feeling that you were reinventing some wheel. But I
may be wrong, and in that case I have said nothing. Peace is not in danger.

Erik.

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

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

Erik:
I agree that is really hard to know (predict) what all the 18xx (might) have 
defined, especially in those areas which are not that important to be covered 
by the rules comparison list. For those details everyone is restricted to the 
knowledge of the titles he plays regularly.

In some sort re-factoring is always a kind of reinventing. Hopefully to the 
better.

I fixed the issue with the ClosePrivate implementation, some leftover of the 
separation of the correction actions prevented the propagation of the action 
down to the OR class.

I will be away for a week on vacation, I hope to find a finalized 1835 after 
that ;-)

Stefan

> It's usually impossible to tell beforehand if some special case can be
> handled by a generic property, or needs special code (in a game-specific
> subclass). I usually try to find out how it can be done with minimal code.
> In this case I gladly leave it to you how to model all of this. I only got
> a (perhaps unjustified) feeling that you were reinventing some wheel. But I
> may be wrong, and in that case I have said nothing. Peace is not in danger.
>
> Erik.
>
>
> ---------------------------------------------------------------------------
>--- _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] revenue library

[Freek D. <sf_...@ma...>]

Stefan, and all others who helped,

My compliments for the revenue calculator. It looks awesome already!

I just did a minor commit adding the graph libraries to the classpath in
build.xml; without it, it did not run. (This is only relevant for those
who use ant to build the app).

Regards,
Freek

Re: [Rails-devel] revenue library

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

Freek,
thanks for the compliments and the fix to the built script.
Stefan

Some more updates to changes to the revenue calculator:
The result is that 1830 and 1889 are now the first games, which are fully 
supported.

The changes are:
-> Stations with identical city attributes are automatically defined 
as "vertexVisitSets" for the revenue calculator. Thus each station sets all 
other stations to be already visited. For offboard stations the attribute 
defined for the hex is used, for all other stations the tile definition is 
the relevant one.

This prevents a train to run twice into multiple-hex off-board locations. For 
tiles with multiple stations (e.g. Berlin in 1835), where only one can 
visited per run, the city tag has to be defined accordingly.

-> For hexes and tiles RevenueBonuses can be defined.

An example for the syntax is:
<RevenueBonus value="40"> <Vertex id="-1"/> <Train type="D"/> </RevenueBonus>
(That is the one used for 1889 off-board locations).
An additional tag <Phase name=""/> is available.

All tags can be used more than once per each RevenueBonus, trains and phases 
are "OR" connected, vertices "AND".
 
This allows the already mentioned 1889 diesel bonuses and the HH Elbe crossing 
malus in 1835. In addition those are basic elements for RevenueModifiers, 
which will allow to implement more complicated bonuses.


On Sunday 09 May 2010 00:10:07 Freek Dijkstra wrote:
> Stefan, and all others who helped,
>
> My compliments for the revenue calculator. It looks awesome already!
>
> I just did a minor commit adding the graph libraries to the classpath in
> build.xml; without it, it did not run. (This is only relevant for those
> who use ant to build the app).
>
> Regards,
> Freek
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] revenue library

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

Some more updates to the revenue calculator:

As a result 1835 is now fully supported.

Open issues:
-> Berlin tile still has to be added to the hand-made tiles (city names to
block double runs to yellow Berlin).

-> Hamburg tile has to be layed without rotation, otherwise the Elbe malus
is not applied correctly.

-> I assume that Elsac/Lothringen is a single multi-hex off-board area, thus
cannot be included both into a single run (It is not 100% clear from the 
different rules).

General Changes are:
-> Complex bonuses (multi-vertex) are possible (as in HH).
-> All vertices with special conditions are protected throughout the graph
optimization.
-> The message box shows now the individual value of each train and adds
line breaks for long runs. Complex Bonuses are shown at the end of the run, 
simple bonuses as a "+ xx" value  for the vertex.

I do not know, what the general opinion is: I would prefer not too wait too 
long for the next release to get more feedback. Currently we have 1830, 1835 
and 1889 with complete support of revenue calculation. All games (except 1851 
with the invisible Birmingham) should have the basic route awareness working.

All others are more complex and require the RevenueModifiers, which I would 
prefer to keep back until the next release. It is possible to add some of the 
games at minor releases.

My proposal is:
1) Define a gameOption for RevenueCalculation with two settings for now: 
{None, Suggest} for 1830, 1835, 1889
2) Define a gameOption for RouteAwareness with two settings for now:
{None, (Hex)Highlight} for all games, except 1851

An open question is whether the default should be none or one of the active 
ones. If the active selection is chosen, I would suggest, that we add another 
default for those games saved by previous version ("undefined default") and 
set those to none. Otherwise people might complain that they get a feature, 
that they did not want at the start of their game.

And another question: Anyone suggest better colors (RGB values) for the 
routing paths. I do not know, if I have time to figure out, how I make those 
configurable from the properties file.

Stefan

Re: [Rails-devel] revenue library

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

My comments below.
Erik. 

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Friday 14 May 2010 17:42
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] revenue library

Some more updates to the revenue calculator:

As a result 1835 is now fully supported.

Open issues:
-> Berlin tile still has to be added to the hand-made tiles (city names to
block double runs to yellow Berlin).

[EV] Does this mean that the one and only function of Station city names in
the Tile definitions is to block multiple runs?
That does not sound very logical to me. Cannot this blocking feature (much)
better be made a (single) MapHex property? Or, if it's colour-dependent, in
TileSet?  Like <NoMultipleAccess/> or such?

-> Hamburg tile has to be layed without rotation, otherwise the Elbe malus
is not applied correctly.

[EV] Now implemented (orientation="0" in TileSet fixes orientation).

-> I assume that Elsac/Lothringen is a single multi-hex off-board area, thus
cannot be included both into a single run (It is not 100% clear from the 
different rules).

[EV] That's what I also would assume.

I do not know, what the general opinion is: I would prefer not too wait too 
long for the next release to get more feedback. Currently we have 1830, 1835

and 1889 with complete support of revenue calculation. All games (except
1851 
with the invisible Birmingham) should have the basic route awareness
working.

[EV] I agree. However, 1856 needs some more retesting (see previous
message).

All others are more complex and require the RevenueModifiers, which I would 
prefer to keep back until the next release. It is possible to add some of
the 
games at minor releases.

My proposal is:
1) Define a gameOption for RevenueCalculation with two settings for now: 
{None, Suggest} for 1830, 1835, 1889
2) Define a gameOption for RouteAwareness with two settings for now:
{None, (Hex)Highlight} for all games, except 1851

An open question is whether the default should be none or one of the active 
ones. If the active selection is chosen, I would suggest, that we add
another 
default for those games saved by previous version ("undefined default") and 
set those to none. Otherwise people might complain that they get a feature, 
that they did not want at the start of their game.

[EV] OK with me. Another idea is to allow defining defaults in
My.properties.

And another question: Anyone suggest better colors (RGB values) for the 
routing paths. I do not know, if I have time to figure out, how I make those

configurable from the properties file.

[EV] I'm willing to look at that.

Re: [Rails-devel] revenue library

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

Erik:
see below.

On Saturday 15 May 2010 22:04:15 Erik Vos wrote:
> -> Berlin tile still has to be added to the hand-made tiles (city names to
> block double runs to yellow Berlin).
>
> [EV] Does this mean that the one and only function of Station city names in
> the Tile definitions is to block multiple runs?
> That does not sound very logical to me. Cannot this blocking feature (much)
> better be made a (single) MapHex property? Or, if it's colour-dependent, in
> TileSet?  Like <NoMultipleAccess/> or such?

I found it logical, but I came up with that solution, so that does not mean 
too much. And all solutions have reasonable pro/cons. My reasons were:

A) Choosing the city attribute mirrors the solution for the offboard 
locations/stations. The only difference is that for offboard locations the 
city name (like the revenue value) is defined on the MapHex instead of 
creating different tiles for each off-board area. Allows easy implementation.

I only hope that no one ever comes up with two different off-map locations 
combined on one hex, but that would cause headaches for the revenue value as 
well.

B) Why not in TileSet? Stations are defined in Tile.xml, I did not want to 
split that information over various  files.

C) Why not one property per MapHex/Tile? It allows easily to have restrictions 
that combine several hexes/tiles into one vertex set (as I call them). And 
think about a tile with three stations, where only belong to one city.
I admit that all that is not required for the games currently implemented.

Stefan