Re: [Rails-devel] Tile orientation display

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> -----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