Re: [Rails-devel] Tile orientation display

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

> The point of a canonical orientation is that there is only one (if there is
> more than one, such as for tile #9, then they are indistinguishable for all
> purposes).  I'm not sure which canonical rules you are referring to, but in
> the one I proposed (and use) there is exactly one possible base orientation
> for #25, which is branches from D to B and F.  You have other cases that
> have to be dealt with in the canonical rules, such as when there is internal
> connectivity, such as between multiple city clusters and external exits, but
> it is easy enough to extend the canonicalization rules to accomodate those.
> 
John,
thanks for the clarification.

I referred to the definition from the 18xx yahoo message Erik pointed to 
(copied below).

I now understand my mistake:
The vertical axis of 3) runs perpendicular from the middle of side D to the 
middle of side A, instead of my understanding that it refers to the "diagonal" 
going from the corner between D/E to the corner A/B.
But I am still wondering about the wording of 3) as it refers only to the 
symmetry of the exits, not of the track configuration. 

I checked the discussion thread again, and John David Galt came up with a good 
solution for that:

2.5) if the track on a tile is a "switch" (like a tree where one "trunk"
splits into two or more "branches"), the D position is always the "trunk".
If the tile has multiple "switches" on it, D must be one of the "trunks".

Depending on the orientation (hex standing on the base D or balancing of the 
corner between D/E) "vertical axis" can vary. 
I used 
http://www.fwtwr.com/18xx/maps_tile_sheets/1830_ts1.htm
to check the definition and got confused by that.

Is there are another definition that describes the same configuration that is 
better suited for programming instead of having to check for symmetry against 
the vertical axis?

My current proposal for an algorithm of the canonical orientation is the 
following:

W can gladly ignore 1) as the orientation will be for a general database of 
tiles, not a game specific one (this is taken care somewhere else).

On first glance it seems that assigning points (think binary if you like) to 
the exits or exit combinations ensures the rules.

2) Exit at D = 10000
2.5) Two tracks ending at D = 1000
3) Exits at A&D = 100
3) Exits at B&E = 100
3) Exits at C&F = 100
4+5) Exit at C= 11
4) Exit at A = 10
4) Exit at B = 10

The prefix x) refers to the rule covered by assigning points.

Stefan

John's Definition copied here:

1) if a tile may only be played on a specific place on the map in a
specific orientation, orient the tile so that up on the tile reflects up
on the map.
2) one exit must be in the D position
3) if the exits can be arranged such that they are symmetrical across the
vertical axis, it must be arranged so.
4) if the exits can be arranged to only be on A, B, C, and D, it must be
arranged so.
5) prefer orientations that leave B empty over ones that leave C empty.

And JDG's definition again:

2.5) if the track on a tile is a "switch" (like a tree where one "trunk"
splits into two or more "branches"), the D position is always the "trunk".
If the tile has multiple "switches" on it, D must be one of the "trunks".