rails-devel

[Rails-devel] Stop properties

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

I have implemented (but not yet pushed) the train stop properties that we
have discussed a while ago, all described below. 

My questions are (in particular so Stefan):
Q1. Do you like it this way?  Is it usable?
Q2. What shall I do to the repository?  Push the branch? Or push it merged
with master?  Or first redo it all because you don't like it? ;-)
Q3. See point 6: some algorithms classes currently pick up values from
HexMap.  The current code requires that these values should be taken from
Stop (see comments below).  Would that be OK for you?  Or should I add
methods to HexMap and/or Tile that honour defaults?

Here is the overview (I'll put it into the wiki later):

1. City has been renamed to Stop. This object represents a train stop on a
certain tile that has been laid on a certain hex. 
Stop will become the primary source of all properties that are required to
define routes and calculate revenues.
(I have left Station as it is, because this object name equates to the
corresponding tag names in Tile.xml, 
which I did not want to change after all.  I hope we can live with this
slight naming inconsistency.)

2. The Stop properties can be derived from either MapHex (defined in
Map.xml) or Tile (defined in TileSet.xml).  
If both exist, MapHex takes precedence, as it is more specific.
If neither is defined, it will use defaults on the Manager level in the same
XML files, with the same precedence. 
See item 5 for details and a precedence list.

3. The stop properties are:

- type = {major|minor|offmap|medium|halt|pass|port|mine|null} .
I have added offmap because usually different defaults apply. 
However, for train running purposes offmap stops should normally be treated
as major cities.
Cities on "red" tiles are marked offmap by default.
"null" applies to plain track tiles, and allows to define a non-default
"loop" value (1860), see below.

- runTo = {no|yes|tokenOnly}. Default "yes".
"no" would apply to e.g. Birmingham in 1851 before phase 4 and
Elsaß-Lothringen in 1835 except in phase 2. 
"tokenOnly" would apply to e.g. the 18Scan red cities.
This usage implies that the runTo value may be phase-dependent.

- runThrough = {no|yes|tokenOnly}.  Default "yes" (exception: offmap "no").
"yes" obviously only applies if the city is not closed (i.e. filled by
tokens of other companies).
"no" would apply to standard off-map areas, 
"tokenOnly" would apply to 1830 Altoona (PRR base, implying a PRR token).
Is there a need for "always" (i.e., even if closed)? Any other special
cases?

4. A somewhat related new MapHex property (also accessible to Stop, but not
restricted to tiles with stops) is:
- loop = {yes|no}, which defines if one train may touch a hex more than
once.  Default "yes" (exception: offmap "no").
"no" applies to *all* tiles in 1860.

5. Defaults per stop type, and generic defaults (type=null) can be defined
in Map.xml and TileSet.xml. 
These defaults are parsed and stored in MapManager and TileManager,
respectively.
The precedence is (the first non-null value found is used):
- specific Hex
- specific Tile
- Hex default per stop type
- Tile default per stop type
- generic Hex default (type=null)
- generic Tile default (type = null)
- final default as defined above.

I believe this all gives enough flexibility, but of course the proof of the
pudding is in the eating.
I have tested settings at various but not all levels.  Current usage
effectively only needs the first and last level.

6. Stop, Tile and MapHex all have these four methods:
Stop.Type getType() or getStopType(),
Stop.RunTo isRunToAllowed(), 
Stop.RunThrough isRunThroughAllowed(),
Stop.Loop isLoopAllowed().
However, only the return values from Stop follow the precedence rules. The
values from HexMap and Tile only return any *explicit* settings in <Hex> and
<Tile>, so these are of little use.
Please let me know if that could be a problem for some use cases.  I would
have to add separate methods if these return values should also honour the
defaults.

(Note: the existing HexMap.Run type has been split and moved to Stop.  The
algorithms classes still pick up values from HexMap, which is no longer
correct, see above.)

I have so far added explicit settings to the following cases (all in
Map.xml):
1830: The PRR [and Reading] bases: runThrough="tokenOnly".
1856 Goderich/18EU Hamburg: runThrough="yes" (not really needed, because
tile -939 already behaves correctly, but that one has been manually
tweaked).
18EU Paris/Berlin/Vienna: loop="no".

The Stop code temporarily logs all Stop settings in a way that stands out,
so that checking the effects of any trial settings should be easy.

Erik.

Re: [Rails-devel] Stop properties

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

On Fri, Aug 12, 2011 at 5:47 AM, Erik Vos <eri...@xs...> wrote:
> I have implemented (but not yet pushed) the train stop properties that we
> have discussed a while ago, all described below.
>
> My questions are (in particular so Stefan):
> Q1. Do you like it this way?  Is it usable?
> Q2. What shall I do to the repository?  Push the branch? Or push it merged
> with master?  Or first redo it all because you don't like it? ;-)


You can also diff your branch against master, and post the diff to the
mailing list.  ;-)

---Brett.

Re: [Rails-devel] Stop properties

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

OK, here is a diff.
(I did this from the command line, as I could not find how to do it in Egit.  It's a git diff).

Erik.

> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Friday, August 12, 2011 5:30 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Stop properties
> 
> On Fri, Aug 12, 2011 at 5:47 AM, Erik Vos <eri...@xs...> wrote:
> > I have implemented (but not yet pushed) the train stop properties that
> > we have discussed a while ago, all described below.
> >
> > My questions are (in particular so Stefan):
> > Q1. Do you like it this way?  Is it usable?
> > Q2. What shall I do to the repository?  Push the branch? Or push it
> > merged with master?  Or first redo it all because you don't like it?
> > ;-)
> 
> 
> You can also diff your branch against master, and post the diff to the mailing
> list.  ;-)
> 
> ---Brett.
> 
> ------------------------------------------------------------------------------
> FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
> Subversion made easy with a complete admin console. Easy to use, easy to
> manage, easy to install, easy to extend.
> Get a Free download of the new open ALM Subversion platform now.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties

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

Erik:
I had a glance at the diff: Seems perfect fine to me.

The only issue I have is related to the type attribute:

Could you please add another attribute that defines if the stop has to be 
counted against the major or minor train reach? Maybe call this revenueType or 
scoreType? Values are {major|minor}. Or rename the type attribute to name and 
call that type. 

Answer to your questions below.

Stefan

PS: On some occasions the methods to ask for stops are still label getCities. 
Maybe you could change that accordingly?


On Friday, August 12, 2011 02:47:02 pm Erik Vos wrote:
> I have implemented (but not yet pushed) the train stop properties that we
> have discussed a while ago, all described below.
> 
> My questions are (in particular so Stefan):
> Q1. Do you like it this way?  Is it usable?
Sure, see above.
> Q2. What shall I do to the repository?  Push the branch? Or push it merged
> with master?  Or first redo it all because you don't like it? ;-)

Push after merge.

> Q3. See point 6: some algorithms classes currently pick up values from
> HexMap.  The current code requires that these values should be taken from
> Stop (see comments below).  Would that be OK for you?  Or should I add
> methods to HexMap and/or Tile that honour defaults?

Asking the stop only was exactly the solution I prefer. I will adapt the 
algorithm code myself after you have pushed it.

> 
> Here is the overview (I'll put it into the wiki later):
> 
> 1. City has been renamed to Stop. This object represents a train stop on a
> certain tile that has been laid on a certain hex.
> Stop will become the primary source of all properties that are required to
> define routes and calculate revenues.
> (I have left Station as it is, because this object name equates to the
> corresponding tag names in Tile.xml,
> which I did not want to change after all.  I hope we can live with this
> slight naming inconsistency.)
> 
> 2. The Stop properties can be derived from either MapHex (defined in
> Map.xml) or Tile (defined in TileSet.xml).
> If both exist, MapHex takes precedence, as it is more specific.
> If neither is defined, it will use defaults on the Manager level in the
> same XML files, with the same precedence.
> See item 5 for details and a precedence list.
> 
> 3. The stop properties are:
> 
> - type = {major|minor|offmap|medium|halt|pass|port|mine|null} .
> I have added offmap because usually different defaults apply.
> However, for train running purposes offmap stops should normally be treated
> as major cities.
> Cities on "red" tiles are marked offmap by default.
> "null" applies to plain track tiles, and allows to define a non-default
> "loop" value (1860), see below.
> 
> - runTo = {no|yes|tokenOnly}. Default "yes".
> "no" would apply to e.g. Birmingham in 1851 before phase 4 and
> Elsaß-Lothringen in 1835 except in phase 2.
> "tokenOnly" would apply to e.g. the 18Scan red cities.
> This usage implies that the runTo value may be phase-dependent.
> 
> - runThrough = {no|yes|tokenOnly}.  Default "yes" (exception: offmap "no").
> "yes" obviously only applies if the city is not closed (i.e. filled by
> tokens of other companies).
> "no" would apply to standard off-map areas,
> "tokenOnly" would apply to 1830 Altoona (PRR base, implying a PRR token).
> Is there a need for "always" (i.e., even if closed)? Any other special
> cases?
> 
> 4. A somewhat related new MapHex property (also accessible to Stop, but not
> restricted to tiles with stops) is:
> - loop = {yes|no}, which defines if one train may touch a hex more than
> once.  Default "yes" (exception: offmap "no").
> "no" applies to *all* tiles in 1860.
> 
> 5. Defaults per stop type, and generic defaults (type=null) can be defined
> in Map.xml and TileSet.xml.
> These defaults are parsed and stored in MapManager and TileManager,
> respectively.
> The precedence is (the first non-null value found is used):
> - specific Hex
> - specific Tile
> - Hex default per stop type
> - Tile default per stop type
> - generic Hex default (type=null)
> - generic Tile default (type = null)
> - final default as defined above.
> 
> I believe this all gives enough flexibility, but of course the proof of the
> pudding is in the eating.
> I have tested settings at various but not all levels.  Current usage
> effectively only needs the first and last level.
> 
> 6. Stop, Tile and MapHex all have these four methods:
> Stop.Type getType() or getStopType(),
> Stop.RunTo isRunToAllowed(),
> Stop.RunThrough isRunThroughAllowed(),
> Stop.Loop isLoopAllowed().
> However, only the return values from Stop follow the precedence rules. The
> values from HexMap and Tile only return any *explicit* settings in <Hex>
> and <Tile>, so these are of little use.
> Please let me know if that could be a problem for some use cases.  I would
> have to add separate methods if these return values should also honour the
> defaults.
> 
> (Note: the existing HexMap.Run type has been split and moved to Stop.  The
> algorithms classes still pick up values from HexMap, which is no longer
> correct, see above.)
> 
> I have so far added explicit settings to the following cases (all in
> Map.xml):
> 1830: The PRR [and Reading] bases: runThrough="tokenOnly".
> 1856 Goderich/18EU Hamburg: runThrough="yes" (not really needed, because
> tile -939 already behaves correctly, but that one has been manually
> tweaked).
> 18EU Paris/Berlin/Vienna: loop="no".
> 
> The Stop code temporarily logs all Stop settings in a way that stands out,
> so that checking the effects of any trial settings should be easy.
> 
> Erik.
> 
> 
> 
> ---------------------------------------------------------------------------
> --- Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties

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

Stefan,

Revised proposals and some further questions below.

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

> The only issue I have is related to the type attribute:
> 
> Could you please add another attribute that defines if the stop has to be
> counted against the major or minor train reach? Maybe call this
revenueType
> or scoreType? Values are {major|minor}. Or rename the type attribute to
> name and call that type.

Very good point.  I had mixed up stopType and scoreType.  

For stopTypes we can now reuse the original 'city' and 'town' markers:
stopType = {city|town|offmap|halt|pass|port|mine|null} 
Note: I have removed 'medium', as it does not affect scoring, only
upgrading.
(The special upgrading rules for medium cities in 1854 and 1880 can already
be dealt with. 
Perhaps the upgrade rules could be simplified by adding a special <Hex>
attribute to mark *hexes* as medium cities).

scoreType = {major|minor}.
Q4: Do we need a separate type for 1860 halts? And perhaps 1825 halts (see
also Q7 below)?

I think each stopType needs a default scoreType, as follows:

stopType =
{city(major)|town(major*)|offmap(major)|halt(minor?)|pass(major)|port(minor)
|mine(major)} .
* Q5: or minor? I chose 'major' because 1830 and many other games there is
no difference between cities and towns as regards scoring, but OTOH the
train properties and I believe your code can already deal with either.

Some other issues:

Q6: How are we going to deal with train-dependent runTo values, as we have
in 1837 (mines) and 18VA (CMDs), where only G-trains may run from/to such
stops?

Q7: In 1825, the only difference between cities and towns is, that routes
may not start or end at a town (except for some special trains). 
We could implement this by setting <Access stopType="town" runTo="no"/>, but
I don't know if that would work, and it would be train-dependent too.
Does runThrough="yes" require runTo="yes", or are these two settings
entirely independent?

Erik.

Re: [Rails-devel] Stop properties

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

Erik,
answers see below.
Stefan

> Q4: Do we need a separate type for 1860 halts? And perhaps 1825 halts (see
> also Q7 below)?
> 
> I think each stopType needs a default scoreType, as follows:
 > 
> stopType =
> {city(major)|town(major*)|offmap(major)|halt(minor?)|pass(major)|port(minor
> )
> 
> |mine(major)} .

I would only add stopTypes to XML which are already supported. 
So currently we have only city, town and offmap.
I have not checked how you defined the ports in 18EU, but for me they are 
identical to towns and would not need an own stopType.

> 
> * Q5: or minor? I chose 'major' because 1830 and many other games there is
> no difference between cities and towns as regards scoring, but OTOH the
> train properties and I believe your code can already deal with either.

Towns can and should always be minor as for standard trains major and minor 
stops are both counted to train reach.

The revenue calculation supports trains that
* ignore minors (as express trains)
* score minors, but do not count them to reach (as trains in 18EU)
* multiply majors and/or minors (as 4D in 18AL)
* plus trains (as 3+3 in 1835)
* hex trains (in 1826)

Each train is defined individually, thus all types of train can run jointly.

> 
> Some other issues:
> 
> Q6: How are we going to deal with train-dependent runTo values, as we have
> in 1837 (mines) and 18VA (CMDs), where only G-trains may run from/to such
> stops?

This should be supported by a RevenueDynamicModifier, as the current algorithm 
does not support this out of the box. All modifiers can be setup as 
configurable components in XML, thus you could and should add attributes 
there, placed under RevenueManager.

> 
> Q7: In 1825, the only difference between cities and towns is, that routes
> may not start or end at a town (except for some special trains).
> We could implement this by setting <Access stopType="town" runTo="no"/>,
> but I don't know if that would work, and it would be train-dependent too.
> Does runThrough="yes" require runTo="yes", or are these two settings
> entirely independent?

All 1825 specific issues are supported by revenue modifiers already, thus 
there does not need a XML support for this.

1825 modifiers are:
DoubleHeadingModifier to allow two 2-trains run as a 3 train.
ScoreTileOnlyOnceModifier to check that each tile is scored only once.
TerminateAtMajorModifier to only allow runs that start/finish at majors.

I would only add XML support if we have a lot more games that would make use 
of it. And then I would start adding attributes to configure the modifiers (if 
required), instead to change the general xml settings.

The advantage for a modifier is that we commit only to work correctly in the 
context of the specific game for which it is defined.

For properties defined in general xml, it should work in general and in 
combination with all other settings of all other properties defined in the 
xml. And this is difficult to code and especially test against.

Re: [Rails-devel] Stop properties

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

OK, I have pushed the Stop properties code, after wrapping it up with
Stefan's latest comments.

ScoreType (minor, major) has been added.  See 1830/Map.xml for the <Access>
XML format; this also applies to TileSet.xml.

StopTypes have been restricted to city, town, offmap, although I expect that
more types will be needed later on.

Erik.

Re: [Rails-devel] Stop properties

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

> > Q4: Do we need a separate type for 1860 halts? And perhaps 1825 halts
> > (see also Q7 below)?
> >
> I would only add stopTypes to XML which are already supported.
> So currently we have only city, town and offmap.

We have already started to work at 18VA and 1825, so I would like to look at
these games anyway.

After all, the stop properties are only intended to make your life a bit
easier, at least in this matter....:-)

> I have not checked how you defined the ports in 18EU, but for me they are
> identical to towns and would not need an own stopType.

That's true for 18EU, and 1841 as well (except that in 1841 ports do not
count as stops in finding a valid route - towns do).
Currently, 18EU ports are defined as towns.

18VA ports are of a different kind. These are not separate stops (for
finding valid route purposes), but add a bonus to the nearby cities (if
tokened) - but only if that city is at one end of a route. 
To enforce port cities being at the end of a route, it could be helpful to
add ports as special kind of stops anyway. (This only applies to Baltimore
and Annapolis: you cannot both run through to Philadelphia or Baltimore and
get the port bonus).
On the other hand, if we don't consider 18VA ports as separate entities, I
think we should also remove the 18VA ports from the visible map.

> Towns can and should always be minor as for standard trains major and
> minor stops are both counted to train reach.

OK.

> All 1825 specific issues are supported by revenue modifiers already, thus
> there does not need a XML support for this.
> 
> 1825 modifiers are:
> DoubleHeadingModifier to allow two 2-trains run as a 3 train.
> ScoreTileOnlyOnceModifier to check that each tile is scored only once.
> TerminateAtMajorModifier to only allow runs that start/finish at majors.

Wouldn't you need something extra to support 1825 halts (on tile #11, in
some kits)? 
Only T-trains may (optionally) consider halts as stops, other trains must
ignore halts.
I think a separate scoreType could be helpful here, but perhaps you can do
without.

Erik.

Re: [Rails-devel] Stop properties

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

Erik:
your suggestions/questions below all belong to the same discussion.

My design principle for the revenue calculation is the following:

A) Implement the general 18xx rules in the core revenue classes in a general 
way (thus allow variations) and keep performance in mind. 

B) Implement all specific game rules in specific modifiers, which only 
implement what is needed. Here I do not take care about performance.
All modifiers have to use pre-defined interfaces.

This translates to XML: 
A) All variations of the core rules should be controlled by variables in XML.

B) Define specific settings (e.g. hexes, trains) inside the modifier classes. 
No XML needed.

It has the additional benefit to keep the XML clean and focused.

It might happen over time that a rule upgrades from the specific to the 
general category.

This was my type A) remark, type B) remarks below ;-)

Stefan


On Sunday, August 14, 2011 03:21:15 pm Erik Vos wrote:
> > > Q4: Do we need a separate type for 1860 halts? And perhaps 1825 halts
> > > (see also Q7 below)?
> > 
> > I would only add stopTypes to XML which are already supported.
> > So currently we have only city, town and offmap.
> 
> We have already started to work at 18VA and 1825, so I would like to look
> at these games anyway.
> 
> After all, the stop properties are only intended to make your life a bit
> easier, at least in this matter....:-)

For me the stopType is nothing more than a name (for me). I do not like to 
have something like stopType.equals ("....") inside the core code (type A)). 
This is similar to the name of a trainType: All attributes have to be defined 
by attributes, the name does not matter.

This for example enables the fact that entities with identical names behave 
differently across games (think about how 2-trains in 18EU or 1830, H-trains 
in 1844 or 1826 etc.).

> 
> > I have not checked how you defined the ports in 18EU, but for me they are
> > identical to towns and would not need an own stopType.
> 
> That's true for 18EU, and 1841 as well (except that in 1841 ports do not
> count as stops in finding a valid route - towns do).
> Currently, 18EU ports are defined as towns.

Again it does not matter: If the type is only a name, one can define 18EU 
ports as ports and then define the attributes identical to towns in 18EU.

> 
> 18VA ports are of a different kind. These are not separate stops (for
> finding valid route purposes), but add a bonus to the nearby cities (if
> tokened) - but only if that city is at one end of a route.
> To enforce port cities being at the end of a route, it could be helpful to
> add ports as special kind of stops anyway. (This only applies to Baltimore
> and Annapolis: you cannot both run through to Philadelphia or Baltimore and
> get the port bonus).
> On the other hand, if we don't consider 18VA ports as separate entities, I
> think we should also remove the 18VA ports from the visible map.

As the type is only a name, ports in 18EU are independent of ports in 18VA.
However it seems that this is a very specific behavior, thus it will be a 
modifier => type B) rule, no XML support.

> 
> > Towns can and should always be minor as for standard trains major and
> > minor stops are both counted to train reach.
> 
> OK.


To be more precise: Actually towns could be defined as major in 1830 as there 
are no +-trains currently. However as soon as someones adds a plus-train, 
(s)he would be surprised that it does not behave as expected.


> 
> > All 1825 specific issues are supported by revenue modifiers already, thus
> > there does not need a XML support for this.
> > 
> > 1825 modifiers are:
> > DoubleHeadingModifier to allow two 2-trains run as a 3 train.
> > ScoreTileOnlyOnceModifier to check that each tile is scored only once.
> > TerminateAtMajorModifier to only allow runs that start/finish at majors.
> 
> Wouldn't you need something extra to support 1825 halts (on tile #11, in
> some kits)?
> Only T-trains may (optionally) consider halts as stops, other trains must
> ignore halts.
> I think a separate scoreType could be helpful here, but perhaps you can do
> without.

You are right, but I thought that T-trains and tile #11 only exists in some 
kits, I did not know that they are already included.
Again sounds like a modifier, thus no need to support inside XML.

> 
> Erik.
> 
> 
> 
> ---------------------------------------------------------------------------
> --- FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
> Subversion made easy with a complete admin console. Easy
> to use, easy to manage, easy to install, easy to extend.
> Get a Free download of the new open ALM Subversion platform now.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties

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

Erik:
I tried to change my coding in NetworkVertex accordingly.
Thanks a lot this will simplify the previous code needed to adapt the revenue 
code to the algorithm code substantially.

However as usual with coding one realizes some more thing.

I think having those attributes are one thing, checking if runThrough or runTo 
is possible still requires more than that.

The best solution would be adding additional methods for if a runThrough and a 
runTo is possible for a specific company. Thus it also checks the current 
token situation.

Thus something like

public boolean runThroughAllowedFor(PublicCompanyI company)
public boolean runToAllowedFor(PublicCompanyI company)

From my perspective you could then define the 
isRunToAllowed/isRunThroughAllowed for  as private or even remove it, as this 
is only required internally. Similar for the according methods in MapHex or 
Tile, they only need to be package private and not public.

Even better would be if  you could add similar methods. Then all values are 
retrieved from the stop object, instead of sometimes querying hex or station 
instead.

* public int getValueAt(PhaseI phase)
Retrieves the current value (either from the related station for cities/towns 
or via the MapHex for offboard defined values)

* public String getName()
Retrieves the name: Either from the hex or if undefined there from the related 
station.

Again this would allow to restrict access/visibility of a lot of related 
methods in Stop / Station / MapHex.


Some other remarks:

* Are you sure that the time of calling initStopProperties that all other 
objects are already setup correctly? And you should ensure that it is not 
possible to change the values of the runTo and runThrough attributes of hex 
and station after creation of the stop objects, otherwise there could be nasty 
surprises, if someone tries this in the future. The alternative is to go 
through the list of attributes each time the methods are called.

* I currently do not support the loop attribute. The 1825 not scoring twice 
rule is supported by an independent revenue modifier.
1860 has so many strange rules that it surely needs modifier(s), thus there is 
no need for such an attribute now. I suggest to remove or comment it out, as 
long as it not supported (again to avoid surprise).

Stefan


On Friday, August 12, 2011 02:47:02 pm Erik Vos wrote:
> I have implemented (but not yet pushed) the train stop properties that we
> have discussed a while ago, all described below.
> 
> My questions are (in particular so Stefan):
> Q1. Do you like it this way?  Is it usable?
> Q2. What shall I do to the repository?  Push the branch? Or push it merged
> with master?  Or first redo it all because you don't like it? ;-)
> Q3. See point 6: some algorithms classes currently pick up values from
> HexMap.  The current code requires that these values should be taken from
> Stop (see comments below).  Would that be OK for you?  Or should I add
> methods to HexMap and/or Tile that honour defaults?
> 
> Here is the overview (I'll put it into the wiki later):
> 
> 1. City has been renamed to Stop. This object represents a train stop on a
> certain tile that has been laid on a certain hex.
> Stop will become the primary source of all properties that are required to
> define routes and calculate revenues.
> (I have left Station as it is, because this object name equates to the
> corresponding tag names in Tile.xml,
> which I did not want to change after all.  I hope we can live with this
> slight naming inconsistency.)
> 
> 2. The Stop properties can be derived from either MapHex (defined in
> Map.xml) or Tile (defined in TileSet.xml).
> If both exist, MapHex takes precedence, as it is more specific.
> If neither is defined, it will use defaults on the Manager level in the
> same XML files, with the same precedence.
> See item 5 for details and a precedence list.
> 
> 3. The stop properties are:
> 
> - type = {major|minor|offmap|medium|halt|pass|port|mine|null} .
> I have added offmap because usually different defaults apply.
> However, for train running purposes offmap stops should normally be treated
> as major cities.
> Cities on "red" tiles are marked offmap by default.
> "null" applies to plain track tiles, and allows to define a non-default
> "loop" value (1860), see below.
> 
> - runTo = {no|yes|tokenOnly}. Default "yes".
> "no" would apply to e.g. Birmingham in 1851 before phase 4 and
> Elsaß-Lothringen in 1835 except in phase 2.
> "tokenOnly" would apply to e.g. the 18Scan red cities.
> This usage implies that the runTo value may be phase-dependent.
> 
> - runThrough = {no|yes|tokenOnly}.  Default "yes" (exception: offmap "no").
> "yes" obviously only applies if the city is not closed (i.e. filled by
> tokens of other companies).
> "no" would apply to standard off-map areas,
> "tokenOnly" would apply to 1830 Altoona (PRR base, implying a PRR token).
> Is there a need for "always" (i.e., even if closed)? Any other special
> cases?
> 
> 4. A somewhat related new MapHex property (also accessible to Stop, but not
> restricted to tiles with stops) is:
> - loop = {yes|no}, which defines if one train may touch a hex more than
> once.  Default "yes" (exception: offmap "no").
> "no" applies to *all* tiles in 1860.
> 
> 5. Defaults per stop type, and generic defaults (type=null) can be defined
> in Map.xml and TileSet.xml.
> These defaults are parsed and stored in MapManager and TileManager,
> respectively.
> The precedence is (the first non-null value found is used):
> - specific Hex
> - specific Tile
> - Hex default per stop type
> - Tile default per stop type
> - generic Hex default (type=null)
> - generic Tile default (type = null)
> - final default as defined above.
> 
> I believe this all gives enough flexibility, but of course the proof of the
> pudding is in the eating.
> I have tested settings at various but not all levels.  Current usage
> effectively only needs the first and last level.
> 
> 6. Stop, Tile and MapHex all have these four methods:
> Stop.Type getType() or getStopType(),
> Stop.RunTo isRunToAllowed(),
> Stop.RunThrough isRunThroughAllowed(),
> Stop.Loop isLoopAllowed().
> However, only the return values from Stop follow the precedence rules. The
> values from HexMap and Tile only return any *explicit* settings in <Hex>
> and <Tile>, so these are of little use.
> Please let me know if that could be a problem for some use cases.  I would
> have to add separate methods if these return values should also honour the
> defaults.
> 
> (Note: the existing HexMap.Run type has been split and moved to Stop.  The
> algorithms classes still pick up values from HexMap, which is no longer
> correct, see above.)
> 
> I have so far added explicit settings to the following cases (all in
> Map.xml):
> 1830: The PRR [and Reading] bases: runThrough="tokenOnly".
> 1856 Goderich/18EU Hamburg: runThrough="yes" (not really needed, because
> tile -939 already behaves correctly, but that one has been manually
> tweaked).
> 18EU Paris/Berlin/Vienna: loop="no".
> 
> The Stop code temporarily logs all Stop settings in a way that stands out,
> so that checking the effects of any trial settings should be easy.
> 
> Erik.
> 
> 
> 
> ---------------------------------------------------------------------------
> --- Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties

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

> * Are you sure that the time of calling initStopProperties that all other
> objects are already setup correctly? 

That should be OK: this method is called via finishConfiguration(), i.e.
after all XML has been parsed (that is a hard rule).

> And you should ensure that it is not
> possible to change the values of the runTo and runThrough attributes of
hex
> and station after creation of the stop objects, otherwise there could be
nasty
> surprises, if someone tries this in the future. 

I think I have not added any setters yet, but I have already mentioned that
we might need some. In cases like 1851 Birmingham, runTo is in fact
phase-dependent (although you have probably already solved that with some
modifier).

> The alternative is to go
> through the list of attributes each time the methods are called.

Sounds unnecessary to me.

> * I currently do not support the loop attribute. 

I know, but I had hoped that you would like to add it (apologies for not
asking so explicitly). 

It's all in the spirit of giving more power to the non-programmers amongst
us.  Several people have already started implementing games by preparing
XML, only to find that they have to involve you and me to get the details
done.  I'm very well aware that we cannot make everything configurable in
XML, and that it would be silly to strive for it.  But why not do it for
simple settings that occur relatively frequently?  I thought 'loop' would be
such a case, and pretty easy to implement (but I cannot really judge that).

We also have cases like 18EU Paris/Berlin/Vienna, where I already have added
loop="no". If you have no plan to start supporting it soon, my hopeful loop
settings should indeed be removed. 

Erik.

Re: [Rails-devel] Stop properties

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

Erik,

> I think I have not added any setters yet, but I have already mentioned that
> we might need some. In cases like 1851 Birmingham, runTo is in fact
> phase-dependent (although you have probably already solved that with some
> modifier).

Yes that is a GraphModifier that removes Birmingham  from the graph in the 
phases required.

The runTo modifier is a generalization of that (except that it is not phase-
dependent).

> 
> I know, but I had hoped that you would like to add it (apologies for not
> asking so explicitly).
> 
> It's all in the spirit of giving more power to the non-programmers amongst
> us.  Several people have already started implementing games by preparing
> XML, only to find that they have to involve you and me to get the details
> done.  I'm very well aware that we cannot make everything configurable in
> XML, and that it would be silly to strive for it.  But why not do it for
> simple settings that occur relatively frequently?  I thought 'loop' would
> be such a case, and pretty easy to implement (but I cannot really judge
> that).

I am aware and support of other people adding games ;-)
The two important words above are "simple" and/or "frequently". 

However quite often it seems that two games share the same mechanism (most of 
the time because they use the same terminology), but they are substantially 
different in mechanism: For example unfortunately it is not enough to add an 
attribute " merge='yes' " to companies to allow them merging...

So the 1860 example cannot be easily solved by adding the attributes. The 
short explanation is that currently all simple track that only connects the 
scoring vertices are optimized away. It is possible to protect vertices from 
that (for similar cases), however I do not like the idea to protect all track 
vertices as it could be a drag on the revenue calculation, especially as 1860 
has some other rules to consider. So let us wait until we implement that game.

> 
> We also have cases like 18EU Paris/Berlin/Vienna, where I already have
> added loop="no". If you have no plan to start supporting it soon, my
> hopeful loop settings should indeed be removed.

I forgot about that case: If only scoring vertices are meant this is possible.
Maybe we should call this scoreTwice = "no" as it avoids people from thinking 
this is identical to loop (revisit twice).

This would replace the current identical name mechanism. 
However we would still need a mechanism to prevent scoring multiple-hex 
offboard areas twice. I am not sure how you would like to implement that?

I think an off-board area attributes (name, values etc.) should be defined 
only once and then have a list of hexes it refers to.
Then this object could be used directly to create the vertexVisitSet that I 
currently have to create for the algorithm.
But it makes the setup of the hexes harder, but I believe that is the correct 
solution. I could volunteer to implement that.

Stefan

Re: [Rails-devel] Stop properties

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

Stefan,

Thanks for reminding me on how you currently prevent loops by comparing
names - that had completely escaped my mind.
Now I also better understand your need for a Stop getName() method!
Indeed I was already concerned that my current "loop" idea cannot yet handle
the case of multiple-hex off-map areas.

> I am aware and support of other people adding games ;-) The two important
> words above are "simple" and/or "frequently".

Indeed.
 
> However quite often it seems that two games share the same mechanism
> (most of the time because they use the same terminology), but they are
> substantially different in mechanism: For example unfortunately it is not
> enough to add an attribute " merge='yes' " to companies to allow them
> merging...
> 
> So the 1860 example cannot be easily solved by adding the attributes. The
> short explanation is that currently all simple track that only connects
the
> scoring vertices are optimized away. It is possible to protect vertices
from
> that (for similar cases), however I do not like the idea to protect all
track
> vertices as it could be a drag on the revenue calculation, especially as
1860
> has some other rules to consider. So let us wait until we implement that
> game.

I agree.
 
> > We also have cases like 18EU Paris/Berlin/Vienna, where I already have
> > added loop="no". If you have no plan to start supporting it soon, my
> > hopeful loop settings should indeed be removed.
> 
> I forgot about that case: If only scoring vertices are meant this is
possible.
> Maybe we should call this scoreTwice = "no" as it avoids people from
thinking
> this is identical to loop (revisit twice).

Now I'm puzzled. I'm only aware of no-visit-twice cases (which obviously
implies no-score-twice).  Do really cases exist where revisit-twice is
allowed but score-twice is not?
Certainly not 1825 [rule 1.8] and the 18EU metropoles [rule 4.4.3, 6th
bullet point], which are definitely no-revisit cases. Also the routes to
determine 18EU minor connections may not revisit a tile.
Or do I now misunderstand you?
 
> This would replace the current identical name mechanism.

I vaguely remember having opposed to that mechanism before, but I can't find
back the emails about that.

> However we would still need a mechanism to prevent scoring multiple-hex
> offboard areas twice. I am not sure how you would like to implement that?
> 
> I think an off-board area attributes (name, values etc.) should be defined
> only once and then have a list of hexes it refers to.
> Then this object could be used directly to create the vertexVisitSet that
I
> currently have to create for the algorithm.
> But it makes the setup of the hexes harder, but I believe that is the
correct
> solution. 

I fully agree. And it wouldn't be that much harder.  For instance (1830):

<Area id="A9A11" name="Canadian West" value="30,50">
	<Access type="offmap"/>  - the offmap game defaults apply, including
loop="no".
</Area>
...
<Hex name="A9" area="A9A11" .../> - omitting value.

Perhaps we can somehow merge the stops of both tiles, or use one as the
primary stop for the area. 
In the latter case we could even omit the <Area> and have the second offmap
hex refer back to the first (which would be even easier to configure):

<Hex name="A9"/> - as it is now
<Hex name="A11" area="A9"/>  - which would make Hex A11 consider the A9
Station/Stop as its own in all respects, including value and access.

BTW I have long thought that in <Hex> we should rename 'name' to 'id' and
'city' to 'name', but it's probably not worthwhile taking that effort.

> I could volunteer to implement that.

If you like, otherwise I'll try.

Erik.

Re: [Rails-devel] Stop properties

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

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, August 15, 2011 6:25 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Stop properties
> 
> Erik:
> I tried to change my coding in NetworkVertex accordingly.
> Thanks a lot this will simplify the previous code needed to adapt the
revenue
> code to the algorithm code substantially.
> 
> However as usual with coding one realizes some more thing.
> 
> I think having those attributes are one thing, checking if runThrough or
runTo
> is possible still requires more than that.
> 
> The best solution would be adding additional methods for if a runThrough
> and a runTo is possible for a specific company. Thus it also checks the
current
> token situation.
> 
> Thus something like
> 
> public boolean runThroughAllowedFor(PublicCompanyI company) public
> boolean runToAllowedFor(PublicCompanyI company)

Hmm, that does make sense.  

> >From my perspective you could then define the
> isRunToAllowed/isRunThroughAllowed for  as private or even remove it, as
> this is only required internally. Similar for the according methods in
MapHex
> or Tile, they only need to be package private and not public.

On the supposition that we will never subclass MapHex, Stop and Tile. But
that's indeed unlikely.
 
> Even better would be if  you could add similar methods. Then all values
are
> retrieved from the stop object, instead of sometimes querying hex or
station
> instead.
> 
> * public int getValueAt(PhaseI phase)
> Retrieves the current value (either from the related station for
cities/towns
> or via the MapHex for offboard defined values)
> 
> * public String getName()
> Retrieves the name: Either from the hex or if undefined there from the
> related station.
> 
> Again this would allow to restrict access/visibility of a lot of related
methods
> in Stop / Station / MapHex.

I think getName() must be public everywhere - it's used in many ways. 

Ok, this all should be doable, hopefully before I'm going on vacation next
week Wednesday for almost three weeks.  During my vacation you probably
won't hear from me.

Erik.

Re: [Rails-devel] Stop properties

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

Brett & Erik,
maybe a new release should be done this weekend to have all the new games out 
for testing during Erik's vacation?
Stefan


> 
> Ok, this all should be doable, hopefully before I'm going on vacation next
> week Wednesday for almost three weeks.  During my vacation you probably
> won't hear from me.
> 
> Erik.
> 
> 
> 
> 
> ---------------------------------------------------------------------------
> --- uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties

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

I'm fine with doing a release. I'll make the new version tag on
Friday, or as soon as Erik and Stefan confirm a desired tag point.

---Brett.



On Mon, Aug 15, 2011 at 10:12 PM, Stefan Frey <ste...@we...> wrote:
> Brett & Erik,
> maybe a new release should be done this weekend to have all the new games out
> for testing during Erik's vacation?
> Stefan
>
>
>>
>> Ok, this all should be doable, hopefully before I'm going on vacation next
>> week Wednesday for almost three weeks.  During my vacation you probably
>> won't hear from me.
>>
>> Erik.
>>
>>
>>
>>
>> ---------------------------------------------------------------------------
>> --- uberSVN's rich system and user administration capabilities and model
>> configuration take the hassle out of deploying and managing Subversion and
>> the tools developers use with it. Learn more about uberSVN and get a free
>> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Stop properties

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

I'm fine.  
Erik.

> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Tuesday, August 16, 2011 10:25 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Stop properties
> 
> I'm fine with doing a release. I'll make the new version tag on Friday, or as
> soon as Erik and Stefan confirm a desired tag point.
> 
> ---Brett.
> 
> 
> 
> On Mon, Aug 15, 2011 at 10:12 PM, Stefan Frey <ste...@we...>
> wrote:
> > Brett & Erik,
> > maybe a new release should be done this weekend to have all the new
> > games out for testing during Erik's vacation?
> > Stefan
> >
> >
> >>
> >> Ok, this all should be doable, hopefully before I'm going on vacation
> >> next week Wednesday for almost three weeks.  During my vacation you
> >> probably won't hear from me.
> >>
> >> Erik.
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> ------
> >> --- uberSVN's rich system and user administration capabilities and
> >> model configuration take the hassle out of deploying and managing
> >> Subversion and the tools developers use with it. Learn more about
> >> uberSVN and get a free download at:
> >> http://p.sf.net/sfu/wandisco-dev2dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -------- uberSVN's rich system and user administration capabilities
> > and model configuration take the hassle out of deploying and managing
> > Subversion and the tools developers use with it. Learn more about
> > uberSVN and get a free download at:
> > http://p.sf.net/sfu/wandisco-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
> administration capabilities and model configuration. Take the hassle out of
> deploying and managing Subversion and the tools developers use with it.
> http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Release Planning

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

Perfect,
I have nothing to commit now, all tests are running.
Due to the new patch a new game with options can be started.

I only realized that there is an option for a 1830 Reading that is not defined 
in LocalisedText.

Stefan

On Tuesday, August 16, 2011 10:24:46 pm brett lentz wrote:
> I'm fine with doing a release. I'll make the new version tag on
> Friday, or as soon as Erik and Stefan confirm a desired tag point.
> 
> ---Brett.
> 
> On Mon, Aug 15, 2011 at 10:12 PM, Stefan Frey <ste...@we...> wrote:
> > Brett & Erik,
> > maybe a new release should be done this weekend to have all the new games
> > out for testing during Erik's vacation?
> > Stefan
> > 
> >> Ok, this all should be doable, hopefully before I'm going on vacation
> >> next week Wednesday for almost three weeks.  During my vacation you
> >> probably won't hear from me.
> >> 
> >> Erik.
> >> 
> >> 
> >> 
> >> 
> >> ------------------------------------------------------------------------
> >> --- --- uberSVN's rich system and user administration capabilities and
> >> model configuration take the hassle out of deploying and managing
> >> Subversion and the tools developers use with it. Learn more about
> >> uberSVN and get a free download at:
> >>  http://p.sf.net/sfu/wandisco-dev2dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > ----- uberSVN's rich system and user administration capabilities and
> > model configuration take the hassle out of deploying and managing
> > Subversion and the tools developers use with it. Learn more about
> > uberSVN and get a free download at:
> >  http://p.sf.net/sfu/wandisco-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel