Re: [Rails-devel] 1830 Reading

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

Stefan,

> is there any reason, why you put the driveThroughStation on map.xml
> instead in tile.xml, other than the one discusses previously, that
tiles.xml is
> not game specific?

The reason is that Tiles.xml is generated from the TileDesigner XML export,
via my class ConvertTilesXML.  Any manual tweaks to that output would be
overwritten the next time something changes in the tile set of a game. 

> However the tiles you defined are (very) game specific already.

So far, yes, but please note that runTo and runThrough are intended to
provide a generic solution for all red off-map hexes as well.
[ I wrote this before I saw your inclusion of an old mail of yours below.
See below for further comments.]
See for instance 18Scan, where red hexes can only be run to if tokened,
whereas in 1800 no token is required to run to a similar off-map tile
(although it's coloured white in that game).

> Both from logical and implementation issues I would prefer to define
> attributes of stations in the station tag instead of the hex tag.

I can understand that.  I could answer (not quite seriously), that in this
case we cannot really decide if this is a hex or a tile/station property,
because these preprinted tiles are never upgraded. One wonders if that
non-drivethrough property would survive if an upgrade would exist...   

Although I basically agree with you, I found this way simpler to implement,
at least for this first step.  To do it your way, tile-specific special code
would be needed in ConvertTilesXML. 
See below.

> Coalfields:
> For the coalfield hex a mechanism to buy the coalfield tokens is needed
first.
> Then it is easy to add the adjustment to the revenue calculator via the
static
> modifier approach similar to the bonus tokens.

Yes, that's on my list of things to do Real Soon Now.

> Stefan
> 
> By the way:
> 
> I have thought about similar issues in my mailing last year (04/29/10) on
> "Changes to the Station objects", which cover some more cases due to a
> more general approach.
> 
> A) Each station adds the following (additional) attributes:
> 
> tokenAllows = {RunThrough, RunFrom, NoAccess, N/A} If a token is laid it
> allows to run through, to run from or no access?
> 
> openStationAllows = {RunThrough, RunTo, NoAccess, N/A} If a token is laid
it
> allows to run through, to run to or none?
> 
> closedStationAllows = {RunThrough, RunTo, NoAccess, N/A} If the station is
> fully tokened and the company does not own a token there, what are the
> possibilities?
> 
> To allow an easier definition I suggest to use station type definitions
like the
> company types etc.
> 
> A station is closed if the number of tokens equals the number of slots,
> otherwise it is open.

Except in 1830 Altoona etc.
 
> By this definition a town is always closed, but by setting
closedStationAllows
> to RunThrough that is not an issue.
> 
> B) Different off-board locations:
> There is a substantial variation of different kind of off-board locations.
> There are at least four cases, may be more.
> 
> 1) Standard off-board locations (as in 1830) The off-board areas act as
sinks
> for all companies.
> No tokens allowed.
> (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows = RunTo)
> 
> 2) Tokenable off-board locations (example: SP base in 1870) A base token
can
> be layed in at least one of the areas.
> The rules claim that off-board areas are still sink for all companies,
except for
> the company with a token which can start a train there.
> But it cannot run its trains through the hex (thus SP cannot have the same
> train enter from NE and then continue to the E).
> 
> (tokenAllows = RunFrom, openStationAllows = RunTo, closedStationAllows =
> RunTo)
> 
> 3) Run-through off-board locations (as Hamburg in 18EU) A non-tokenable
> station (similar to towns), that allows running through it.
> 
> (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows =
> RunThrough)
> 
> And another from an non-implemented game:
> 4) Tokenable run-to off-board locations (as in 18Scan) Here a base-token
is
> needed to run to the station.
> 
> (tokenAllows = RunFrom, openStationAllows = NoAccess ,
> closedStationAllows =
> NoAccess)
> 
> In  general a station is fully tokened if the nb of slots equals the nb of
tokens.
> This implies that (default) towns are fully tokened (0=0), but the
> fullyTokened attribute would be set to RunThrough.
> 
> StationTypes should be added to provide defaults.
> 
> C) Other new station attributes
> runStationType = {Major, Minor}
> Is it counted as city-type or town-type for plus-trains and
express-trains?
> 
> name = {...}
> I would like to add is a "name" attribute for stations on tiles. Identical
names
> would imply that those stations are mutually exclusive for train runs.
They
> would be automatically added to the list of exclusions to the revenue
> calculator.

Apologies that I did not remember this old mail of yours, and that I
(probably) never responded to it.  So you had already thought through these
matters long before I did.

All fine with me, but the catch still is that we cannot use Tiles.xml to
define all these details. As long as we have to live with the limitations of
TileDesigner, we only can use TileSet.xml and Map.xml to define such
details.  I must insist upon that.  

I now tend to think that we can best use TileSet.xml, as that is the place
where we define ALL tile properties that TileDesginer cannot give us.  And
for off-map hexes, this way it's only needed once per red tile type, instead
of once per red hex. 

Tiles.xml and TileSet.xml are parsed simultaneously, and in that process the
contents of both files are effectively merged into the single Tile class and
its related Track and Station classes.  So it's easy to propagate properties
from TileSet.xml to the Stations.

I propose to add a <Station> tag to TileSet.xml and define any such special
station properties there. In the unlikely case of multiple stations with
different properties, we can use the (badly named) city number.

Erik.