Game configuration 3: Stop properties

3. Stop properties

3.1. Introduction

Stop properties are about the interaction between trains and stations: if they are allowed to run to and through a station, how they count against the train lengths, and (indirectly) what revenue they gain. These properties are contained in a Java class called Access, and that also is the tag name where these properties, if non-default, are specified.

The values of these properties are static, these do not change during a game. The effect of tokens laid on city stations is therefore not included.

3.2 Properties

The stop properties include:

• type: the stop type defines its properties with respect to train accessibility and revenue counting. There is a fixed set of stop types, that are defined in the enum Stop.Type. The currently available types are: CITY, TOWN, OFFMAP, MINE, PORT and PASS.

• runTo: if trains may run to or from a station as the start- or endpoint of a route. Possible values are: "yes", "no", "tokenonly" and "trains:xxxx". The value "tokenonly" means that access is only granted to a company that has laid a token in that hex (as with the 18Scan offmap cities). A special value is "trains:xxxx" (no spaces), where "xxxx" must indicate one or more train categories (passenger, goods) that are allowed to run to a station. "passenger" is the default and can be omitted if a game has only one train category, as is usually the case. Other names (such as "goods") are not predefined and free to choose. Multiple values after the colon are allowed and should be separated by commas.

• runThrough: if trains may run through a station (if not fully tokened). Possible values are: "yes", "no", "tokenonly" and "always". Again, "tokenonly" means that access is only granted to a company that has laid a token in that hex. This applies to the PRR home station in 1830. "always" allows running through a station even if it is fully tokened.

• mutexId: an arbitrary string that can be used to mark certain stations of which only one may be included in a train route. For instance, in 1837, goods trains may only access one mine. This can be achieved to mark all mines with mutexId="Mine" (or any other string). This property replaces the former property loop, which only restricted running to two stations on the same hex or off-map area. The existing hex property city still performs that same function, mainly used for off-map areas and cities like Berlin in 1835.

• count: the value can be "major", "minor" or "no". Only needed for "+" trains, to count their stops appropriately. "major" applies to stops counting towards the number before the "+", and "minor" similarly to the count after the "+". "no" should be used for ports and such wherever these do not count against the train length. Note: this property was originally named score, but that was a misnomer; revenue scoring is a different subject.

3.3. Specification levels

Access properties can be defined on no less that 7 (seven) levels. Not all of these levels are actually used, but they are available when needed.

The levels are, in order of priority (higher levels trump lower ones):

Specific levels:

1. Per station (the tile-bound equivalent of the hex-bound Stop). This level is useful if two or more stations on a tile have different properties. Examples are the yellow Copenhagen tile in 18Scan, the Venice tiles in 1841 and the ZKB mine hex in 1837. Station access must be included in file TileSet.xml, with an <Access> tag within a <Station> subtag of the relevant <Tile> tag.

2. Per tile, for the properties that apply to all stations on a tile. The <Access> tag should then be placed within the relevant <Tile> tags in TileSet.xml.

3. Per hex, for properties that apply to all stations on tiles being laid on that hex. The <Access> tag should be placed inside the relevant <Hex> tags in Map.xml.

Default levels, for any specific stop type:

4. For all tiles that have stops of a certain type. In this case, <Access> tags per type should be placed in a <Defaults> section directly below the <TileManager> tag in TileSet.xml. This level is not yet used, and not recommended; see level 5.

5. For all tiles on the map that have stops of a certain type. The <Access> tags should be placed in a <Defaults> section below <Map> in Map.xml. This is the recommended method to define default stop properties per stop type.

6. Generic default properties per type. These are hard-coded in class Access for all of the predefined Stop types.

7. If even level 6 fails, the CITY type defaults in class Access are used.

Any property takes the value that is defined on the highest level where it appears in an <Access> tag. As long as it does not appear, it falls through.

3.4. Configuration details