Re: [Rails-devel] Tile orientation display

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

Thanks, Stefan, I now better understand what you're after.  Sounds good.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday, July 16, 2011 8:03 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Tile orientation display
> 
> 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
> 
>
----------------------------------------------------------------------------
--
> 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