Re: [Rails-devel] Problem with 1835 PfB

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

Martin,

> 1. the Map Definition of the Hex is wrong...

I suppose you refer to 'unlaidHomeBlocksTokens="yes" '.  That indeed causes the behaviour that Volker is complaining about.
Strictly spoken this attribute is still valid: BA must lay its home token before BY can add its token.  
The question is: exactly WHEN must BA lay its home token in such a case?

The rules (English v2) say: "... the new Baden director decides in the next operating round which of the two stations to occupy with its station marker."
But the rules don't say *when* in that OR he must take that decision. 
Possibilities I see: (1) at the start of the OR, or (2) in its own turn, or (3) in its own turn or earlier as soon as another company wants to lay a second token on L6 (either using PfB, or by a normal token lay).

Current implementation is (2), as is correct for Erie(1830) and THB (1856). There the hex remains blocked until after the home token has been laid normally.  
If this interpretation would hold for the BA as well, there is no problem at all. BY must wait until BA has had a turn.

Now Volker appears to favour interpretation (3).  I'm actually not sure if that interpretation is correct.  Any other opinions?

I have been working to implement (3) by actually giving the BA director an intervening turn, but that turns out to be rather complex and tricky, and I think I'll abandon that approach.
We need a generic solution for such problems, but such a solution will not fit well into the current architecture. Let's await which direction Rails will take in the near future before trying again.

A simpler approach would be to have the current player (the BY president) place the BA token. So these players (if different) must consult each other, but that is not uncommon in Dropbox Rails. That approach sounds doable now, but let's first discuss what the real need is.

> 2. the method to move a token on a hex after that token has been laid is not yet implemented i am afraid.
 
I'm not sure what you mean here.  Tokens can never be moved.  
In some cases, initial token placement is provisional.  That is the case if the tile hasn't any tracks yet.  As soon as a tile with tracks is placed, actual token placement follows.
That has been implemented and it works (at least it did last time I looked). 

> 3. if you alter the map definition for that hex in 1835/Map.xml the game declares the save file invalid because it expects a different action...
 
Then game loading breaks down in an earlier stage.  I'm not sure exactly why, but meddling with the course of events often (if not always) renders saved files invalid.

Erik.