rails-devel — List for discussion of Rails development

[Rails-devel] Release Rails 1.7.7 available

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

A new maintenance release for Rails 1.x series

Downloads are available at http://rails.sourceforge.net/ or by the
direct link http://sourceforge.net/projects/rails/files/Rails/1.7.7/

Contributors: Erik Vos, Stefan Frey

Bug reported by Are-Harald Brenne, John David Galt

New:
- Added little fun variant 18Lummer

Lists of bugs fixed:
- Errors in UI after adding a comment at game start
- Fixed failure on reloading a just started game
- 1835: Manual close of Pfalzbahn is possible
(to enable closing after token lay only)
- 1835 (and others): Fixed UI issues with token relays on OO-tiles

Re: [Rails-devel] Bugs at Game Start (was: [Rails-users] A few bugs)

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

> > - If you save the game at the start before any move has been made, the
> > game bugs on reloading, similar symptoms as above.

In GameFileIO.replayGame(), the list of game actions was null (rather than
empty, as one would expect). 
There was no check on this condition, so a NullPointerException followed.
I have added such a null check.

Erik

[Rails-devel] Rules enforcement for Token lay (was: 1835 Pfalzbahn token lay)

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

On 06/15/2012 01:05 AM, John David Galt wrote:
> On 2012-06-13 22:46, Mike Bourke wrote:
>> I'm pretty sure that we were playing 1st edition English Rules. Perhaps this
>> is one of the changes that took place between the two editions? Is it worth
>> considering offering the two as options choices during game setup?
>
> I have the impression that the present code does not enforce any rules about
> where tokens can be laid, so I wouldn't create an option for playing that way.
> If they are enforced later, then we'd want an option to turn off enforcement
> (and it is probably in the intended design already).
>

Current rules enforcement for tokens:
There are some rules with respect to token lays that are enforced by the 
current implementation. Some examples are:
* It is only possible to lay one token per OR.
* The correct cost of a token lay is enforced.
* Lay of home token is enforced (actually done automatically).
* No more tokens can be laid than slots are available.
* It is not possible to lay more tokens than available for the company.
* Correct handling of tokens after mergers.

If I do not forget something else here, there is only one (but an 
important one) rule missing: The check for connectivity.
However this is easy to add given the current code base, so expect this 
to be added in Rails2.1+ .

Similar to the automatic revenue calculation my current idea is to allow 
for different settings for connectivity rules enforcement for token (and 
tile) laying.

However it would still effect connectivity checks, the other rules (see 
above) would still be in place.

Most likely the option to switch on suggestions (highlighting valid 
hexes/tiles) should be better moved from the game options to the 
configuration options, as this would allow to make the option changeable 
during a game session.

Stefan

Re: [Rails-devel] 1835 Pfalzbahn token lay (was Re: Minor bug, 1835, 1.7.6)

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

On 2012-06-13 22:46, Mike Bourke wrote:
> I'm pretty sure that we were playing 1st edition English Rules. Perhaps this
> is one of the changes that took place between the two editions? Is it worth
> considering offering the two as options choices during game setup?

I have the impression that the present code does not enforce any rules about
where tokens can be laid, so I wouldn't create an option for playing that way.
If they are enforced later, then we'd want an option to turn off enforcement
(and it is probably in the intended design already).

Re: [Rails-devel] Upcoming release 1.7.7

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

Stefan,

It had slipped out of my mind, but I'll look at it tomorrow.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday, June 14, 2012 4:51 PM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Upcoming release 1.7.7
> 
> Erik:
> do you think you will be able fix to the start-of-game save problem soon?
> Otherwise I will put out 1.7.7 today.
> Stefan
> 
> On 06/14/2012 03:50 PM, Erik Vos wrote:
> >> I was not yet able to test if the related 1830 Erie and 1856 THB home
> > hexes
> >> still work as before, but I have no reason to doubt that.
> >
> > Putting that last bold statement was asking for trouble, of course,
> > and indeed Rails crashed with the typical Erie yellow-to-green upgrade.
> > The fix to that has been pushed to master.
> >
> > Erik.
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the
> > latest in malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware
threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] [Rails-users] A few bugs

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

Fixed the first bug (in rails1.7.x): The first comment has no player 
linked as there has no action been taken and comments are linked to the 
previous action's owner.

On 06/10/2012 11:40 PM, Are-Harald Brenne wrote:
> Two bugs:
>
> - If you try to add a comment at the start of the game before any move
> has been made, the game stops working. You can make a bid or purchase
> a private, but the round never progresses to the next player.
> - If you save the game at the start before any move has been made, the
> game bugs on reloading, similar symptoms as above.
>
> This came up when I tried to start a game for play through dropbox and
> email, where I'm not the first player out.
>
> Thanks to the developers for making this very nice piece of software!
>
> Cheers,
> Are-Harald
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-users mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-users

[Rails-devel] Upcoming release 1.7.7

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

Erik:
do you think you will be able fix to the start-of-game save problem soon?
Otherwise I will put out 1.7.7 today.
Stefan

On 06/14/2012 03:50 PM, Erik Vos wrote:
>> I was not yet able to test if the related 1830 Erie and 1856 THB home
> hexes
>> still work as before, but I have no reason to doubt that.
>
> Putting that last bold statement was asking for trouble, of course, and
> indeed Rails crashed with the typical Erie yellow-to-green upgrade.
> The fix to that has been pushed to master.
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835 Pfalzbahn token lay (was Re: Minor bug, 1835, 1.7.6)

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

> I was not yet able to test if the related 1830 Erie and 1856 THB home
hexes
> still work as before, but I have no reason to doubt that.

Putting that last bold statement was asking for trouble, of course, and
indeed Rails crashed with the typical Erie yellow-to-green upgrade.
The fix to that has been pushed to master.

Erik.

Re: [Rails-devel] 1835 Pfalzbahn token lay (was Re: Minor bug, 1835, 1.7.6)

[Mike B. <com...@ip...>]

I'm pretty sure that we were playing 1st edition English Rules. Perhaps this
is one of the changes that took place between the two editions? Is it worth
considering offering the two as options choices during game setup?

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com




---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120613-1, 14/06/2012
Tested on: 14/06/2012 3:46:13 PM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [Rails-devel] 1835 Pfalzbahn token lay (was Re: Minor bug, 1835, 1.7.6)

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

On 2012-06-13 12:18, Mike Bourke wrote:
> Not having a copy of the rules, I can't quote them to dispute this, but once
> the home railhead was layed, the understanding of the rules we always played
> by (and we did consult the rules during play) was that you could lay a rail
> head on any other empty city space (except those reserved for other
> corporations home bases). You didn't have to be connected to that city
> space. From memory it was $20 per hex removed but that I'm not completely
> sure of.

2nd edition English rules by John Webley:

   VIII.7)  A station marker may only be placed on a station that is directly
   connected with an existing station marker of that company.  The connecting
   route must not be blocked with markers of other companies.

The German equivalent appears to be in 5.5.2.7, though I don't really have that
language.

Re: [Rails-devel] 1835 Pfalzbahn token lay (was Re: Minor bug, 1835, 1.7.6)

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

I have fixed both A and B (pushed to master).  The below only applies to
(preprinted) tiles that have the relayBaseTokens="yes" Upgrade attribute in
TileSet.xml.  
So far, this only applies to upgrades of a yellow OO-style tile to a green
one.

In such cases, the UI code now does some additional checks:
1. If both a home token and a 'remote' token have been laid before on that
hex, the home company president gets the first turn to decide where to put
its token.
2. If a station (city) has no free spots, it is no longer offered as a
choice for token laying.
The existing code already took care, that a choice list of length one is
executed without asking.

The combination of the above checks ensures, that in the case mentioned only
the BA president gets a question asked.

As far as I could test, this works correctly for 1835 PfB on hex L6.
I was not yet able to test if the related 1830 Erie and 1856 THB home hexes
still work as before, but I have no reason to doubt that.

My commit also includes Stefan's fix for closing the PfB manually.

Erik.

> Current Rails implementation:
> A) If the Pfalz owner tries to place a token on LU/MA before the BA token
> gets laid, he first gets the choice to choose between two undefined
stations:
> Only after that selection he gets informed that he is not allowed to place
the
> token now (due to being home hex of BA).
> 
> B) Both owner of tokens get asked and both are free to choose any of the
> stations. If both choose the same station, several follow-up bugs occur
(only
> one token is shown, revenue calculation throws errors).
> This has to be changed that only the BA owner get asked, and the other
> token gets assigned accordingly.

[Rails-devel] 1830 D&H token lay (was: 1835 Pfalzbahn token lay (was Re: Minor bug, 1835, 1.7.6))

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

>
>> In Steve Thomas rules clarification it also addresses that this creates
>> the ambiguity what happens if the tile has been laid already, but does
>> not present a preferred answer (due to the building costs it is unlikely
>> to happen anyway). The further suggestion is that the
>> token laying right is lost if it is not executed immediately after the
>> tile laying property.
>
> This seems to me a silly argument because no one would want to lay the token
> without the tile if the private confers both abilities.  But I would rule
> that they are separable powers just to avoid the silliness of that "further
> suggestion," so if someone else has laid the tile you can still place the
> token (and the private closes when it has been used to lay the token and the
> tile has been laid by anybody).
>

I could still imagine several reasons for playing the token without 
laying the tile first, some of them might be less silly than assumed.

A) The tile lay still costs 120 due to the mountain in the hex which 
might not be the D&H owners treasury. Maybe another company will help 
out later, which is able to build D&H hex because of location.
B) A yellow city tile is not available at that time, but the 5 train is 
on the horizon and the company wants to have the token there.
C) The owner of the company that owns the D&H wants to create maximum 
mess to that company.

However how I read the rules is that the tile lay is required anyway as 
a condition for the token lay.

I cannot judge the degree of silliness that lead to Steve Thomas 
clarifications: However I would suggest that Rails should try to follow 
them over other possible interpretations.
But the discussion supports that it is better to prefer an 
implementation that allows different rule interpretations, but make 
players aware about this.

The D&H never closes after the use of either or both of the special 
properties, so luckily that is not an issue for 1830.

Re: [Rails-devel] 1835 Pfalzbahn token lay (was Re: Minor bug, 1835, 1.7.6)

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

I find this list much more useful, as well as the 18xx Family page linked
at the top of it.

http://boardgamegeek.com/wiki/page/18xx

As I recall, someone (John Tamplin?) put a huge amount of work into the
18xx pages on Wikipedia, only to see the work deleted and truncated by the
Wikipedia content police.

--
Chris

Please consider the environment before printing this e-mail.


On Wed, Jun 13, 2012 at 12:18 PM, Mike Bourke
<com...@ip...>wrote:

> Not having a copy of the rules, I can't quote them to dispute this, but
> once
> the home railhead was layed, the understanding of the rules we always
> played
> by (and we did consult the rules during play) was that you could lay a rail
> head on any other empty city space (except those reserved for other
> corporations home bases). You didn't have to be connected to that city
> space. From memory it was $20 per hex removed but that I'm not completely
> sure of.
>
> On a completely unrelated topic, the developers might find this list of
> 18xx
> games worth bookmarking: http://en.wikipedia.org/wiki/18XX_games
>
> Mike Bourke
> Campaign Mastery http://www.campaignmastery.com
> Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com
>
>
>
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 120612-1, 13/06/2012
> Tested on: 14/06/2012 5:18:10 AM
> avast! - copyright (c) 1988-2012 AVAST Software.
> http://www.avast.com
>
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1835 Pfalzbahn token lay (was Re: Minor bug, 1835, 1.7.6)

[Mike B. <com...@ip...>]

Not having a copy of the rules, I can't quote them to dispute this, but once
the home railhead was layed, the understanding of the rules we always played
by (and we did consult the rules during play) was that you could lay a rail
head on any other empty city space (except those reserved for other
corporations home bases). You didn't have to be connected to that city
space. From memory it was $20 per hex removed but that I'm not completely
sure of.

On a completely unrelated topic, the developers might find this list of 18xx
games worth bookmarking: http://en.wikipedia.org/wiki/18XX_games

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120612-1, 13/06/2012
Tested on: 14/06/2012 5:18:10 AM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [Rails-devel] 1835 Pfalzbahn token lay (was Re: Minor bug, 1835, 1.7.6)

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

On 2012-06-12 04:46, Mike Bourke wrote:
> However, there are some games (I forget which) that specifically prohibit
> the laying of railheads other than the home railhead unless you are
> connected by track to that location. I remember this because one of the
> things that made 1835 so distinctive (relative to the other 18xx games) was
> that you could lay a rail head anywhere, it was only a question of the
> distance from your home base.

To my knowledge this is not true and has never been true.  All games require
a track connection for non-home tokens unless you are using an explicit special
power (D&H, Pfalz, NF, or the like).

On 2012-06-13 10:38, Stefan Frey wrote:
> ** Rules on D&H in 1830:
> I re-read the 1830 rules on D&H they seem to be pretty clear that the 
> tile laying step is the condition for the token lay of D&H (so we played 
> that correctly many years ago).
> 
> In Steve Thomas rules clarification it also addresses that this creates 
> the ambiguity what happens if the tile has been laid already, but does 
> not present a preferred answer (due to the building costs it is unlikely 
> to happen anyway). The further suggestion is that the
> token laying right is lost if it is not executed immediately after the 
> tile laying property.

This seems to me a silly argument because no one would want to lay the token
without the tile if the private confers both abilities.  But I would rule
that they are separable powers just to avoid the silliness of that "further
suggestion," so if someone else has laid the tile you can still place the
token (and the private closes when it has been used to lay the token and the
tile has been laid by anybody).

[Rails-devel] 1830 D&H token lay (was:1835 Pfalzbahn token lay (was Re: Minor bug, 1835, 1.7.6))

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

Mike:
You are right laying the home token was always the exception to the 
case. However I was thinking about those cases where a special property
allowed the laying an unconnected token.

** Rules on D&H in 1830:
I re-read the 1830 rules on D&H they seem to be pretty clear that the 
tile laying step is the condition for the token lay of D&H (so we played 
that correctly many years ago).

In Steve Thomas rules clarification it also addresses that this creates 
the ambiguity what happens if the tile has been laid already, but does 
not present a preferred answer (due to the building costs it is unlikely 
to happen anyway). The further suggestion is that the
token laying right is lost if it is not executed immediately after the 
tile laying property.

** Rails implementation:

Both D&H rights are implemented as being independent.
* It is possible to lay the token without laying the tile first.
* It is possible to lay the tile and the token later.

In my view the implementation does not confirm to the rules, however 
this is only missing rules enforcement, thus it allows illegal actions, 
it does not prevent allowed actions.
So the best workaround is mentioning in the limitations section of 1830.

Stefan



On 06/12/2012 01:46 PM, Mike Bourke wrote:
>> Most likely there is no rule that is generally illegal to lay the token
>> without a tile (for those cases when there is no connectivity requirement).
>
>> However I do not remember by heart if there is any 18xx rule-set which
>> explicitly allows this (have not played 18GA yet).
>
> It's easy to demonstrate that this is explicitly possible by considering the
> home location of the Erie in 1830. It is a double city with no inbuilt
> track. Therefore, until green tiles become available, it cannot connect with
> anything, but there is no rule that prevents launching the company (and
> placing a railhead) prior to green tiles. It's a silly move, but not am
> illegal one.
>
> However, there are some games (I forget which) that specifically prohibit
> the laying of railheads other than the home railhead unless you are
> connected by track to that location. I remember this because one of the
> things that made 1835 so distinctive (relative to the other 18xx games) was
> that you could lay a rail head anywhere, it was only a question of the
> distance from your home base.
>
> Mike Bourke
> Campaign Mastery http://www.campaignmastery.com
> Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com
>
>
>
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 120611-1, 12/06/2012
> Tested on: 12/06/2012 9:46:02 PM
> avast! - copyright (c) 1988-2012 AVAST Software.
> http://www.avast.com
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835 Pfalzbahn token lay (was Re: Minor bug, 1835, 1.7.6)

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

> Conclusion:
> I will add the CloseManually Option to the Pfalzbahn and then everyone can
> continue to play according to their own rules.

And I intend to have a look at the UI problems that Stefan has mentioned.

Erik.

Re: [Rails-devel] 1835 Pfalzbahn token lay (was Re: Minor bug, 1835, 1.7.6)

[Mike B. <com...@ip...>]

>Most likely there is no rule that is generally illegal to lay the token 
>without a tile (for those cases when there is no connectivity requirement).

>However I do not remember by heart if there is any 18xx rule-set which 
>explicitly allows this (have not played 18GA yet).

It's easy to demonstrate that this is explicitly possible by considering the
home location of the Erie in 1830. It is a double city with no inbuilt
track. Therefore, until green tiles become available, it cannot connect with
anything, but there is no rule that prevents launching the company (and
placing a railhead) prior to green tiles. It's a silly move, but not am
illegal one.

However, there are some games (I forget which) that specifically prohibit
the laying of railheads other than the home railhead unless you are
connected by track to that location. I remember this because one of the
things that made 1835 so distinctive (relative to the other 18xx games) was
that you could lay a rail head anywhere, it was only a question of the
distance from your home base.

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120611-1, 12/06/2012
Tested on: 12/06/2012 9:46:02 PM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

[Rails-devel] 1835 Pfalzbahn token lay (was Re: Minor bug, 1835, 1.7.6)

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

>
> I don't think it is generally illegal (in 1835 or in most 18xx games) to lay a
> token on a city hex with no track without placing a tile first.  Indeed, the
> Waycross&  Southern private company power in 18GA is meant to be used this way
> (since it lets you "teleport in" a token, but you have to wait until the tile
> lay phase of the next turn before you can start building track from that token).
>
Most likely there is no rule that is generally illegal to lay the token 
without a tile (for those cases when there is no connectivity requirement).

However I do not remember by heart if there is any 18xx rule-set which 
explicitly allows this (have not played 18GA yet).

I cannot check the 1830 rules now, but do they allow to use the D&H 
teleport to only lay the token onto the hex without laying the tile 
first if it is not laid yet?  I have never played it that way, but maybe 
my group was not creative enough.

OK let us assume that the Pfalzbahn token can be laid before the tile is 
laid. What are the further consequences?

Rules:
A) It is still valid that the token can only be laid after the Baden 
token has been laid on the hex (compare VIII-10 in the 2nd English 
rules), which occurs as soon as the BA floats.

B) As soon as the green tile is laid on LU/MA hex and/or at start of the 
next OR the BA owner decides where the station is laid.

Current Rails implementation:
A) If the Pfalz owner tries to place a token on LU/MA before the BA 
token gets laid, he first gets the choice to choose between two 
undefined stations: Only after that selection he gets informed that he 
is not allowed to place the token now (due to being home hex of BA).

B) Both owner of tokens get asked and both are free to choose any of the 
stations. If both choose the same station, several follow-up bugs
occur (only one token is shown, revenue calculation throws errors).
This has to be changed that only the BA owner get asked, and the other
token gets assigned accordingly.

Required Fixes:
The implementation allows correct play, A) is only ugly, B) allows the 
game to be screwed, however undo or reload fixes the issues.

So it is possible to play with the Pfalzbahn token laid on the hex 
without a tile, however it triggers some ugly UI behavior.

> I don't think that question really matters here, though.  Even without using
> the Pfalz, it's usually quite possible for other players to lay a green tile in
> Ludwigshafen/Mannheim before BA first operates, and if they don't, BA will.
>
> The question then becomes, should the Pfalz owner be stuck with the private
> until the first 5-train purchase just because someone else laid a tile there?
> I think not, and I offer the OBB (which closes when *anybody* lays tiles on
> both of its hexes) as an example in support of that position.
>

You are right, going back to the start:
Seems that there is no unique rule agreement, so allowing both 
interpretations without adding game options seems the best way going 
forward for now.

Conclusion:
I will add the CloseManually Option to the Pfalzbahn and then everyone 
can continue to play according to their own rules.

Stefan

Re: [Rails-devel] Minor bug, 1835, 1.7.6

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

On 2012-06-11 10:47, Stefan Frey wrote:
>> Now it is important for the 1st edition/English rules interpretation if 
>> a tile laying action of a player who does not own the Pfalzbahn is 
>> enough to fit the condition stated above. If so the two conditions are 
>> identical, if we assume that the tile has to be laid before a token can 
>> be laid.
>>
>> However interestingly the rules state that the Pfalzbahn owner is 
>> allowed to "... lay a station marker onto this hex". This could be read 
>> as it might even be possible to lay a token before the green tile is laid.

I don't think it is generally illegal (in 1835 or in most 18xx games) to lay a
token on a city hex with no track without placing a tile first.  Indeed, the
Waycross & Southern private company power in 18GA is meant to be used this way
(since it lets you "teleport in" a token, but you have to wait until the tile
lay phase of the next turn before you can start building track from that token).

I don't think that question really matters here, though.  Even without using
the Pfalz, it's usually quite possible for other players to lay a green tile in
Ludwigshafen/Mannheim before BA first operates, and if they don't, BA will.

The question then becomes, should the Pfalz owner be stuck with the private
until the first 5-train purchase just because someone else laid a tile there?
I think not, and I offer the OBB (which closes when *anybody* lays tiles on
both of its hexes) as an example in support of that position.

On 2012-06-11 12:36, Erik Vos wrote:
> Practice tells, that if a rule can be interpreted in different ways, then
> that is exactly what is going to happen. 
> For that reason, I would prefer to go for the manual closure workaround,
> rather than trying to satisfy all tastes by adding options.

Makes sense.

Re: [Rails-devel] Updated rails 2.0 branch

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

On Mon, Jun 11, 2012 at 3:20 PM, Erik Vos <eri...@xs...> wrote:
> Stefan,
>
> Strange things sometimes happen: your response ended up in my junk mail, and
> I just found it.
>
> I sent my question off-list because I was just curious about the reason why
> you renamed Round to AbstractRound.  I had intended to reserve expressing my
> dislike of that change for a follow-up, if still relevant at all.  But you
> guessed it.  I don't see why the fact that a superclass is abstract should
> be expressed in its name.  If a developer working on a subclass forgets
> that, he'll find out soon enough.  But it's probably just a matter of taste
> - as always.

The one case where I could see this making sense is if we want the
base non-abstract class to be called Round. In that case, we can't
have an abstract class called Round, too. So, calling it
"AbstractRound" or "aRound" or "RoundA" or whatever makes some sense.

Then you have "class Round implements AbstractRound {}" despite also
having the very redundant "abstract class AbstractRound {}".

However, if all of our non-abstract classes are FooRound and BarRound,
then having the abstract class be Round is fine.

>
> On interfaces: I don't like the 'I' postfix either.
> When we started Rails, some people gave their well-meant advices, and I did
> not have much background in Java design, so I went ahead as they told me.
> But here I am on your side.  All or most 'I' interfaces we have are useless
> (in fact: annoying), and if you want to get rid of these, you have my full
> support.
>

+1

This one's my fault. I was also new to Java when I started this
project. So, I was using what I was told were "good" java conventions.
Now that I've done a few more projects in a variety of languages, I
find that I was misusing the convention.

Having interfaces is good if we expose an API, but most of the current
interfaces in the Rails code really aren't useful in that sense. Let's
toss them and, at some future point, we can revisit the issue of what
classes and methods should be a part of a public API and what stuff
ought to be private/protected.

> Erik.
>

---Brett.

>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Monday, May 28, 2012 5:14 PM
>> To: Erik Vos
>> Subject: Re: [Rails-devel] Updated rails 2.0 branch
>>
>> Follow-up:
>> I do not mind to make such discussions on-list, as this can help to
> generate a
>> list of coding standards for Rails.
>> But that is up to you to decide (I did not even imagined to be this
> off-list, but
>> I wondered why it did not came back from the list ...) Stefan
>>
>>
>> Erik:
>> Rails2.0 should not be "my" project, even if I am the driving force
>> behind the refactoring.
>>
>> Good to see your comments:
>>
>> Naming is convention, and mostly a matter of taste. First of all I do
>> not like the postfix -I convention.
>>
>> My preference for Interface names are to either use adjectives, for
>> example Ownable, Observable etc.
>>
>> If I realize that most classes that are derived from an Interface uses
>> the same base implementation I use an abstract Class and prefer a short
>> noun like State, Model etc.
>>
>> If I do not come up with a good adjective for the Interface I use a
>> short noun there (like Item instead of "Itemizeable" or "Roundable") and
>> if I now add a baseline abstract class I prefix with Abstract (e.g.
>> AbstractItem and AbstractRound).
>>
>> However if every class that implements the Interface is derived from the
>> abstract class there is no need to keep the Interface and I drop it, as
>> it is easy to factor it out again later on - if needed.
>>
>> I could have removed the Round interface altogether and rename
>> AbstractRound to Round again, but I did not focus on that so far, as I
>> intend to change the Round mechanism anyway.
>>
>> But if you prefer to keep at least RoundI as historical artifact, this
>> is possible.
>>
>> Stefan
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Minor bug, 1835, 1.7.6

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

Practice tells, that if a rule can be interpreted in different ways, then
that is exactly what is going to happen. 
For that reason, I would prefer to go for the manual closure workaround,
rather than trying to satisfy all tastes by adding options.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, June 11, 2012 7:47 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Minor bug, 1835, 1.7.6
> 
> Maybe we have discussed that before (Pfalz is always a trouble maker if it
> comes to rules), but I could not find that exact issue:
> 
> A) Rules:
> Is there a general consent of 1835 players what the condition is that the
> Pfalzbahn closes?
> 
> The German rules on boardgamegeek (this is the 2nd German edition rules)
> state under 3.1.3.3 that the Pfalzbahn closes after laying the free token.
> 
> The English rules on boardgamegeek (this is the 2nd English translation of
the
> 1st German edition rules) state in section II that the Pfalzbahn closes as
soon
> as both actions as been carried out.
> 
> Now it is important for the 1st edition/English rules interpretation if a
tile
> laying action of a player who does not own the Pfalzbahn is enough to fit
the
> condition stated above. If so the two conditions are identical, if we
assume
> that the tile has to be laid before a token can be laid.
> 
> However interestingly the rules state that the Pfalzbahn owner is allowed
to
> "... lay a station marker onto this hex". This could be read as it might
even be
> possible to lay a token before the green tile is laid.
> 
> B) Current Implementation:
> Rails currently requires both special properties to be taken before the
> Pfalzbahn closes. If another player lays the tile the token lay property
is not
> activated and the token lay alone does not activate the closing condition.
> 
> C) Possible Solutions:
> It is easy to add a <CloseManually/> tag to the Pfalzbahn xml definition,
in
> this case it is possible to close the Pfalzbahn manually, similar to the
OBB. This
> is also a quick-workaround and does not change the action-set, thus is
> reload-compatible.
> 
> If all agree that the token lay alone closes the Pfalzbahn (as in the 2nd
edition
> German rules, which have no  English equivalent as far as I know), then it
> would be possible to implement a solution that it is possible to define a
> SpecialProperty which after activation closes the private company. So far
it is
> only possible for multiple-power privates that either all or any closes
the
> private.
> 
> However such a change could prevent reloading existing 1835 games.
> 
> 
> On 06/10/2012 10:19 PM, John David Galt wrote:
> > The BY just used the Pfalz to place a token, which is supposed to
> > close the Pfalz but didn't.  (The BA laid its own home tile.)
> >
> > Perhaps a "close private" menu option is called for as in 1856.
> >
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the
> > latest in malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >
> >
> >
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware
threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Updated rails 2.0 branch

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

Stefan,

Strange things sometimes happen: your response ended up in my junk mail, and
I just found it.

I sent my question off-list because I was just curious about the reason why
you renamed Round to AbstractRound.  I had intended to reserve expressing my
dislike of that change for a follow-up, if still relevant at all.  But you
guessed it.  I don't see why the fact that a superclass is abstract should
be expressed in its name.  If a developer working on a subclass forgets
that, he'll find out soon enough.  But it's probably just a matter of taste
- as always.

On interfaces: I don't like the 'I' postfix either.
When we started Rails, some people gave their well-meant advices, and I did
not have much background in Java design, so I went ahead as they told me.
But here I am on your side.  All or most 'I' interfaces we have are useless
(in fact: annoying), and if you want to get rid of these, you have my full
support.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, May 28, 2012 5:14 PM
> To: Erik Vos
> Subject: Re: [Rails-devel] Updated rails 2.0 branch
> 
> Follow-up:
> I do not mind to make such discussions on-list, as this can help to
generate a
> list of coding standards for Rails.
> But that is up to you to decide (I did not even imagined to be this
off-list, but
> I wondered why it did not came back from the list ...) Stefan
> 
> 
> Erik:
> Rails2.0 should not be "my" project, even if I am the driving force
> behind the refactoring.
> 
> Good to see your comments:
> 
> Naming is convention, and mostly a matter of taste. First of all I do
> not like the postfix -I convention.
> 
> My preference for Interface names are to either use adjectives, for
> example Ownable, Observable etc.
> 
> If I realize that most classes that are derived from an Interface uses
> the same base implementation I use an abstract Class and prefer a short
> noun like State, Model etc.
> 
> If I do not come up with a good adjective for the Interface I use a
> short noun there (like Item instead of "Itemizeable" or "Roundable") and
> if I now add a baseline abstract class I prefix with Abstract (e.g.
> AbstractItem and AbstractRound).
> 
> However if every class that implements the Interface is derived from the
> abstract class there is no need to keep the Interface and I drop it, as
> it is easy to factor it out again later on - if needed.
> 
> I could have removed the Round interface altogether and rename
> AbstractRound to Round again, but I did not focus on that so far, as I
> intend to change the Round mechanism anyway.
> 
> But if you prefer to keep at least RoundI as historical artifact, this
> is possible.
> 
> Stefan

Re: [Rails-devel] Minor bug, 1835, 1.7.6

[Mike B. <com...@ip...>]

The current implementation matches the rules as my group of players have
always interpreted them.

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120610-1, 11/06/2012
Tested on: 12/06/2012 3:51:05 AM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [Rails-devel] Minor bug, 1835, 1.7.6

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

Maybe we have discussed that before (Pfalz is always a trouble maker if 
it comes to rules), but I could not find that exact issue:

A) Rules:
Is there a general consent of 1835 players what the condition is that 
the Pfalzbahn closes?

The German rules on boardgamegeek (this is the 2nd German edition rules) 
state under 3.1.3.3 that the Pfalzbahn closes after laying
the free token.

The English rules on boardgamegeek (this is the 2nd English translation
of the 1st German edition rules) state in section II that the Pfalzbahn 
closes as soon as both actions as been carried out.

Now it is important for the 1st edition/English rules interpretation if 
a tile laying action of a player who does not own the Pfalzbahn is 
enough to fit the condition stated above. If so the two conditions are 
identical, if we assume that the tile has to be laid before a token can 
be laid.

However interestingly the rules state that the Pfalzbahn owner is 
allowed to "... lay a station marker onto this hex". This could be read 
as it might even be possible to lay a token before the green tile is laid.

B) Current Implementation:
Rails currently requires both special properties to be taken before the 
Pfalzbahn closes. If another player lays the tile the token lay property 
is not activated and the token lay alone does not activate the closing 
condition.

C) Possible Solutions:
It is easy to add a <CloseManually/> tag to the Pfalzbahn xml 
definition, in this case it is possible to close the Pfalzbahn manually, 
similar to the OBB. This is also a quick-workaround and does not change 
the action-set, thus is reload-compatible.

If all agree that the token lay alone closes the Pfalzbahn (as in the 
2nd edition German rules, which have no  English equivalent as far as I 
know), then it would be possible to implement a solution that it is 
possible to define a SpecialProperty which after activation closes the
private company. So far it is only possible for multiple-power privates 
that either all or any closes the private.

However such a change could prevent reloading existing 1835 games.


On 06/10/2012 10:19 PM, John David Galt wrote:
> The BY just used the Pfalz to place a token, which is supposed to close the
> Pfalz but didn't.  (The BA laid its own home tile.)
>
> Perhaps a "close private" menu option is called for as in 1856.
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel