Re: [Rails-devel] Tile orientation display

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

Erik:
imho the canonical orientation intends to solve same issue, however it uses a 
different algorithm, thus there will be different orientations.

And it seems that it does not orientate tile 25 (switch with two broad curves) 
uniquely: There are three configurations that have identical position of the 
exits: The switch can either be in position D, F or B, however exits are still 
always B, D and F.
This problem arises for all tiles with symmetrical exits, but asymmetrical 
tracks.
But maybe I have misunderstood something there (likely given the expertise of 
the discussants).

For neither mine nor the canonical one the reference point is important and 
can be chosen.

In any case the re-orientation will be done by programming code, not by 
editing all tiles with the TileDesigner ;-) I never intended to propose that. 
What a horrible idea ...

The idea is to create an (base)orientation-attribute like you suggested 
previously, but not manually.

Stefan


The canonical orientation copied here for reference:

>> As I went through tiles, I came up with new rules and simplified some
>> others, so there is still much to be done to get the entire tile database
>> consistent with these rules (orientations for flat-bottom tiles are A at
>> the top, following clockwise from there -- flat-side tiles are rotated 30
>> degrees [ie, A is northeast and F is northwest]).
>>
>> 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.





On Thursday, July 14, 2011 11:09:23 am Erik Vos wrote:
> Stefan,
> 
> Thanks for the clarification (I didn't find it irritating, but missed the
> background).
> 
> About the "natural" tile orientation: there has been a similar discussion
> in the [18xx] group a few months ago.  See message #31521, where Scott
> pointed to John Tamplin's "canonical orientation" and Steve Thomas
> commented upon that.  Could it be beneficial to align with that proposal?
> 
> The trouble with any standard tile orientation that is different from the
> usual ones (with the number at S or SW), is that it is meaningless to
> anyone who has not internalized the algorithm to define it (and I would
> have trouble doing that).  To fix that, we would need to change all tile
> rotations in TileDesigner to align with the new rule.  That's not
> impossible, but a lot of work...
> 
> I hope I'm still understanding you right...
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Thursday, July 14, 2011 7:38 AM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Tile orientation display
> > 
> > Edward & Erik,
> > 
> > sorry for the (irritating) mail: Erik guessed right, this was a  copy
> > from
> 
> a more
> 
> > extended document about my thoughts to create the complete logic for tile
> > laying and upgrading. This would prevent any illegal tile-lay and thus
> 
> needs to
> 
> > consider the various upgrade rules (permissive, semi-restrictive and
> > restrictive) and cope with all the little details the human mind can
> 
> easily
> 
> > solve, but are difficult for an algorithm.
> > 
> > This is not yet finished as I am not satisfied with neither the text nor
> 
> the
> 
> > proposed design. And it would require a substantial rewrote of the UI,
> 
> which
> 
> > I would delay until it is decided which client/server model and what kind
> 
> of
> 
> > (mobile) devices Rails will support in the future.
> > 
> > However what I proposed below is a (very simple) rule to create a natural
> > orientation of each tile, which is only defined by the actual track
> > configuration of the tile. This avoids arbitrary rules like the location
> 
> of tile id,
> 
> > which result in different orientations of the same tile between different
> 
> 18xx
> 
> > titles (or even inside one game as reported on the yahoo list).
> > 
> > Another advantage is that allows someone to redraw/redesign the artwork
> > of the tile and then the algorithm would still define the same base
> 
> rotation.
> 
> > Other than this the rule makes my (yet unpublished) algorithm to choose
> 
> the
> 
> > allowed upgrade rotations more efficient and is part of the problem to
> > identify symmetric orientations (there are only 3 possible orientations
> 
> for the
> 
> > straight line, not 6). But that part was impossible to understand without
> 
> the
> 
> > context.
> > 
> > Stefan
> > 
> > On Wednesday, July 13, 2011 11:30:12 am Erik Vos wrote:
> > > Thinking about it (I should do that more often :-), Stefan is probably
> > > working on making the rotation logic route-aware (as in: "some new
> > > track must be part of a valid route" and all its variations). The
> > > current code isn't.
> > > 
> > > Erik.
> > > 
> > > > -----Original Message-----
> > > > From: Erik Vos [mailto:eri...@xs...]
> > > > Sent: Wednesday, July 13, 2011 10:02 AM
> > > > To: 'Development list for Rails: an 18xx game'
> > > > Subject: Re: [Rails-devel] Tile orientation display
> > > > 
> > > > > -----Original Message-----
> > > > > From: Edward S. Rustin [mailto:ed...@we...]
> > > > > 
> > > > > Having read all that, I do have to wonder about one thing - what's
> > > > > the problem you're trying to solve?
> > > > 
> > > > That also was my first question. I can imagine that some clever
> > > > algorithm would make it easier to determine the valid rotations of a
> 
> laid
> 
> > tile.
> > 
> > > > Currently that's pretty messy code of my making (see
> > > > GUITile.rotate()),
> > > 
> > > and
> > > 
> > > > if Stefan sees ways to improve/simplify that, I'm all for it.
> > > > 
> > > > Unfortunately, I don't yet see how Stefan's calculations would
> > > > improve the situation, so I can't provide any more substantial
> > 
> > commentary.
> > 
> > > > The allowed rotations of tiles #64-68 (the tile #59 upgrades) were
> > > > hardest
> > > 
> > > to
> > > 
> > > > get right, so that's a main test case.
> > > > 
> > > > > It might just be my lack of knowledge about Rails (although I've
> > > > > been
> > > > 
> > > > picking
> > > > 
> > > > > some up here and there from lurking on here and prodding the
> > > > > source), but I'm really not sure what the purpose of your
> > > > > algorithm is. Surely for any
> > > > 
> > > > given
> > > > 
> > > > > 18xx game, there's a specified upgrade path where Tile X can be
> > > > > upgraded
> > > > 
> > > > to
> > > > 
> > > > > Tile Y or Tile Z, and there's only going to be a few unique
> > > > > mappings based
> > > > 
> > > > on
> > > > 
> > > > > orientation.
> > > > > 
> > > > > As a side point, your algorithm might work better were you to
> > > > > enumerate the sides as 1, 2, 4, 8, 16, 32 (ie make it a six bit
> > > > > binary
> > > > > value) so that you avoid the problem of two different tiles having
> > > > > the
> > > > 
> > > > same
> > > > 
> > > > > value (a tile with exits at 1, 2, 5 has the same value as one with
> > > > > exits
> > > > 
> > > > at 1, 3, 4
> > > > 
> > > > > for example).
> > > > 
> > > > Another side point: as we currently use S/SW=0, wouldn't it be less
> > > 
> > > confusing
> > > 
> > > > to stick with that start point for side numbering? Or doesn't it
> > > > make a difference?
> > > > 
> > > > > On Wed, Jul 13, 2011 at 06:55, Stefan Frey <ste...@we...>
> > 
> > wrote:
> > > > > > Somehow related to the discussion and I would be happy to hear
> > > > > > suggestions and comments on that problem:
> > > > > > 
> > > > > > After finishing the RevenueCalculation algorithms I started to
> > > > > > design/outline the workflow of an UpgradeTile algorithm.
> > > > > > 
> > > > > > To make this efficient I intended to make the base rotation of
> > > > > > all tiles such that it allows the upgrades to fit with minimal
> 
> rotations.
> 
> > > > > > What is the idea behind this? Take the example how Keith
> > > > > > Thomasson built his tile sheets for postal play.
> > > > > > 
> > > > > > Check the tile sheet of:
> > > > > > http://www.fwtwr.com/18xx/maps_tile_sheets/1830_ts1.htm
> > > > > > It seems that in many cases those tiles are already orientated
> > > > > > to allow for easy upgrades:
> > > > > > 
> > > > > > Define Facing 1 as the base rotation of an tile. Then it is the
> > > > > > case for example for an upgrade from tile 8 to tiles 19, 24, 29
> > > > > > the possible upgrade will keep facings identical (thus no
> > > > > > rotation of the upgraded tiles is required). To upgrade to tile
> > > > > > 16 and 25 one of the possible upgrades has identical facings.
> > > > > > 
> > > > > > So I came up with the idea if there is a solution that allows to
> > > > > > define an algorithm that defines a base rotations for all tiles
> > > > > > such that upgrades can be done with only a few rotations.
> > > > > > 
> > > > > > At that time my idea was the following:
> > > > > > Id each hex side (for the example start with NW = 0, NE = 1, ...
> > > > > > , W =
> > > > > > 5)
> > > > > > 
> > > > > > A) Then sum up the id of all sides with at least one track
> > > > > > leading to it. Call that X. Compare each possible facing and
> > > > > > choose that with minimal X as the base rotation.
> > > > > > 
> > > > > > It is easy to check that tiles 7, 8 and 9 are optimal rotated
> > > > > > given in that definition (and starting id=0 from NW).
> > > > > > 
> > > > > > It is also the case for 16, 18, 19. However not for 20 (facing 2
> > > > > > has minimal ids), and 23 (here facing 4), but again for 24.
> > > > > > 
> > > > > > For tile 25 facing 1 and 3 have the same X. So a secondary
> > > > > > criteria would be helpful. Thus
> > > > > > 
> > > > > > B) Sum up the ids of all tracks => Y So given same X, then
> > > > > > choose minimal Y as the base rotation.
> > > > > > 
> > > > > > 25 has two tracks: Facing 1 has tracks from id=0 to id=2 and
> > > > > > from
> > > > > > id=0 to id=4, thus Y = 6. Facing 3 has tracks from id=0 to id=2
> > > > > > and from
> > > > > > id=2 to id=4 thus Y=8.
> > > > > > 
> > > > > > C) What about tiles with stations on it? If you have only one
> > > > > > station which is connected to all tracks you can easily rely on
> > > 
> > > ranking by X:
> > > > > > 57, 15, 53 have optimal facings, for 14 facing 2 is minimal.
> > > > > > 
> > > > > > If you have two stations the minimal rotation is always found by
> > > > > > ranking with X and Y as long as the stations have identical
> > > > > > attributes and number of tracks.
> > > > > > 
> > > > > > However in other cases it can get more difficult and one still
> > > > > > has to fall back to some base rotation defined in the master
> 
> database.
> 
> > > > > > (One Example is tile 11 in
> > 
> > http://www.fwtwr.com/18xx/maps_tile_sheets/1825u123r123k1356_ts1.ht
> > 
> > > > > m
> > > > > 
> > > > > > ). Facing 1, 3 and 5 have same X and Y.
> > > > > > 
> > > > > > Related to this is he issue of symmetry: For example tile 9 has
> > > > > > a potential facing 4 (which is the rotation by 180 degree, but
> > > > > > as tile
> > > > > > 9 has exactly a symmetry there, this facing can ignored). So
> > > > > > identity in X and Y is a necessary condition for symmetry. For
> > > > > > the
> > > > > > 1830 tile set it is also a sufficient condition (as far as I
> > > > > > have checked, correct me if I am wrong)
> > > > > > 
> > > > > > In general the identity of X and Y is not a sufficient condition
> > > > > > for all
> > > > > > (existing) 18xx tiles (see example above) and if someone
> > > > > > proposes an algorithm that covers more cases than mine I would be
> > 
> > very grateful.
> > 
> > > > > > But for my case (an efficient algorithm) a necessary condition
> > > > > > that is easy to calculate is already very helpful as the more
> > > > > > complex check is only needed for those cases not eliminated by
> > > > > > the simple one (similar to a hash code to test equality).
> > > > > > 
> > > > > > On Tuesday, July 12, 2011 07:57:14 pm Erik Vos wrote:
> > > > > >> The currently ongoing discussion in the [18xx] group on how to
> > > > > >> describe tile lays is also of interest for Rails.  I'm in
> > > > > >> particular referring to cases where the Rails (TileDesigner)
> > > > > >> tile orientation (i.e., the tile number placement)  is
> > > > > >> different from the physical game. I just checked
> > > > > >> 1830 and 1856. The 1830 tile orientations are the same as in
> > > > > >> Rails (except tile #65), whereas with 1856 there are many
> > 
> > differences.
> > 
> > > > > >> Take tile #23 as an example. The 1856 orientation of this tile
> > > > > >> is upside-down as compared with 1830 and Rails.  Now assume
> > > > > >> tile #9 has been laid before on hex O10 (connecting SW-NE) and
> > > > > >> is upgraded to tile #23 (adding a connection NW-NE).  Now the
> > > > > >> question is: how to display this upgrade in the map window and
> 
> the
> 
> > game report?
> > 
> > > > > >> The Rails tile has the number as in 1830, on the SW side in
> > > > > >> this case, so the upgrade is now coded as #23/O10/SW.  However,
> > > > > >> the physical tile would have its number on the NE side, so in
> > > > > >> an FTF game the upgrade would be denoted as #23/O10/NE.
> > > > > >> 
> > > > > >> My question is: what do we prefer?
> > > > > >> 
> > > > > >> I am thinking on adding an optional attribute to <Tile> in
> > > > > >> TileSet.xml that specifies the 'base rotation' of the physical
> > > > > >> tile as compared with the Rails tile (or vice versa). This
> > > > > >> 'base rotation' would then be added (or
> > > > > >> subtracted) to the internal value to calculate the displayed
> > > > > >> tile orientation.
> > > > > >> 
> > > > > >> So, to make the laid tile in this example be described as
> > > > > >> #23/O10/NE we should add an attribute like 'baseRotation="3"'.
> > > > > >> 
> > > > > >> Any need for this feature? Should it  be an option?
> > > > > >> 
> > > > > >> Erik.
> > > > > >> 
> > > > > >> 
> > > > > >> ---------------------------------------------------------------
> > > > > >> ----
> > > > > >> --
> > > > > >> ------
> > > > > >> --- AppSumo Presents a FREE Video for the SourceForge Community
> > > > > >> by Eric Ries, the creator of the Lean Startup Methodology on
> > > > > >> "Lean Startup Secrets Revealed." This video shows you how to
> > > > > >> validate your ideas, optimize your ideas and identify your
> 
> business
> 
> > strategy.
> > 
> > > > > >> http://p.sf.net/sfu/appsumosfdev2dev
> > > > > >> _______________________________________________
> > > > > >> Rails-devel mailing list
> > > > > >> Rai...@li...
> > > > > >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > > > > 
> > > > > > ----------------------------------------------------------------
> > > > > > ----
> > > > > > --
> > > > > > -------- AppSumo Presents a FREE Video for the SourceForge
> > > > > > Community by Eric Ries, the creator of the Lean Startup
> > > > > > Methodology on "Lean Startup Secrets Revealed." This video shows
> > > > > > you how to validate your ideas, optimize your ideas and identify
> 
> your
> 
> > business strategy.
> > 
> > > > > > http://p.sf.net/sfu/appsumosfdev2dev
> > > > > > _______________________________________________
> > > > > > Rails-devel mailing list
> > > > > > Rai...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > 
> > > ----------------------------------------------------------------------
> > > -----
> > > -
> > > 
> > > > --
> > > > 
> > > > > AppSumo Presents a FREE Video for the SourceForge Community by
> > > > > Eric Ries, the creator of the Lean Startup Methodology on "Lean
> > > > > Startup Secrets Revealed." This video shows you how to validate
> > > > > your ideas, optimize your ideas and identify your business
> > > > > strategy. http://p.sf.net/sfu/appsumosfdev2dev
> > > > > _______________________________________________
> > > > > Rails-devel mailing list
> > > > > Rai...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > 
> > > ----------------------------------------------------------------------
> > > -----
> > > - --
> > > 
> > > > AppSumo Presents a FREE Video for the SourceForge Community by Eric
> > > > Ries, the creator of the Lean Startup Methodology on "Lean Startup
> > > > Secrets Revealed." This video shows you how to validate your ideas,
> > > > optimize your ideas and identify your business strategy.
> > > > http://p.sf.net/sfu/appsumosfdev2dev
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > 
> > > ----------------------------------------------------------------------
> > > -----
> > > --- AppSumo Presents a FREE Video for the SourceForge Community by
> > > Eric Ries, the creator of the Lean Startup Methodology on "Lean
> > > Startup Secrets Revealed." This video shows you how to validate your
> > > ideas, optimize your ideas and identify your business strategy.
> > > http://p.sf.net/sfu/appsumosfdev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> - --
> 
> > AppSumo Presents a FREE Video for the SourceForge Community by Eric
> > Ries, the creator of the Lean Startup Methodology on "Lean Startup
> > Secrets Revealed." This video shows you how to validate your ideas,
> > optimize your ideas and identify your business strategy.
> > http://p.sf.net/sfu/appsumosfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets
> Revealed." This video shows you how to validate your ideas, optimize your
> ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel