rails-devel — List for discussion of Rails development

Re: [Rails-devel] 1835 playtest report - Rails 1.4.2

[Phil D. <de...@gm...>]

I'd definitely second this as something that needs thinking about

On 13 July 2011 06:31, John David Galt <jd...@di...> wrote:
> 4. While I haven't exhaustively tested the different combinations of buying
> and selling certificates in companies that have more than one size, the
> obvious bugs there appear fixed.  However, the display still does not show
> which certificates each player has (and it's often important to know,
> especially if you're considering nationalizing the big one).  I suggest a
> tooltip showing this information when you hover over that player's holding.

Differing size certs is an issue that rails is going to have with it's
display as it only denotes share allowance and who is the president.
This is fine for usually 20% P share and 8*10% shares but 1835 does
get confusing as it's easy to forget who has which niggly little 5%
share floating around.  I'm not sure a tooltip is the easiest answer -
something that can be displayed clearer in the UI might be better but
I'm unsure how to achieve that.  Perhaps a small number in parenthesis
next to the share count that states the cert count for that
corporation? Then a tooltip could give you an exact breakdown of that
share distribution perhaps?

Re: [Rails-devel] Tile orientation display

[Edward S. R. <ed...@we...>]

Having read all that, I do have to wonder about one thing - what's the
problem you're trying to solve?

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

My two cents anyway, feel free to ignore if I've got no idea what I'm
talking about!

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.htm
> ). 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
>

Re: [Rails-devel] Tile orientation display

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

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.htm
). 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

[Rails-devel] 1835 playtest report - Rails 1.4.2

[John D. G. <jd...@di...>]

Most of the bugs I found in earlier versions are now gone, and I was able
to play the game through to the end.

These problems still exist.

1. Map still doesn't show which cities are "Y" or "XX".

2. During and after the starting round, it would be helpful to see what
percentage of the Prussian each player holds (that is, including shares
they will eventually receive in exchange for privates/minors now owned).
I suggest this be shown in (parentheses) in the Pr row of the table.

3. When the 4+4 train is purchased (after the Prussian has formed), all
players get asked whether to convert our remaining minors.  (This is only
supposed to happen (a) when the M2 converts, thus forming the Prussian, or
(b) at the beginnings of rounds.  Thus we should not be asked upon the 4+4
purchase unless the owner of M2 declined all earlier opportunities to form
the Prussian and so is forced to form it then.)

4. While I haven't exhaustively tested the different combinations of buying
and selling certificates in companies that have more than one size, the
obvious bugs there appear fixed.  However, the display still does not show
which certificates each player has (and it's often important to know,
especially if you're considering nationalizing the big one).  I suggest a
tooltip showing this information when you hover over that player's holding.

5. The train limit for most major companies gets reduced to two, and I am
forced to discard one, upon the 4+4-train purchase.  This is not supposed
to happen until the first 5-train purchase.

6. When I was forced to purchase a train using money out of hand, the
program forced me to buy the 3 from the bank pool rather than the 6 which
is the next new train for sale.  I believe I am supposed to be allowed to
buy the 6-train.

Re: [Rails-devel] Tile orientation display

[Phil D. <de...@gm...>]

I'm with Scott and Chris, i find most orientation statements end up confusing someone and you need to clarify it in more verbose text so I'm not especially bothered if rails is internally consisten

Phil

On 12 Jul 2011, at 19:17, Scott Petersen <sc...@re...> wrote:

> On Tue, Jul 12, 2011 at 1:13 PM, Chris Shaffer <chr...@gm...> wrote:
> To be honest, as a player, I don't care.  When I use CyberBoard and Rails, I don't bother specifying tile orientation in text.  As long as there is a system that can be derived from the log, it's fine with me.
>  
> I agree with this.  Since the entire game is contained within Rails, there is no strong need to have a uniform system.  
> 
> Also note that there are some games that have the tile number printed on a corner, not an edge.  I believe DTG's 1826 and 1846 are like this.
> ------------------------------------------------------------------------------
> 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

Re: [Rails-devel] Tile orientation display

[brett l. <bre...@gm...>]

If it's as easy as specifying the starting rotation in the XML, that
shouldn't be too cumbersome and appears to be a usability win (for
users mapping the physical game to the digital game).

It sounds useful to me. :)

---Brett.



On Tue, Jul 12, 2011 at 10:57 AM, Erik Vos <eri...@xs...> 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
>

Re: [Rails-devel] Tile orientation display

[Scott P. <sc...@re...>]

On Tue, Jul 12, 2011 at 1:13 PM, Chris Shaffer <chr...@gm...>wrote:

> To be honest, as a player, I don't care.  When I use CyberBoard and Rails,
> I don't bother specifying tile orientation in text.  As long as there is a
> system that can be derived from the log, it's fine with me.


I agree with this.  Since the entire game is contained within Rails, there
is no strong need to have a uniform system.

Also note that there are some games that have the tile number printed on a
corner, not an edge.  I believe DTG's 1826 and 1846 are like this.

Re: [Rails-devel] Tile orientation display

[Chris S. <chr...@gm...>]

To be honest, as a player, I don't care.  When I use CyberBoard and Rails, I
don't bother specifying tile orientation in text.  As long as there is a
system that can be derived from the log, it's fine with me.

--
Chris

Please consider the environment before printing this e-mail.


On Tue, Jul 12, 2011 at 10:57 AM, Erik Vos <eri...@xs...> 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
>

Re: [Rails-devel] Tile orientation display

[John A. T. <ja...@ja...>]

On Tue, Jul 12, 2011 at 1:57 PM, Erik Vos <eri...@xs...> 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?
>

Some games are not even consistent within that game (I don't remember which
ones, but there was a discussion on the 18xx group many years ago) -- the
same tile number can have the tile number in two different positions --
either KT or ST should be able to talk about it since they both run lots of
PBeM games.  However, that is hard to deal with anyway, since you have to
know which one of the different ones was played.

If you really want to support different orientations per game, I suggest
simply having the per-game tile manifest will provide a rotation for the
tile number only (or equivalently everything but the tile number), so it can
be made to match the tiles supplied in the game.  If the rotation isn't
supplied, the game uses the orientation in the master tile database.

-- 
John A. Tamplin

[Rails-devel] Tile orientation display

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

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.

Re: [Rails-devel] Are we ready for Git?

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

That would be great.  Thanks.
Erik.

> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Monday, July 11, 2011 9:45 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Are we ready for Git?
> 
> I'll work on it this week.  This coming weekend should be a good target for
> the cutover.
> 
> ---Brett.
> 
> 
> 
> On Mon, Jul 11, 2011 at 12:32 PM, Erik Vos <eri...@xs...> wrote:
> > OK, it seems we are ready then for the switchover.
> >
> > Brett, when do you think you can have rebuilt the Git repo at Sourceforge?
> > I suppose it's better to create a fresh new repository than to do a
> > massive update to get the current old one up to date.
> >
> > Erik.
> >
> >> -----Original Message-----
> >> From: Phil Davies [mailto:de...@gm...]
> >> Sent: Monday, July 11, 2011 10:56 AM
> >> To: Development list for Rails: an 18xx game
> >> Subject: Re: [Rails-devel] Are we ready for Git?
> >>
> >> As far as I'm concerned it's really Brett, Erik and Stefan's decision
> > being the
> >> primary contributors to the project.  IntelliJ has a Git plugin so
> >> I'm
> > sure I'll
> >> work it out :)
> >>
> >> Phil
> >>
> >> On 11 July 2011 06:04, Stefan Frey <ste...@we...> wrote:
> >> > Erik & Brett,
> >> > given that you both had some long-time hands-on-experience with
> >> > Maven (compared to my third-party recommendation and a short
> >> > try-out) I agree to stay with the current setup.
> >> > I had not tested EGit/JGit before, thus I considered them as
> >> > competing products similar to the svn-support in eclipse ;-) Stefan
> >> >
> >> > On Sunday, July 10, 2011 07:08:05 pm brett lentz wrote:
> >> >> On Sun, Jul 10, 2011 at 9:24 AM, Erik Vos <eri...@xs...> wrote:
> >> >> >> -----Original Message-----
> >> >> >> From: Stefan Frey [mailto:ste...@we...]
> >> >> >> Sent: Sunday, July 10, 2011 2:42 PM
> >> >> >> To: Development list for Rails: an 18xx game
> >> >> >> Subject: Re: [Rails-devel] Are we ready for Git?
> >> >> >>
> >> >> >> Erik & Brett,
> >> >> >> I am up for that move. Do you recommend JGit or Egit?
> >> >> >
> >> >> > AFAIK you need both (in Eclipse).
> >> >>
> >> >> Correct.
> >> >>
> >> >> JGit is the java git implementation.
> >> >> EGit is the eclipse plugin built on top of JGit.
> >> >>
> >> >> >> I am wondering if you would consider to move to a maven  build
> >> >> >> at the same time. Ideally by changing to the maven recommended
> >> >> >> repo
> >> layout.
> >> >> >
> >> >> > Dunno. Brett is handling the builds (I only run either from
> >> >> > Eclipse Run or from the published Rails jars).
> >> >> >
> >> >> > I hardly know anything about Maven. In the past I have been
> >> >> > half-involved with some (old) projects that used Maven, and
> >> >> > perhaps
> >> some other stuff.
> >> >> > What I remember about these projects was the ubiquitous presence
> >> >> > of pom.xml files that did not mean anything to me (I wasn't
> >> >> > really interested either - it worked). So I'm blank.
> >> >>
> >> >> I deal with Maven at my day job, and I'm not a fan. Perhaps as
> >> >> Maven
> >> >> 3 matures, it will improve in crucial areas. Right now, I really
> >> >> dislike the way it handles dependency resolution, among other things.
> >> >>
> >> >> > Perhaps we'll better restrict ourselves to one major step at a time?
> >> >>
> >> >> Agreed.
> >> >>
> >> >> > One thing on our Git repo that I have struggled with yesterday
> >> >> > is that it seems to require that the .git directory would exist
> >> >> > at the same level as all project directories (game, tile, data
> >> >> > etc.).  I was trying to get these directories below a src
> >> >> > directory on the same level as .git (under the project root),
> >> >> > but failed  to get there. Not really a problem, but perhaps
> noteworthy.
> >> >> >
> >> >> > Erik.
> >> >>
> >> >> ---Brett.
> >> >>
> >> >> ------------------------------------------------------------------
> >> >> ---
> >> >> ------
> >> >> --- All of the data generated in your IT infrastructure is
> >> >> seriously valuable. Why? It contains a definitive record of
> >> >> application performance, security threats, fraudulent activity,
> >> >> and more. Splunk takes this data and makes sense of it. IT sense. And
> common sense.
> >> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> >> _______________________________________________
> >> >> Rails-devel mailing list
> >> >> Rai...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >
> >> > -------------------------------------------------------------------
> >> > ---
> >> > -------- All of the data generated in your IT infrastructure is
> >> > seriously valuable.
> >> > Why? It contains a definitive record of application performance,
> >> > security threats, fraudulent activity, and more. Splunk takes this
> >> > data and makes sense of it. IT sense. And common sense.
> >> > http://p.sf.net/sfu/splunk-d2d-c2
> >> > _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >
> >>
> >>
> > ----------------------------------------------------------------------
> > ------
> > --
> >> All of the data generated in your IT infrastructure is seriously valuable.
> >> Why? It contains a definitive record of application performance,
> >> security threats, fraudulent activity, and more. Splunk takes this
> >> data and makes sense of it. IT sense. And common sense.
> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > ----------------------------------------------------------------------
> > -------- All of the data generated in your IT infrastructure is
> > seriously valuable.
> > Why? It contains a definitive record of application performance,
> > security threats, fraudulent activity, and more. Splunk takes this
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Are we ready for Git?

[brett l. <bre...@gm...>]

I'll work on it this week.  This coming weekend should be a good
target for the cutover.

---Brett.



On Mon, Jul 11, 2011 at 12:32 PM, Erik Vos <eri...@xs...> wrote:
> OK, it seems we are ready then for the switchover.
>
> Brett, when do you think you can have rebuilt the Git repo at Sourceforge?
> I suppose it's better to create a fresh new repository than to do a massive
> update to get the current old one up to date.
>
> Erik.
>
>> -----Original Message-----
>> From: Phil Davies [mailto:de...@gm...]
>> Sent: Monday, July 11, 2011 10:56 AM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Are we ready for Git?
>>
>> As far as I'm concerned it's really Brett, Erik and Stefan's decision
> being the
>> primary contributors to the project.  IntelliJ has a Git plugin so I'm
> sure I'll
>> work it out :)
>>
>> Phil
>>
>> On 11 July 2011 06:04, Stefan Frey <ste...@we...> wrote:
>> > Erik & Brett,
>> > given that you both had some long-time hands-on-experience with Maven
>> > (compared to my third-party recommendation and a short try-out) I
>> > agree to stay with the current setup.
>> > I had not tested EGit/JGit before, thus I considered them as competing
>> > products similar to the svn-support in eclipse ;-) Stefan
>> >
>> > On Sunday, July 10, 2011 07:08:05 pm brett lentz wrote:
>> >> On Sun, Jul 10, 2011 at 9:24 AM, Erik Vos <eri...@xs...> wrote:
>> >> >> -----Original Message-----
>> >> >> From: Stefan Frey [mailto:ste...@we...]
>> >> >> Sent: Sunday, July 10, 2011 2:42 PM
>> >> >> To: Development list for Rails: an 18xx game
>> >> >> Subject: Re: [Rails-devel] Are we ready for Git?
>> >> >>
>> >> >> Erik & Brett,
>> >> >> I am up for that move. Do you recommend JGit or Egit?
>> >> >
>> >> > AFAIK you need both (in Eclipse).
>> >>
>> >> Correct.
>> >>
>> >> JGit is the java git implementation.
>> >> EGit is the eclipse plugin built on top of JGit.
>> >>
>> >> >> I am wondering if you would consider to move to a maven  build at
>> >> >> the same time. Ideally by changing to the maven recommended repo
>> layout.
>> >> >
>> >> > Dunno. Brett is handling the builds (I only run either from Eclipse
>> >> > Run or from the published Rails jars).
>> >> >
>> >> > I hardly know anything about Maven. In the past I have been
>> >> > half-involved with some (old) projects that used Maven, and perhaps
>> some other stuff.
>> >> > What I remember about these projects was the ubiquitous presence of
>> >> > pom.xml files that did not mean anything to me (I wasn't really
>> >> > interested either - it worked). So I'm blank.
>> >>
>> >> I deal with Maven at my day job, and I'm not a fan. Perhaps as Maven
>> >> 3 matures, it will improve in crucial areas. Right now, I really
>> >> dislike the way it handles dependency resolution, among other things.
>> >>
>> >> > Perhaps we'll better restrict ourselves to one major step at a time?
>> >>
>> >> Agreed.
>> >>
>> >> > One thing on our Git repo that I have struggled with yesterday is
>> >> > that it seems to require that the .git directory would exist at the
>> >> > same level as all project directories (game, tile, data etc.).  I
>> >> > was trying to get these directories below a src directory on the
>> >> > same level as .git (under the project root), but failed  to get
>> >> > there. Not really a problem, but perhaps noteworthy.
>> >> >
>> >> > Erik.
>> >>
>> >> ---Brett.
>> >>
>> >> ---------------------------------------------------------------------
>> >> ------
>> >> --- All of the data generated in your IT infrastructure is seriously
>> >> valuable. Why? It contains a definitive record of application
>> >> performance, security threats, fraudulent activity, and more. Splunk
>> >> takes this data and makes sense of it. IT sense. And common sense.
>> >> http://p.sf.net/sfu/splunk-d2d-c2
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> > ----------------------------------------------------------------------
>> > -------- All of the data generated in your IT infrastructure is
>> > seriously valuable.
>> > Why? It contains a definitive record of application performance,
>> > security threats, fraudulent activity, and more. Splunk takes this
>> > data and makes sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-d2d-c2
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>>
>>
> ----------------------------------------------------------------------------
> --
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Are we ready for Git?

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

OK, it seems we are ready then for the switchover.

Brett, when do you think you can have rebuilt the Git repo at Sourceforge?
I suppose it's better to create a fresh new repository than to do a massive
update to get the current old one up to date.

Erik.

> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Monday, July 11, 2011 10:56 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Are we ready for Git?
> 
> As far as I'm concerned it's really Brett, Erik and Stefan's decision
being the
> primary contributors to the project.  IntelliJ has a Git plugin so I'm
sure I'll
> work it out :)
> 
> Phil
> 
> On 11 July 2011 06:04, Stefan Frey <ste...@we...> wrote:
> > Erik & Brett,
> > given that you both had some long-time hands-on-experience with Maven
> > (compared to my third-party recommendation and a short try-out) I
> > agree to stay with the current setup.
> > I had not tested EGit/JGit before, thus I considered them as competing
> > products similar to the svn-support in eclipse ;-) Stefan
> >
> > On Sunday, July 10, 2011 07:08:05 pm brett lentz wrote:
> >> On Sun, Jul 10, 2011 at 9:24 AM, Erik Vos <eri...@xs...> wrote:
> >> >> -----Original Message-----
> >> >> From: Stefan Frey [mailto:ste...@we...]
> >> >> Sent: Sunday, July 10, 2011 2:42 PM
> >> >> To: Development list for Rails: an 18xx game
> >> >> Subject: Re: [Rails-devel] Are we ready for Git?
> >> >>
> >> >> Erik & Brett,
> >> >> I am up for that move. Do you recommend JGit or Egit?
> >> >
> >> > AFAIK you need both (in Eclipse).
> >>
> >> Correct.
> >>
> >> JGit is the java git implementation.
> >> EGit is the eclipse plugin built on top of JGit.
> >>
> >> >> I am wondering if you would consider to move to a maven  build at
> >> >> the same time. Ideally by changing to the maven recommended repo
> layout.
> >> >
> >> > Dunno. Brett is handling the builds (I only run either from Eclipse
> >> > Run or from the published Rails jars).
> >> >
> >> > I hardly know anything about Maven. In the past I have been
> >> > half-involved with some (old) projects that used Maven, and perhaps
> some other stuff.
> >> > What I remember about these projects was the ubiquitous presence of
> >> > pom.xml files that did not mean anything to me (I wasn't really
> >> > interested either - it worked). So I'm blank.
> >>
> >> I deal with Maven at my day job, and I'm not a fan. Perhaps as Maven
> >> 3 matures, it will improve in crucial areas. Right now, I really
> >> dislike the way it handles dependency resolution, among other things.
> >>
> >> > Perhaps we'll better restrict ourselves to one major step at a time?
> >>
> >> Agreed.
> >>
> >> > One thing on our Git repo that I have struggled with yesterday is
> >> > that it seems to require that the .git directory would exist at the
> >> > same level as all project directories (game, tile, data etc.).  I
> >> > was trying to get these directories below a src directory on the
> >> > same level as .git (under the project root), but failed  to get
> >> > there. Not really a problem, but perhaps noteworthy.
> >> >
> >> > Erik.
> >>
> >> ---Brett.
> >>
> >> ---------------------------------------------------------------------
> >> ------
> >> --- All of the data generated in your IT infrastructure is seriously
> >> valuable. Why? It contains a definitive record of application
> >> performance, security threats, fraudulent activity, and more. Splunk
> >> takes this data and makes sense of it. IT sense. And common sense.
> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -------- All of the data generated in your IT infrastructure is
> > seriously valuable.
> > Why? It contains a definitive record of application performance,
> > security threats, fraudulent activity, and more. Splunk takes this
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
>
----------------------------------------------------------------------------
--
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Are we ready for Git?

[Phil D. <de...@gm...>]

As far as I'm concerned it's really Brett, Erik and Stefan's decision
being the primary contributors to the project.  IntelliJ has a Git
plugin so I'm sure I'll work it out :)

Phil

On 11 July 2011 06:04, Stefan Frey <ste...@we...> wrote:
> Erik & Brett,
> given that you both had some long-time hands-on-experience with Maven
> (compared to my third-party recommendation and a short try-out) I agree to
> stay with the current setup.
> I had not tested EGit/JGit before, thus I considered them as competing
> products similar to the svn-support in eclipse ;-)
> Stefan
>
> On Sunday, July 10, 2011 07:08:05 pm brett lentz wrote:
>> On Sun, Jul 10, 2011 at 9:24 AM, Erik Vos <eri...@xs...> wrote:
>> >> -----Original Message-----
>> >> From: Stefan Frey [mailto:ste...@we...]
>> >> Sent: Sunday, July 10, 2011 2:42 PM
>> >> To: Development list for Rails: an 18xx game
>> >> Subject: Re: [Rails-devel] Are we ready for Git?
>> >>
>> >> Erik & Brett,
>> >> I am up for that move. Do you recommend JGit or Egit?
>> >
>> > AFAIK you need both (in Eclipse).
>>
>> Correct.
>>
>> JGit is the java git implementation.
>> EGit is the eclipse plugin built on top of JGit.
>>
>> >> I am wondering if you would consider to move to a maven  build at the
>> >> same time. Ideally by changing to the maven recommended repo layout.
>> >
>> > Dunno. Brett is handling the builds (I only run either from Eclipse Run
>> > or from the published Rails jars).
>> >
>> > I hardly know anything about Maven. In the past I have been half-involved
>> > with some (old) projects that used Maven, and perhaps some other stuff.
>> > What I remember about these projects was the ubiquitous presence of
>> > pom.xml files that did not mean anything to me (I wasn't really
>> > interested either - it worked). So I'm blank.
>>
>> I deal with Maven at my day job, and I'm not a fan. Perhaps as Maven 3
>> matures, it will improve in crucial areas. Right now, I really dislike
>> the way it handles dependency resolution, among other things.
>>
>> > Perhaps we'll better restrict ourselves to one major step at a time?
>>
>> Agreed.
>>
>> > One thing on our Git repo that I have struggled with yesterday is that it
>> > seems to require that the .git directory would exist at the same level as
>> > all project directories (game, tile, data etc.).  I was trying to get
>> > these directories below a src directory on the same level as .git (under
>> > the project root), but failed  to get there. Not really a problem, but
>> > perhaps noteworthy.
>> >
>> > Erik.
>>
>> ---Brett.
>>
>> ---------------------------------------------------------------------------
>> --- All of the data generated in your IT infrastructure is seriously
>> valuable. Why? It contains a definitive record of application performance,
>> security threats, fraudulent activity, and more. Splunk takes this data
>> and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Are we ready for Git?

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

Erik & Brett,
given that you both had some long-time hands-on-experience with Maven 
(compared to my third-party recommendation and a short try-out) I agree to 
stay with the current setup.
I had not tested EGit/JGit before, thus I considered them as competing 
products similar to the svn-support in eclipse ;-)
Stefan

On Sunday, July 10, 2011 07:08:05 pm brett lentz wrote:
> On Sun, Jul 10, 2011 at 9:24 AM, Erik Vos <eri...@xs...> wrote:
> >> -----Original Message-----
> >> From: Stefan Frey [mailto:ste...@we...]
> >> Sent: Sunday, July 10, 2011 2:42 PM
> >> To: Development list for Rails: an 18xx game
> >> Subject: Re: [Rails-devel] Are we ready for Git?
> >> 
> >> Erik & Brett,
> >> I am up for that move. Do you recommend JGit or Egit?
> > 
> > AFAIK you need both (in Eclipse).
> 
> Correct.
> 
> JGit is the java git implementation.
> EGit is the eclipse plugin built on top of JGit.
> 
> >> I am wondering if you would consider to move to a maven  build at the
> >> same time. Ideally by changing to the maven recommended repo layout.
> > 
> > Dunno. Brett is handling the builds (I only run either from Eclipse Run
> > or from the published Rails jars).
> > 
> > I hardly know anything about Maven. In the past I have been half-involved
> > with some (old) projects that used Maven, and perhaps some other stuff.
> > What I remember about these projects was the ubiquitous presence of
> > pom.xml files that did not mean anything to me (I wasn't really
> > interested either - it worked). So I'm blank.
> 
> I deal with Maven at my day job, and I'm not a fan. Perhaps as Maven 3
> matures, it will improve in crucial areas. Right now, I really dislike
> the way it handles dependency resolution, among other things.
> 
> > Perhaps we'll better restrict ourselves to one major step at a time?
> 
> Agreed.
> 
> > One thing on our Git repo that I have struggled with yesterday is that it
> > seems to require that the .git directory would exist at the same level as
> > all project directories (game, tile, data etc.).  I was trying to get
> > these directories below a src directory on the same level as .git (under
> > the project root), but failed  to get there. Not really a problem, but
> > perhaps noteworthy.
> > 
> > Erik.
> 
> ---Brett.
> 
> ---------------------------------------------------------------------------
> --- All of the data generated in your IT infrastructure is seriously
> valuable. Why? It contains a definitive record of application performance,
> security threats, fraudulent activity, and more. Splunk takes this data
> and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Are we ready for Git?

[brett l. <bre...@gm...>]

On Sun, Jul 10, 2011 at 9:24 AM, Erik Vos <eri...@xs...> wrote:
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Sunday, July 10, 2011 2:42 PM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Are we ready for Git?
>>
>> Erik & Brett,
>> I am up for that move. Do you recommend JGit or Egit?
>>
>
> AFAIK you need both (in Eclipse).
>

Correct.

JGit is the java git implementation.
EGit is the eclipse plugin built on top of JGit.

>> I am wondering if you would consider to move to a maven  build at the same
>> time. Ideally by changing to the maven recommended repo layout.
>
> Dunno. Brett is handling the builds (I only run either from Eclipse Run or
> from the published Rails jars).
>
> I hardly know anything about Maven. In the past I have been half-involved
> with some (old) projects that used Maven, and perhaps some other stuff.
> What I remember about these projects was the ubiquitous presence of pom.xml
> files that did not mean anything to me (I wasn't really interested either -
> it worked). So I'm blank.
>

I deal with Maven at my day job, and I'm not a fan. Perhaps as Maven 3
matures, it will improve in crucial areas. Right now, I really dislike
the way it handles dependency resolution, among other things.


> Perhaps we'll better restrict ourselves to one major step at a time?
>

Agreed.

> One thing on our Git repo that I have struggled with yesterday is that it
> seems to require that the .git directory would exist at the same level as
> all project directories (game, tile, data etc.).  I was trying to get these
> directories below a src directory on the same level as .git (under the
> project root), but failed  to get there. Not really a problem, but perhaps
> noteworthy.
>
> Erik.
>
>

---Brett.

Re: [Rails-devel] Are we ready for Git?

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

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Sunday, July 10, 2011 2:42 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Are we ready for Git?
> 
> Erik & Brett,
> I am up for that move. Do you recommend JGit or Egit?
>

AFAIK you need both (in Eclipse).

> I am wondering if you would consider to move to a maven  build at the same
> time. Ideally by changing to the maven recommended repo layout.

Dunno. Brett is handling the builds (I only run either from Eclipse Run or
from the published Rails jars). 

I hardly know anything about Maven. In the past I have been half-involved
with some (old) projects that used Maven, and perhaps some other stuff.
What I remember about these projects was the ubiquitous presence of pom.xml
files that did not mean anything to me (I wasn't really interested either -
it worked). So I'm blank.

Perhaps we'll better restrict ourselves to one major step at a time?

One thing on our Git repo that I have struggled with yesterday is that it
seems to require that the .git directory would exist at the same level as
all project directories (game, tile, data etc.).  I was trying to get these
directories below a src directory on the same level as .git (under the
project root), but failed  to get there. Not really a problem, but perhaps
noteworthy.

Erik.

Re: [Rails-devel] Are we ready for Git?

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

Erik & Brett,
I am up for that move. Do you recommend JGit or Egit?

I am wondering if you would consider to move to a maven  build at the same 
time. Ideally by changing to the maven recommended repo layout.

A year ago I considered proposing that and I was able to have it compile under 
maven in a few hours without any previous knowledge of maven.
Main issue was the search for the maven repos of the libs we have in.

My main reason for doing that was the Sonar (http://sonarsource.org) support 
that comes automatically with it.

Stefan


On Sunday, July 10, 2011 02:18:15 pm Erik Vos wrote:
> To all committing developers, in particular Stefan,
> 
> Brett and I have been discussing off-list if it could be the right time to
> move from SVN to Git as a code repository on Sourceforge.  You may
> remember that Brett already had prepared a Git repo several months ago. 
> The Egit add-on for Eclipse now seems to be good enough to be used for
> that purpose.  I have given it a try yesterday, and although I have not
> tested all required actions yet, so far it looks fine to me.
> 
> I have started this discussion now because I'm fed up with SVN (or perhaps
> rather: the Subversive plug-in to Eclipse).  I have had too many problems
> recently (see below for the most recent one - I found that Git allows to
> ignore .gitignore).
> 
> With Git, each developer has its own repository.  I expect that to be an
> real benefit, as I will be able to make multiple snapshots, and even can
> branch locally, without bothering the central repository until all aspects
> of a new feature are OK.  The only bad news is, that three actions are
> required to distribute a change: Add, Commit and Push.
> 
> I'm all for it.  What about you?
> 
> Erik
> 
> > -----Original Message-----
> > From: wak...@gm... [mailto:wak...@gm...] On Behalf Of
> > brett lentz
> > Sent: Friday, July 08, 2011 11:18 PM
> > To: Erik Vos
> > Subject: Re: svn:ignore in repository??
> > 
> > Fine by me. I'll turn the sf.net git repository back on this weekend and
> > push our current SVN repo into it.
> > 
> > Do you want to start a new "Let's move to Git" thread on rails-devel, so
> > we can inform everyone of the change?
> > 
> > I've been using Git heavily at work for the last 2 years, so I'm pretty
> > familiar with it. There's some important differences that you'll want to
> > be aware of. Probably the biggest difference that you'll see
> > immediately, is that Git revisions the *whole* repository, unlike CVS
> > and SVN which maintain discrete versions for each file.
> > This means that things like branches, merges, etc. all operate on a per-
> > repository basis.
> > 
> > Here's some resources on getting up to speed with Git. Read the first
> > one, especially.
> > 
> > http://tom.preston-werner.com/2009/05/19/the-git-parable.html
> > http://book.git-scm.com/
> > http://www.gitready.com/
> > http://www-cs-students.stanford.edu/~blynn/gitmagic/
> > http://git.or.cz/gitwiki/GitCheatSheet
> > http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
> > 
> > 
> > ---Brett.
> > 
> > On Fri, Jul 8, 2011 at 1:42 PM, Erik Vos <eri...@xs...> wrote:
> > > Hmm, now I first had a conflict, and after I managed to fix that with
> > 
> > Tortoise, SVN keeps insisting on committing svn:ignore to the repository!
> > 
> > > I suppose this started after I installed a new version of Subversion (I
> > > think
> > 
> > 1.6) when I had problems a while ago.
> > 
> > > It turns out that (at least in this version) svn:ignore is a
> > > *versioned*
> > 
> > property, in other words: it is *supposed* to be in the repository!
> > 
> > > See http://svnbook.red-bean.com/nightly/en/svn.ref.properties.html .
> > > 
> > > I find this ridiculous, and to me it's another nail in the coffin of
> > > SVN.  Guess
> > 
> > it's time to install Jgit/Egit.
> > 
> > > Erik.
> > > 
> > >> -----Original Message-----
> > >> From: wak...@gm... [mailto:wak...@gm...] On Behalf Of
> > >> brett lentz
> > >> Sent: Friday, July 08, 2011 7:18 PM
> > >> To: Erik Vos
> > >> Subject: Re: svn:ignore in repository??
> > >> 
> > >> I've removed the svn:ignore property. Hopefully that helps. :-)
> > >> 
> > >> ---Brett.
> > >> 
> > >> On Fri, Jul 8, 2011 at 8:15 AM, brett lentz <bre...@gm...> 
wrote:
> > >> > Sounds like somebody committed their version of the file to the
> > 
> > repository.
> > 
> > >> > I'll see if I can fix that.
> > >> > 
> > >> > ---Brett.
> > >> > 
> > >> > On Fri, Jul 8, 2011 at 4:02 AM, Erik Vos <eri...@xs...> wrote:
> > >> >> Brett, I don't know if you can help me with the following:
> > >> >> 
> > >> >> Commits have started to fail because there is a difference between
> > >> >> svn:ignore locally and remotely in the root directory.  Indeed I
> > >> >> gave added some files to it.
> > >> >> I can fix that easily by removing the root from the commit, but
> > >> >> the difference keeps showing up when I synchronize, and I can't
> > >> >> clean that
> > >> 
> > >> up.
> > >> 
> > >> >> The main thing, though, is that I completely don't understand what
> > >> >> business svn:ignore has of being in the repository at all.
> > >> >> Shouldn't that just be a local file only?  Can that be fixed?
> > >> >> 
> > >> >> Erik.
> 
> ---------------------------------------------------------------------------
> --- All of the data generated in your IT infrastructure is seriously
> valuable. Why? It contains a definitive record of application performance,
> security threats, fraudulent activity, and more. Splunk takes this data
> and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Are we ready for Git?

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

To all committing developers, in particular Stefan,

Brett and I have been discussing off-list if it could be the right time to move from SVN to Git as a code repository on Sourceforge.  You may remember that Brett already had prepared a Git repo several months ago.  The Egit add-on for Eclipse now seems to be good enough to be used for that purpose.  I have given it a try yesterday, and although I have not tested all required actions yet, so far it looks fine to me.

I have started this discussion now because I'm fed up with SVN (or perhaps rather: the Subversive plug-in to Eclipse).  I have had too many problems recently (see below for the most recent one - I found that Git allows to ignore .gitignore). 

With Git, each developer has its own repository.  I expect that to be an real benefit, as I will be able to make multiple snapshots, and even can branch locally, without bothering the central repository until all aspects of a new feature are OK.  The only bad news is, that three actions are required to distribute a change: Add, Commit and Push. 

I'm all for it.  What about you?

Erik

> -----Original Message-----
> From: wak...@gm... [mailto:wak...@gm...] On Behalf Of
> brett lentz
> Sent: Friday, July 08, 2011 11:18 PM
> To: Erik Vos
> Subject: Re: svn:ignore in repository??
> 
> Fine by me. I'll turn the sf.net git repository back on this weekend and push
> our current SVN repo into it.
> 
> Do you want to start a new "Let's move to Git" thread on rails-devel, so we
> can inform everyone of the change?
> 
> I've been using Git heavily at work for the last 2 years, so I'm pretty familiar
> with it. There's some important differences that you'll want to be aware of.
> Probably the biggest difference that you'll see immediately, is that Git
> revisions the *whole* repository, unlike CVS and SVN which maintain
> discrete versions for each file.
> This means that things like branches, merges, etc. all operate on a per-
> repository basis.
> 
> Here's some resources on getting up to speed with Git. Read the first one,
> especially.
> 
> http://tom.preston-werner.com/2009/05/19/the-git-parable.html
> http://book.git-scm.com/
> http://www.gitready.com/
> http://www-cs-students.stanford.edu/~blynn/gitmagic/
> http://git.or.cz/gitwiki/GitCheatSheet
> http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
> 
> 
> ---Brett.
> 
> 
> 
> On Fri, Jul 8, 2011 at 1:42 PM, Erik Vos <eri...@xs...> wrote:
> > Hmm, now I first had a conflict, and after I managed to fix that with
> Tortoise, SVN keeps insisting on committing svn:ignore to the repository!
> >
> > I suppose this started after I installed a new version of Subversion (I think
> 1.6) when I had problems a while ago.
> > It turns out that (at least in this version) svn:ignore is a *versioned*
> property, in other words: it is *supposed* to be in the repository!
> > See http://svnbook.red-bean.com/nightly/en/svn.ref.properties.html .
> >
> > I find this ridiculous, and to me it's another nail in the coffin of SVN.  Guess
> it's time to install Jgit/Egit.
> >
> > Erik.
> >
> >> -----Original Message-----
> >> From: wak...@gm... [mailto:wak...@gm...] On Behalf Of
> >> brett lentz
> >> Sent: Friday, July 08, 2011 7:18 PM
> >> To: Erik Vos
> >> Subject: Re: svn:ignore in repository??
> >>
> >> I've removed the svn:ignore property. Hopefully that helps. :-)
> >>
> >> ---Brett.
> >>
> >>
> >>
> >> On Fri, Jul 8, 2011 at 8:15 AM, brett lentz <bre...@gm...> wrote:
> >> > Sounds like somebody committed their version of the file to the
> repository.
> >> >
> >> > I'll see if I can fix that.
> >> >
> >> > ---Brett.
> >> >
> >> >
> >> >
> >> > On Fri, Jul 8, 2011 at 4:02 AM, Erik Vos <eri...@xs...> wrote:
> >> >> Brett, I don't know if you can help me with the following:
> >> >>
> >> >> Commits have started to fail because there is a difference between
> >> >> svn:ignore locally and remotely in the root directory.  Indeed I
> >> >> gave added some files to it.
> >> >> I can fix that easily by removing the root from the commit, but
> >> >> the difference keeps showing up when I synchronize, and I can't
> >> >> clean that
> >> up.
> >> >>
> >> >> The main thing, though, is that I completely don't understand what
> >> >> business svn:ignore has of being in the repository at all.
> >> >> Shouldn't that just be a local file only?  Can that be fixed?
> >> >>
> >> >> Erik.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >
> >

Re: [Rails-devel] Problem to start new games

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

Something is wrong with passing on the game options selected (or not) in
GameSetupWindow.  
If Options is expanded and a variant (such as Coalfields) is selected, the
log shows:

2011-07-09 14:44:17 INFO   Game option null set to Coalfields
(GameSetupWindow startNewGame 477) 
2011-07-09 14:44:17 INFO   Game option null set to Highlight
(GameSetupWindow startNewGame 477) 
2011-07-09 14:44:17 INFO   Game option null set to Suggest  (GameSetupWindow
startNewGame 477) 
2011-07-09 14:44:17 INFO   Game option null set to no  (GameSetupWindow
startNewGame 477) 
2011-07-09 14:44:17 INFO   Game option null set to no  (GameSetupWindow
startNewGame 477) 
2011-07-09 14:44:17 INFO   Game option null set to no  (GameSetupWindow
startNewGame 477) 
2011-07-09 14:44:17 INFO   Game option UnlimitedTopTrains_D set to no
(GameSetupWindow startNewGame 477) 
2011-07-09 14:44:17 INFO   Game option null set to no  (GameSetupWindow
startNewGame 477) 
2011-07-09 14:44:17 INFO   Game option null set to no  (GameSetupWindow
startNewGame 477) 
2011-07-09 14:44:17 INFO   Game option null set to no  (GameSetupWindow
startNewGame 477) 
2011-07-09 14:44:17 INFO   Game option null set to PRR  (GameSetupWindow
startNewGame 477) 
2011-07-09 14:44:17 INFO   Game option null set to yes  (GameSetupWindow
startNewGame 477)

and it's these null names that cause the crash.  If I code the null names to
be ignored, the base game starts, rather than Coalfields.

Not sure why this happens, but something related to options must have
changed recently.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday, July 09, 2011 2:26 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: [Rails-devel] Problem to start new games
> 
> Erik or Brett:
> On testing I realized that currently for some games/variants a new game
> cannot be started:
> 
> 1830 coalfields does not work
> (Null pointer exception in Game class), however 1830 base does work.
> 
> 1889 does not work
> (Configruation error: Invalid quantity 0 for train cert type 6 in
> TrainCertificateClass).
> 
> 1856, 18EU seems to work.
> 
> However loading either an older 1830 coalfields or 1889 save file still
works.
> 
> Another strange thing:
> The  Available Games dropdown shows next to each game instead of the
> game status the same label "Notes".
> 
> I am pretty sure that neither of this was caused by my work, do you have
an
> ideas what happened there?
> 
> Stefan
> 
>
----------------------------------------------------------------------------
--
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Problem to start new games

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

Erik or Brett:
On testing I realized that currently for some games/variants a new game cannot 
be started:

1830 coalfields does not work 
(Null pointer exception in Game class), 
however 1830 base does work.

1889 does not work
(Configruation error: Invalid quantity 0 for train cert type 6 in 
TrainCertificateClass).

1856, 18EU seems to work.

However loading either an older 1830 coalfields or 1889 save file still works.

Another strange thing:
The  Available Games dropdown shows next to each game instead of the game 
status the same label "Notes".

I am pretty sure that neither of this was caused by my work, do you have an 
ideas what happened there?

Stefan

Re: [Rails-devel] Refactored loading code (r1613)

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

And the final step, refactoring of game load and save is finished for now.

ListAndFixSavedFile now uses GameFileIO for saving.
It fully supports loading and saving the user comments and those are shown in 
the report window.

Stefan

On Wednesday, July 06, 2011 07:44:35 am Stefan Frey wrote:
> Further steps on refactoring:
> 
> There is a new class that combines all fields required for gameIO into
> rails.util.gameData and renamed the gameLoader into gameFileIO as it now
> combines load and save functions.
> 
> Please do some further checks on your own that load and save still works as
> intended in all situations.
> 
> One little bit is still missing: ListAndFixSavedFile is not able to save
> games currently, only loading.
> 
> Stefan
> 
> On Tuesday, July 05, 2011 07:59:49 pm brett lentz wrote:
> > I was actually thinking something similar this weekend...
> > 
> > No objections here. :-)
> > 
> > ---Brett.
> > 
> > On Tue, Jul 5, 2011 at 10:49 AM, Erik Vos <eri...@xs...> wrote:
> > > Ah, good stuff.  I was already occasionally running into problems with
> > > loading files into ListAndFixSavedFiles.
> > > 
> > > As you may or may not have noticed, since some time I'm pretty
> > > meticulously creating entries in the Wiki Change Log for all my commits
> > > (except very trivial ones).  I don't know if I can expect the same from
> > > Brett and you (as we have seen earlier today, I'm not really the right
> > > person to request discipline). In any case, I have just created simple
> > > entries for the recent commits 1602-1604 by the two of you.  Feel free
> > > to  correct or expand.
> > > 
> > > As for packaging, I would prefer to reserve rails.util for Rails
> > > classes only, and put all external main programs into tools.  That
> > > would mean that ListAndFixSavedFiles should move from rails.util to
> > > tools. Any objections?
> > > 
> > > I just noticed that we have TWO Util classes, one in rails.util and one
> > > in tools.  Does anyone know a good reason for that duplication?
> > > 
> > >  Otherwise I would propose to merge the two into rails.util.Util.
> > > 
> > > Erik.
> > > 
> > >> -----Oorspronkelijk bericht-----
> > >> Van: Stefan Frey [mailto:ste...@we...]
> > >> Verzonden: dinsdag 5 juli 2011 19:11
> > >> Aan: 'Development list for Rails: an 18xx game'
> > >> Onderwerp: [Rails-devel] Refactored loading code
> > >> 
> > >> Brett & Erik,
> > >> some time ago I started to refactor the game loading code in one class
> > >> to
> > > 
> > > get
> > > 
> > >> the ListAndFixSavedFiles utility adjusted to the new comments.
> > >> 
> > >> To avoid more incompatibilities from the started refactoring from
> > >> Brett
> > > 
> > > now I
> > > 
> > >> thought to adjust the code to include the new reload functionality of
> > >> Erik
> > > 
> > > to
> > > 
> > >> be able to commit those changes.
> > >> 
> > >> Nearly all loading functionality has been moved to a new GameLoader
> > >> class
> > > 
> > > in
> > > 
> > >> rails.util package. The load function in Game, GameManager and
> > >> ListAndFixSavedFiles now all make use of a a GameLoader object.
> > >> 
> > >> I have also added a line to the reload error message that asks the
> > >> user to submit the corrupt save file to the Rails user list for bug
> > >> tracking. If
> > > 
> > > you think
> > > 
> > >> that is not a good idea, simply remove that text from
> > >> LocalisedProperties.
> > >> 
> > >> Stefan
> > > 
> > > -----------------------------------------------------------------------
> > > -- --- --
> > > 
> > >> All of the data generated in your IT infrastructure is seriously
> > >> valuable. Why? It contains a definitive record of application
> > >> performance, security threats, fraudulent activity, and more. Splunk
> > >> takes this data and makes sense of it. IT sense. And common sense.
> > >> http://p.sf.net/sfu/splunk-d2d-c2
> > >> _______________________________________________
> > >> Rails-devel mailing list
> > >> Rai...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > 
> > > -----------------------------------------------------------------------
> > > -- ----- All of the data generated in your IT infrastructure is
> > > seriously valuable. Why? It contains a definitive record of
> > > application
> > > performance, security threats, fraudulent activity, and more. Splunk
> > > takes this data and makes sense of it. IT sense. And common sense.
> > > http://p.sf.net/sfu/splunk-d2d-c2
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > -- --- All of the data generated in your IT infrastructure is seriously
> > valuable. Why? It contains a definitive record of application
> > performance, security threats, fraudulent activity, and more. Splunk
> > takes this data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- All of the data generated in your IT infrastructure is seriously
> valuable. Why? It contains a definitive record of application performance,
> security threats, fraudulent activity, and more. Splunk takes this data
> and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Running to and through stations

[brett l. <bre...@gm...>]

Ok... I misunderstood. Apologies for the confusion. :-)

---Brett.



On Fri, Jul 8, 2011 at 9:13 AM, Erik Vos <eri...@xs...> wrote:
> No, I didn't intend to say that.  The (current) City and Station objects are quite different, if only because the City retains its identity when tiles are laid (unless stations merge) and new Stations appear on that hex. The Station objects related to a particular City change several times during a game.
>
> I'm not sure what I exactly did want to say, but I lean towards Station->Stop and City->HexStop.
>
> Erik.
>
>> -----Original Message-----
>> From: brett lentz [mailto:bre...@gm...]
>> Sent: Friday, July 08, 2011 5:25 PM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Running to and through stations
>>
>> Maybe I misunderstood, but I thought Erik was saying, make City and Station
>> both be "Stop" or "HexStop", just with different parameters.
>>
>> Their behavior is largely identical, and what differences there are usually
>> don't really justify a separate class. In most games, A town or whistle stop is
>> just a city that can't be tokened, has a fixed value, and, in some games,
>> means the tile is non-upgradeable.
>>
>> I'm not sure what difference you're referring to by "on the map" and "on tile
>> only". I wasn't suggesting changing the separation between Model and View.
>>
>> ---Brett.
>>
>>
>>
>> On Fri, Jul 8, 2011 at 12:52 AM, Stefan Frey <ste...@we...> wrote:
>> > Brett,
>> > so what is your suggestion exactly?
>> >
>> > Mine was:
>> > City (on the map, tokenable) => HexStation Station (on tile only) =>
>> > Station
>> >
>> > I understood Erik's to be:
>> > City => Stop
>> > Station => Station
>> >
>> > I can live with that, however for me it is now improvement compared to
>> > the previous solution.
>> > But this still keeps Station.
>> >
>> > Maybe your a merger of the two:
>> > City => HexStop or MapStop
>> > Station => Stop or TileStop
>> >
>> > Stefan
>> >
>> >
>> > On Thursday, July 07, 2011 06:49:53 pm brett lentz wrote:
>> >> On Thu, Jul 7, 2011 at 8:59 AM, Erik Vos <eri...@xs...> wrote:
>> >> >> A. City vs. HexStation:
>> >> > I find myself increasingly using the term "train stop".  So, what
>> >> > about Stop or TrainStop?  Very descriptive, and (as you know) I
>> >> > love short type names. Also Stop has no confusing connotations, as
>> >> > City and Station have.
>> >> >
>> >> > Erik.
>> >>
>> >> +1 from me. I like "Stop" a bit better, too. It maps closer to the
>> >> logical function of those features on the hex.
>> >>
>> >> We can use "City" and "Station" as user-visible tags, if we want, but
>> >> to keep the internal data organization sane, I'd like to deprecate
>> >> those terms.
>> >>
>> >> ---------------------------------------------------------------------
>> >> ------
>> >> --- All of the data generated in your IT infrastructure is seriously
>> >> valuable. Why? It contains a definitive record of application
>> >> performance, security threats, fraudulent activity, and more. Splunk
>> >> takes this data and makes sense of it. IT sense. And common sense.
>> >> http://p.sf.net/sfu/splunk-d2d-c2
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> > ----------------------------------------------------------------------
>> > -------- All of the data generated in your IT infrastructure is
>> > seriously valuable.
>> > Why? It contains a definitive record of application performance,
>> > security threats, fraudulent activity, and more. Splunk takes this
>> > data and makes sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-d2d-c2
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Running to and through stations

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

No, I didn't intend to say that.  The (current) City and Station objects are quite different, if only because the City retains its identity when tiles are laid (unless stations merge) and new Stations appear on that hex. The Station objects related to a particular City change several times during a game.

I'm not sure what I exactly did want to say, but I lean towards Station->Stop and City->HexStop.

Erik.

> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Friday, July 08, 2011 5:25 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Running to and through stations
> 
> Maybe I misunderstood, but I thought Erik was saying, make City and Station
> both be "Stop" or "HexStop", just with different parameters.
> 
> Their behavior is largely identical, and what differences there are usually
> don't really justify a separate class. In most games, A town or whistle stop is
> just a city that can't be tokened, has a fixed value, and, in some games,
> means the tile is non-upgradeable.
> 
> I'm not sure what difference you're referring to by "on the map" and "on tile
> only". I wasn't suggesting changing the separation between Model and View.
> 
> ---Brett.
> 
> 
> 
> On Fri, Jul 8, 2011 at 12:52 AM, Stefan Frey <ste...@we...> wrote:
> > Brett,
> > so what is your suggestion exactly?
> >
> > Mine was:
> > City (on the map, tokenable) => HexStation Station (on tile only) =>
> > Station
> >
> > I understood Erik's to be:
> > City => Stop
> > Station => Station
> >
> > I can live with that, however for me it is now improvement compared to
> > the previous solution.
> > But this still keeps Station.
> >
> > Maybe your a merger of the two:
> > City => HexStop or MapStop
> > Station => Stop or TileStop
> >
> > Stefan
> >
> >
> > On Thursday, July 07, 2011 06:49:53 pm brett lentz wrote:
> >> On Thu, Jul 7, 2011 at 8:59 AM, Erik Vos <eri...@xs...> wrote:
> >> >> A. City vs. HexStation:
> >> > I find myself increasingly using the term "train stop".  So, what
> >> > about Stop or TrainStop?  Very descriptive, and (as you know) I
> >> > love short type names. Also Stop has no confusing connotations, as
> >> > City and Station have.
> >> >
> >> > Erik.
> >>
> >> +1 from me. I like "Stop" a bit better, too. It maps closer to the
> >> logical function of those features on the hex.
> >>
> >> We can use "City" and "Station" as user-visible tags, if we want, but
> >> to keep the internal data organization sane, I'd like to deprecate
> >> those terms.
> >>
> >> ---------------------------------------------------------------------
> >> ------
> >> --- All of the data generated in your IT infrastructure is seriously
> >> valuable. Why? It contains a definitive record of application
> >> performance, security threats, fraudulent activity, and more. Splunk
> >> takes this data and makes sense of it. IT sense. And common sense.
> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -------- All of the data generated in your IT infrastructure is
> > seriously valuable.
> > Why? It contains a definitive record of application performance,
> > security threats, fraudulent activity, and more. Splunk takes this
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Running to and through stations

[brett l. <bre...@gm...>]

Maybe I misunderstood, but I thought Erik was saying, make City and
Station both be "Stop" or "HexStop", just with different parameters.

Their behavior is largely identical, and what differences there are
usually don't really justify a separate class. In most games, A town
or whistle stop is just a city that can't be tokened, has a fixed
value, and, in some games, means the tile is non-upgradeable.

I'm not sure what difference you're referring to by "on the map" and
"on tile only". I wasn't suggesting changing the separation between
Model and View.

---Brett.



On Fri, Jul 8, 2011 at 12:52 AM, Stefan Frey <ste...@we...> wrote:
> Brett,
> so what is your suggestion exactly?
>
> Mine was:
> City (on the map, tokenable) => HexStation
> Station (on tile only) => Station
>
> I understood Erik's to be:
> City => Stop
> Station => Station
>
> I can live with that, however for me it is now improvement compared to the
> previous solution.
> But this still keeps Station.
>
> Maybe your a merger of the two:
> City => HexStop or MapStop
> Station => Stop or TileStop
>
> Stefan
>
>
> On Thursday, July 07, 2011 06:49:53 pm brett lentz wrote:
>> On Thu, Jul 7, 2011 at 8:59 AM, Erik Vos <eri...@xs...> wrote:
>> >> A. City vs. HexStation:
>> > I find myself increasingly using the term "train stop".  So, what about
>> > Stop or TrainStop?  Very descriptive, and (as you know) I love short
>> > type names. Also Stop has no confusing connotations, as City and Station
>> > have.
>> >
>> > Erik.
>>
>> +1 from me. I like "Stop" a bit better, too. It maps closer to the
>> logical function of those features on the hex.
>>
>> We can use "City" and "Station" as user-visible tags, if we want, but
>> to keep the internal data organization sane, I'd like to deprecate
>> those terms.
>>
>> ---------------------------------------------------------------------------
>> --- All of the data generated in your IT infrastructure is seriously
>> valuable. Why? It contains a definitive record of application performance,
>> security threats, fraudulent activity, and more. Splunk takes this data
>> and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>