Re: [Rails-devel] Problem with 1835 PfB

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

Aha, thanks, that clarifies it sufficiently.

All I have to do then is to undo most of a change that I did three months
ago.  That change was more a workaround than a fix for the reported problem
that placing the BA home token was asked to the wrong player.  The
workaround was to move the BA home token placement to the first BA OR turn.

Now it turns out that this change precludes correct play in some cases, so
it must be reverted.

The question asked to the NY president was (and will become again):
"<BY-president>, select a station on hex L6 for the BA home base token".
I will see if I can put the correct name (of the BA president) into that
question, but it will still be asked to the BY-president.
Stay tuned.

Erik.


> -----Original Message-----
> From: Schnell, Volker [mailto:vol...@ar...]
> Sent: Tuesday, February 21, 2012 3:26 PM
> To: rai...@li...
> Subject: Re: [Rails-devel] Problem with 1835 PfB
> 
> Hi Erik,
> 
> the english translation is missing an important sentence.
> chapter 5.5.10 3rd Sentence. (VII.10 in the english rules)"Wird das Feld
> bebaut, nachdem dort bereits der Baden-Bahnhof liegt, dann muß der
> Baden-Direktor sofort eine der beiden Städte für seinen Heimatbahnhof
> auswählen, der andere Bahnhof kann dann schon von der gerade bauenden
> Gesellschaft errrichtet werden.
> "if the Tile is built, when the baden Home-token already exists, the baden
> Director must choose immediately one of the cities as the homestation. The
> other one can be used by the building Company."
> The Baden-Token is placed on the Yellow Field, like the Wt-Token and has
to
> assigned to a city, when a tile is placed.
> 
> The hometokens are laid in the stockround, when the company is floated
> (sometimes a problem, when Baden and Hessen opens in the same
> stockround and a Bayern-Token exist in Frankfurt. No Chance for the Baden
> to get throu Frankfurt).
> 
> the Simple approach, that the current Player lays the Bad-token, is for me
ok.
> 
> Volker
> 
> Am 21.02.2012 14:33, schrieb Erik Vos:
> > 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.
> >
> >
> > ----------------------------------------------------------------------
> > -------- Keep Your Developer Skills Current with LearnDevNow!
> > The most comprehensive online learning library for Microsoft
> > developers is just $99.99! Visual Studio, SharePoint, SQL - plus
> > HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when
> you subscribe now!
> > http://p.sf.net/sfu/learndevnow-d2d
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> --
> Volker Schnell
> email: vol...@ar...
> homepage: home.arcor.de\volker_schnell
> 
> 
>
----------------------------------------------------------------------------
--
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel