Re: [Rails-devel] Running to and through stations

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

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> 
> A. City vs. HexStation:
> Actually I got used to City and Station by now, but the main issue still
is to
> explain that strongly. The best is that a City or HexStation exists for
each
> city/station on the map, whereas there is only one Station per TileId. The
> major consequence is that token can only live on City/HexStation, but
never
> on Stations.

Exactly. 
 
> B. List of attributes
> I do not care so much about the precise attributes, as long as the
> suggestions/requirements below are considered. I can live with any of
those
> you suggested below.
> 
> C. Station Types
> Use the same pattern to define types as for trains and companies.
> Example:
> <StationType name="OffBoard" runThrough="no" runTo="yes"
> type="major" > <StationType name="City" runThrough="token"
> runTo="yes"  type="major" > <StationType name="Town" runThrough="yes"
> runTo="yes"  type="minor" >

Yes, that is what we called the "defaults", right?

> Allow modifications of inidividual attributes on the ajdustable
TileSet.xml
> (Suggestion rename that to GameTiles.xml, I can never remember which one
> is the game specific one) and Map.xml, with Map.xml taking precedence.

GameTiles.xml  would be fine with me.

> D. Keep decision tree manageable
> Keep in mind that the conditions to check should be not to difficult to
> evaluate.
> 
> The current code to decide if a station is a sink (cannot be run-through)
is the
> following: (from NetworkVertex initRailsVertex)
> 
> 		// station is offboard area
> 	if (station.getType().equals(Station.OFF_MAP_AREA) || (
>                 // or station is city
>                 station.getType().equals(Station.CITY)
>                 // and is either fully tokened and has token slots or only
tokens allow
> run through
>                 && ( city.getSlots() != 0 && !city.hasTokenSlotsLeft() ||
> hex.isRunThroughAllowed() == MapHex.Run.TOKENONLY)
>                 // and city does not have a token
>                 && !city.hasTokenOf(company))
>                 ) {
> 
> So it is still manageable, but it should not get more complex. And
replacing
> the hard-coded station-types by the new variable one suggested in C would
> make things easier on several places in the code base. However it will
require
> identifying those cases.

Some complexity can't be avoided, but the intention is to keep it as simple
as possible indeed. I think you can best judge this aspect, and that why I'm
trying to define this whole thing as completely as possible before starting
to code.

In my view, HexStation would be responsible to collect all data about a
train stop, so that would be your main entry point.
However, these properties would also be directly obtainable from Tile and
Hex. You'll need that in some cases.

A few special cases that I have on my mind, and that are perhaps worth
thinking about already in this stage:

- 1860: loop="no" would apply to all tiles, also plain track, so there you
can't just use HexStation. Not sure how to configure this case.

- 18VA: I would use type="mine" for the CMDs, and type="minor" for the mines
(which look like, and in fact are, towns in all respects but the name).
This usage of type="mine" would be in line with e.g. 1837.

- Several games have "ports", but I believe in almost all cases these behave
exactly like towns, so I'm not sure we need that as a separate type. The
18VA ports are not separate train stops but bonuses for the nearby cities if
tokened, so I think these ports should be treated differently.

There is probably much more, but I have given up to keep up with all newest
games.

Erik.