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

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

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.

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

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

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

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.

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

>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

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

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

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

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.

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

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
>

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

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

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

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

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.

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

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

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

Warning: 200+ column ASCII-art follows.

On 2012-06-13 15:49, Erik Vos wrote:
> My commit also includes Stefan's fix for closing the PfB manually.

This patch appears to cause a new problem.  Once I have closed PfB manually,
saving the game no longer works for the rest of that game.

When I try to perform a save I get this pop-up:

  +-----------------------------------------------------------------------------------------------+
  | Message                                                                                       |
  +-----------------------------------------------------------------------------------------------+
  | Save failed, reason: rails.game.PrivateCompany                                                |
  | Unexpected action: Save path=C:\Programming\Rails\1835_20120722_0112_OperatingRound 8.1.rails |
  |                                                                                               |
  |                                               [ OK ]                                          |
  +-----------------------------------------------------------------------------------------------+

The save file is still created (and attached to this message), but trying to
reload it produces this pop-up:

  +-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  | Message                                                                                                                                                                                             |
  +-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  | Load failed, Reason = writing aborted; java.io.NotSerializableException: rails.game.PrivateCompany To improve Rails please submit save file to Rails user list at rai...@li... |
  | Load failed, Reason = loaded file has less actions than current game To improve Rails please submit save file to Rails user list at rai...@li...                               |
  |                                                                                                                                                                                                     |
  |                                                                                             [ OK ]                                                                                                  |
  +-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

Thanks for reporting this bug:
This was a pretty stupid one caused by my own code for the ClosePrivate 
action.
There was the transient keyword missing for the PrivateCompany field to 
avoid its de-serialization (Rails never serializes the objects 
themselves, only the identifiers/names).

I have attached both the fixed save file and a save file including the 
ClosePrivate action added.

Fix is pushed to the Rails1.7.x branch.
I will release Rails 1.7.8 tomorrow, maybe Erik will add his fix for the 
status window bug too?

Stefan

On 07/22/2012 03:36 AM, John David Galt wrote:
> Warning: 200+ column ASCII-art follows.
>
> On 2012-06-13 15:49, Erik Vos wrote:
>> My commit also includes Stefan's fix for closing the PfB manually.
>
> This patch appears to cause a new problem.  Once I have closed PfB manually,
> saving the game no longer works for the rest of that game.
>
> When I try to perform a save I get this pop-up:
>
>    +-----------------------------------------------------------------------------------------------+
>    | Message                                                                                       |
>    +-----------------------------------------------------------------------------------------------+
>    | Save failed, reason: rails.game.PrivateCompany                                                |
>    | Unexpected action: Save path=C:\Programming\Rails\1835_20120722_0112_OperatingRound 8.1.rails |
>    |                                                                                               |
>    |                                               [ OK ]                                          |
>    +-----------------------------------------------------------------------------------------------+
>
> The save file is still created (and attached to this message), but trying to
> reload it produces this pop-up:
>
>
>    +-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
>    | Message                                                                                                                                                                                             |
>    +-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
>    | Load failed, Reason = writing aborted; java.io.NotSerializableException: rails.game.PrivateCompany To improve Rails please submit save file to Rails user list at rai...@li... |
>    | Load failed, Reason = loaded file has less actions than current game To improve Rails please submit save file to Rails user list at rai...@li...                               |
>    |                                                                                                                                                                                                     |
>    |                                                                                             [ OK ]                                                                                                  |
>    +-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
>
>
>
> ------------------------------------------------------------------------------
> 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
>

> I will release Rails 1.7.8 tomorrow, maybe Erik will add his fix for the
status
> window bug too?

Will try, if I can decide what the fix will be. I'll possibly add and update
PD to the lower caption row throughout.

> I'll possibly add and update PD to the lower caption row throughout.

That's how I have fixed it now.  Pushed to master.

Erik.