rails-devel

[Rails-devel] Swing Docking Framework for Rails

[Frederick W. <fre...@go...>]

I've done some internet research for finding the "best" LGPL Swing
docking framework, which appears to be DockingFrames. Based on that
framework, I developed a very small prototype that puts that OR Window
on the docking framework.

Instead of pushing to prototype to the dev branch, I attached it as
patches so that you can have a look at this technology.

In any case, I think we need to have a strong buy-in by everyone
before being able to move to this framework.

-- Frederick

===============
Details: DockingFrames
===============

Links:
- Homepage: http://dock.javaforge.com/
- Javadoc: http://dock.javaforge.com/dockingFrames_v1.1.0/doc/index.html
- Examples: http://dock.javaforge.com/help.html
- Forum: http://forum.byte-welt.de/forumdisplay.php?f=69&langid=2

Key advantages (at the first glance)
- LGPL
- Allows for both
   - convenient access to docking functionality ("common" jar")
       -> easy to start with (see prototype)
   - deep configurability ("core" jar)
       -> easy to adapt to future more sophisticated requirements
- Rich feature set

===============
Details: Prototype
===============

Implementation:
- added just about 20 lines to ORWindow
- had to suppress triggering ORWindow revalidation as the docking
framework takes care of that

First findings:
- dockables can be detached from their master frame
   -> finally, the OR panel can be put somewhere else
- Stefan will like the docking tooltips - others probably not... ^_^
   - but should be no issue to find out how to set them to English

Re: [Rails-devel] Swing Docking Framework for Rails

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

Frederick:

thanks for sharing your prototype.

A general remark first:
Agreement on the tools is good, however I do not know if everyone has to 
commit to one framework before you could start.
Three reasons for that: First Rails could support several UIs and second
the one who codes is the one who has to live with the choice.
And third not everyone has the time to do a full evaluation, so most 
cannot commit themselves at this time.
If you come up with something that looks nice both in practice and in 
code people will trust that your choice was the right one.


On the choice of libraries:
A docking framework was on my radar at the time I started coding on 
Rails. I actually did have a look at some of the frameworks (but not 
actually trying to code against them) and DockingFrames was my favorite
at that time too (and it is still under development, which is good given 
that Swing is not a rising star anymore). Alternatives at that time I 
really considered have been Infonode (dual licensed with GPL) or Jide 
(provides free licences to open source projects on request).

I also had a look at alternative LayoutManagers and my preference there 
was to test at least DesignGridLayout 
(http://designgridlayout.java.net/index.html), which seems both easy to 
use and provides a lot of features.

UI development in the longer run:
That is my major concern at the moment: One of the design goals of 
Rails2.0 state and model refactoring is the optimization of UI update 
messages: The amount of round-trip messages between the game engine and 
the UI should be minimal to allow running the game over low-bandwidth 
and latent connections. This would strongly broaden the possibilities of 
UI creation to have the UI for example running inside a browser or on a 
mobile gadget.
Still as this is a long-run development it does not conflict with your 
short to medium-term of refactoring the Swing UI, but I want to share
my thoughts on that.

A target for me that comes before rewriting the UI, but still after the 
core Rails2.0 refactoring is multi-player support via the internet.
My current intention is to employ the XMPP-Protocol, which should in 
principle allow us to rely on existing XMPP-servers which provide the 
required functionality. This might have some impact on the UI, but I do 
not expect that to be to serious, as in a first approach every player 
will have its own game engine running on its local PC which are 
synchronized via messages (similar to how VASSAL works, but replacing 
the central VASSAL server by a multi-puropose XMPP server, which if I 
remember correctly is something VASSAL intends to do in the future too).

No time to have a look at the patch so far, so nothing on that.

Stefan



On 02/02/2012 01:56 PM, Frederick Weld wrote:
> I've done some internet research for finding the "best" LGPL Swing
> docking framework, which appears to be DockingFrames. Based on that
> framework, I developed a very small prototype that puts that OR Window
> on the docking framework.
>
> Instead of pushing to prototype to the dev branch, I attached it as
> patches so that you can have a look at this technology.
>
> In any case, I think we need to have a strong buy-in by everyone
> before being able to move to this framework.
>
> -- Frederick
>
> ===============
> Details: DockingFrames
> ===============
>
> Links:
> - Homepage: http://dock.javaforge.com/
> - Javadoc: http://dock.javaforge.com/dockingFrames_v1.1.0/doc/index.html
> - Examples: http://dock.javaforge.com/help.html
> - Forum: http://forum.byte-welt.de/forumdisplay.php?f=69&langid=2
>
> Key advantages (at the first glance)
> - LGPL
> - Allows for both
>     - convenient access to docking functionality ("common" jar")
>         ->  easy to start with (see prototype)
>     - deep configurability ("core" jar)
>         ->  easy to adapt to future more sophisticated requirements
> - Rich feature set
>
> ===============
> Details: Prototype
> ===============
>
> Implementation:
> - added just about 20 lines to ORWindow
> - had to suppress triggering ORWindow revalidation as the docking
> framework takes care of that
>
> First findings:
> - dockables can be detached from their master frame
>     ->  finally, the OR panel can be put somewhere else
> - Stefan will like the docking tooltips - others probably not... ^_^
>     - but should be no issue to find out how to set them to English
>
>
>
> ------------------------------------------------------------------------------
> 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

Re: [Rails-devel] Swing Docking Framework for Rails

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

On Thu, Feb 2, 2012 at 8:35 AM, Stefan Frey <ste...@we...> wrote:
> Frederick:
>
> thanks for sharing your prototype.
>
> A general remark first:
> Agreement on the tools is good, however I do not know if everyone has to
> commit to one framework before you could start.
> Three reasons for that: First Rails could support several UIs and second
> the one who codes is the one who has to live with the choice.
> And third not everyone has the time to do a full evaluation, so most
> cannot commit themselves at this time.
> If you come up with something that looks nice both in practice and in
> code people will trust that your choice was the right one.
>

+1. Agreed.

>
> On the choice of libraries:
> A docking framework was on my radar at the time I started coding on
> Rails. I actually did have a look at some of the frameworks (but not
> actually trying to code against them) and DockingFrames was my favorite
> at that time too (and it is still under development, which is good given
> that Swing is not a rising star anymore). Alternatives at that time I
> really considered have been Infonode (dual licensed with GPL) or Jide
> (provides free licences to open source projects on request).
>

A quick note about licensing. This is an incredibly thorny issue. I
don't want to jump too far down this rabbit hole, but I'd like to
provide at least some basic guidance.

When considering any libraries or frameworks for use, please only
consider those with GPL-compatible licensing. (See:
http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses )

Our main code base is licensed under the GPL v2 or newer, and so any
libraries or frameworks we rely on must be able to play nicely with
our own code. :-)

> I also had a look at alternative LayoutManagers and my preference there
> was to test at least DesignGridLayout
> (http://designgridlayout.java.net/index.html), which seems both easy to
> use and provides a lot of features.
>
> UI development in the longer run:
> That is my major concern at the moment: One of the design goals of
> Rails2.0 state and model refactoring is the optimization of UI update
> messages: The amount of round-trip messages between the game engine and
> the UI should be minimal to allow running the game over low-bandwidth
> and latent connections. This would strongly broaden the possibilities of
> UI creation to have the UI for example running inside a browser or on a
> mobile gadget.
> Still as this is a long-run development it does not conflict with your
> short to medium-term of refactoring the Swing UI, but I want to share
> my thoughts on that.
>
> A target for me that comes before rewriting the UI, but still after the
> core Rails2.0 refactoring is multi-player support via the internet.
> My current intention is to employ the XMPP-Protocol, which should in
> principle allow us to rely on existing XMPP-servers which provide the
> required functionality. This might have some impact on the UI, but I do
> not expect that to be to serious, as in a first approach every player
> will have its own game engine running on its local PC which are
> synchronized via messages (similar to how VASSAL works, but replacing
> the central VASSAL server by a multi-puropose XMPP server, which if I
> remember correctly is something VASSAL intends to do in the future too).
>
> No time to have a look at the patch so far, so nothing on that.
>
> Stefan
>

---Brett.

>
>
> On 02/02/2012 01:56 PM, Frederick Weld wrote:
>> I've done some internet research for finding the "best" LGPL Swing
>> docking framework, which appears to be DockingFrames. Based on that
>> framework, I developed a very small prototype that puts that OR Window
>> on the docking framework.
>>
>> Instead of pushing to prototype to the dev branch, I attached it as
>> patches so that you can have a look at this technology.
>>
>> In any case, I think we need to have a strong buy-in by everyone
>> before being able to move to this framework.
>>
>> -- Frederick
>>
>> ===============
>> Details: DockingFrames
>> ===============
>>
>> Links:
>> - Homepage: http://dock.javaforge.com/
>> - Javadoc: http://dock.javaforge.com/dockingFrames_v1.1.0/doc/index.html
>> - Examples: http://dock.javaforge.com/help.html
>> - Forum: http://forum.byte-welt.de/forumdisplay.php?f=69&langid=2
>>
>> Key advantages (at the first glance)
>> - LGPL
>> - Allows for both
>>     - convenient access to docking functionality ("common" jar")
>>         ->  easy to start with (see prototype)
>>     - deep configurability ("core" jar)
>>         ->  easy to adapt to future more sophisticated requirements
>> - Rich feature set
>>
>> ===============
>> Details: Prototype
>> ===============
>>
>> Implementation:
>> - added just about 20 lines to ORWindow
>> - had to suppress triggering ORWindow revalidation as the docking
>> framework takes care of that
>>
>> First findings:
>> - dockables can be detached from their master frame
>>     ->  finally, the OR panel can be put somewhere else
>> - Stefan will like the docking tooltips - others probably not... ^_^
>>     - but should be no issue to find out how to set them to English
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>
>
> ------------------------------------------------------------------------------
> 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

[Rails-devel] Problem with 1835 PfB

[Schnell, V. <vol...@ar...>]

Hello,

here is another problem with the special ability of the Pfalzbahn in 1835.
Bad is opened in the sdr and the By-director use the ability of the 
Pfalzbahn (tile laying (i.e. 210/L6/NE) and Token) before the BAD has 
layed the home-Token.
message: by cannot lay token on M6, base token slot.
see attached file. I play the game with the master-Branch.

The rules say, if a tile on L6 is already exist when the BAD is floated, 
the director decides, where to place the BAd-basetoken.

Can you fix the problem?

Volker

-- 
Volker Schnell
email: vol...@ar...
homepage: home.arcor.de\volker_schnell

Re: [Rails-devel] Problem with 1835 PfB

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

Volker,

It was a practical decision to postpone the Bad home-token laying until its first OR, but I agree that in this case it works out badly.  
I'll see if I can do something about it.

Erik


> -----Original Message-----
> From: Schnell, Volker [mailto:vol...@ar...]
> Sent: Monday, February 20, 2012 10:51 AM
> To: rai...@li...
> Subject: [Rails-devel] Problem with 1835 PfB
> 
> Hello,
> 
> here is another problem with the special ability of the Pfalzbahn in 1835.
> Bad is opened in the sdr and the By-director use the ability of the Pfalzbahn
> (tile laying (i.e. 210/L6/NE) and Token) before the BAD has layed the home-
> Token.
> message: by cannot lay token on M6, base token slot.
> see attached file. I play the game with the master-Branch.
> 
> The rules say, if a tile on L6 is already exist when the BAD is floated, the
> director decides, where to place the BAd-basetoken.
> 
> Can you fix the problem?
> 
> Volker
> 
> --
> Volker Schnell
> email: vol...@ar...
> homepage: home.arcor.de\volker_schnell

Re: [Rails-devel] Problem with 1835 PfB

[<Dr....@t-...>]

Hi Erik, 

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

	2. the method to move a token on a hex after that token has been laid
is not yet implemented i am afraid. 

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

	Thats for a quick analysis... 

	If i got some less work and more sleep, but you'll probably be faster
:) 

	Regards, 

	Martin  

	  Von: "Erik Vos" <eri...@xs...>
 An: <vol...@ar...>, "'Development list for Rails: an 18xx
game'" <rai...@li...>
 Betreff: Re: [Rails-devel] Problem with 1835 PfB
 Datum: Mon, 20 Feb 2012 12:16:10 +0100

 Volker,

 It was a practical decision to postpone the Bad home-token laying
until its first OR, but I agree that in this case it works out badly. 

 I'll see if I can do something about it.

 Erik

 > -----Original Message-----
 > From: Schnell, Volker [mailto:vol...@ar...]
 > Sent: Monday, February 20, 2012 10:51 AM
 > To: rai...@li...
 > Subject: [Rails-devel] Problem with 1835 PfB
 > 
 > Hello,
 > 
 > here is another problem with the special ability of the Pfalzbahn
in 1835.
 > Bad is opened in the sdr and the By-director use the ability of the
Pfalzbahn
 > (tile laying (i.e. 210/L6/NE) and Token) before the BAD has layed
the home-
 > Token.
 > message: by cannot lay token on M6, base token slot.
 > see attached file. I play the game with the master-Branch.
 > 
 > The rules say, if a tile on L6 is already exist when the BAD is
floated, the
 > director decides, where to place the BAd-basetoken.
 > 
 > Can you fix the problem?
 > 
 > Volker
 > 
 > --
 > Volker Schnell
 > email: vol...@ar...
 > homepage: home.arcor.devolker_schnell

 ------------------------------------------------------------------------------
 Try before you buy = See our experts in action!
 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-dev2
 _______________________________________________
 Rails-devel mailing list
 Rai...@li...
 https://lists.sourceforge.net/lists/listinfo/rails-devel

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.

Re: [Rails-devel] Problem with 1835 PfB

[<Dr....@t-...>]

Hi Erik, 

	in the approach that the owner of the Pfalzbahnen might use the power
and place a tile on L6 AND place his token and the BAD has not started
yet, the game is handling this wrong as it disallows all actions. 

	Sure most of the time if the first 3 train is bought (thus green
tiles make L6 available) BAD is operational, but it acts after 2 major
companies. 

	And those companies should be able to lay a token if they wish for
their company, cause they might want to got to Elsass Lothringen at
least once :).  This is prohibited by the current mechanic. 

	What should solve the problem would be a Correction Mode for Tokens ?
(or a routine to alter a laid token by special or rightfull power i.e.
the intervening BAd Director Token Turn/Move). 

	Regards, 

	Martin  

	  Von: "Erik Vos" <eri...@xs...>
 An: <Dr....@t-...>, "'Development list for Rails: an
18xx game'" <rai...@li...>
 Betreff: Re: [Rails-devel] Problem with 1835 PfB
 Datum: Tue, 21 Feb 2012 14:33:15 +0100

 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

Re: [Rails-devel] Problem with 1835 PfB

[Schnell, V. <vol...@ar...>]

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

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

Re: [Rails-devel] Problem with 1835 PfB

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

OK, the fix is to always address the president of the company of which the
token must be laid in the token placement prompt.
This is a one-liner, but it breaks the architecture, as the UI (client) is
not supposed to have direct access to the identity of a company president
(which is a server state variable).
So this still is a provisional fix.

Anyway, the effect on this game will be that the prompt becomes the BY
president will now get the prompt "<BA-president>, select a station on hex
L6 for the BA home base token".

BTW all test cases now fail because the first "GameIs" report line has
disappeared from the test report.  But this line still appears in the report
window. 
Something must have changed in the game initialization process.

Erik.

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Tuesday, February 21, 2012 6:50 PM
> To: vol...@ar...; 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Problem with 1835 PfB
> 
> 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
> 
> 
>
----------------------------------------------------------------------------
--
> 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

Re: [Rails-devel] Problem with 1835 PfB

[Schnell, V. <vol...@ar...>]

hi Erik,

sorry, but the change doesn't work, see attached file.
There is no question, to lay the Bad-Token.

Volker

Am 21.02.2012 23:42, schrieb Erik Vos:
> OK, the fix is to always address the president of the company of which the
> token must be laid in the token placement prompt.
> This is a one-liner, but it breaks the architecture, as the UI (client) is
> not supposed to have direct access to the identity of a company president
> (which is a server state variable).
> So this still is a provisional fix.
>
> Anyway, the effect on this game will be that the prompt becomes the BY
> president will now get the prompt "<BA-president>, select a station on hex
> L6 for the BA home base token".
>
> BTW all test cases now fail because the first "GameIs" report line has
> disappeared from the test report.  But this line still appears in the report
> window.
> Something must have changed in the game initialization process.
>
> Erik.
>
>> -----Original Message-----
>> From: Erik Vos [mailto:eri...@xs...]
>> Sent: Tuesday, February 21, 2012 6:50 PM
>> To: vol...@ar...; 'Development list for Rails: an 18xx game'
>> Subject: Re: [Rails-devel] Problem with 1835 PfB
>>
>> 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
>>
>>
> ----------------------------------------------------------------------------
> --
>> 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
>
> ------------------------------------------------------------------------------
> 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

Re: [Rails-devel] Problem with 1835 PfB

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

Volker,

The question is asked when the green tile is laid on L6.  That's what the
rule says that you sent me, and that's how it works now.
You have to Undo twice to get there.

Erik.

> -----Original Message-----
> From: Schnell, Volker [mailto:vol...@ar...]
> Sent: Wednesday, February 22, 2012 9:49 AM
> To: rai...@li...
> Subject: Re: [Rails-devel] Problem with 1835 PfB
> 
> hi Erik,
> 
> sorry, but the change doesn't work, see attached file.
> There is no question, to lay the Bad-Token.
> 
> Volker
> 
> Am 21.02.2012 23:42, schrieb Erik Vos:
> > OK, the fix is to always address the president of the company of which
> > the token must be laid in the token placement prompt.
> > This is a one-liner, but it breaks the architecture, as the UI
> > (client) is not supposed to have direct access to the identity of a
> > company president (which is a server state variable).
> > So this still is a provisional fix.
> >
> > Anyway, the effect on this game will be that the prompt becomes the BY
> > president will now get the prompt "<BA-president>, select a station on
> > hex
> > L6 for the BA home base token".
> >
> > BTW all test cases now fail because the first "GameIs" report line has
> > disappeared from the test report.  But this line still appears in the
> > report window.
> > Something must have changed in the game initialization process.
> >
> > Erik.
> >
> >> -----Original Message-----
> >> From: Erik Vos [mailto:eri...@xs...]
> >> Sent: Tuesday, February 21, 2012 6:50 PM
> >> To: vol...@ar...; 'Development list for Rails: an 18xx game'
> >> Subject: Re: [Rails-devel] Problem with 1835 PfB
> >>
> >> 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
> >>
> >>
> > ----------------------------------------------------------------------
> > ------
> > --
> >> 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
> >
> > ----------------------------------------------------------------------
> > -------- 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

[Rails-devel] Problem with game init (was: Problem with 1835 PfB)

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

Erik & Frederick:
in fact all but the first run fail, a clear indication that running 
several games in sequence is the issue:

The GameIs message is produced in line 91 of rails.game.Game:
ReportBuffer.add(LocalText.getText("GameIs", name));

The message is written to the current gameManager's reportBuffer. This 
reportBuffer is that of the previous gameManager instead of the new one.

To 99% this must have been something to do with Frederick's change of 
the NDC mechanism.
As I do not know what has been changed, it might be easier for Frederick 
to track that bug.

Stefan



> BTW all test cases now fail because the first "GameIs" report line has
> disappeared from the test report.  But this line still appears in the report
> window.
> Something must have changed in the game initialization process.
>
> Erik.

Re: [Rails-devel] Problem with game init (was: Problem with 1835 PfB)

[Frederick W. <fre...@go...>]

Stefan:
> To 99% this must have been something to do with Frederick's change of
> the NDC mechanism.

Having taken a look at the online git repos, I confirm this. But since
I do not have access to my local git clone for the next days, please
feel free to push a fix to this according to the following analysis:

(1) Game's add to the report buffer is called in Game's constructor
but the new GameManager instance is only created in Game's setup
method (called later).

(2) ReportBuffer retrieves the game manager instance (yielding the old
one). Before the NDC change, it was returned null and would buffer the
added message.

Two options to fix this:

(1) Postpone the ReportBuffer add to Game's setup (after the new game
manager is initialized). But from static analysis, it's unclear
whether follow-up issues would arise.

(2) Clear game manager singleton instance in game's constructor (would
require an additional method to GameManager calling
"gameManagerMap.put(GM_KEY, null);")

-- Frederick

Re: [Rails-devel] Problem with game init (was: Problem with 1835 PfB)

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

Thanks for your analysis. I have followed your first suggestion and pushed a
fix.

Erik.

> -----Original Message-----
> From: Frederick Weld [mailto:fre...@go...]
> Sent: Thursday, February 23, 2012 7:49 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Problem with game init (was: Problem with 1835
> PfB)
> 
> Stefan:
> > To 99% this must have been something to do with Frederick's change of
> > the NDC mechanism.
> 
> Having taken a look at the online git repos, I confirm this. But since I
do not
> have access to my local git clone for the next days, please feel free to
push a
> fix to this according to the following analysis:
> 
> (1) Game's add to the report buffer is called in Game's constructor but
the
> new GameManager instance is only created in Game's setup method (called
> later).
> 
> (2) ReportBuffer retrieves the game manager instance (yielding the old
one).
> Before the NDC change, it was returned null and would buffer the added
> message.
> 
> Two options to fix this:
> 
> (1) Postpone the ReportBuffer add to Game's setup (after the new game
> manager is initialized). But from static analysis, it's unclear whether
follow-up
> issues would arise.
> 
> (2) Clear game manager singleton instance in game's constructor (would
> require an additional method to GameManager calling
> "gameManagerMap.put(GM_KEY, null);")
> 
> -- Frederick
> 
>
----------------------------------------------------------------------------
--
> Virtualization & Cloud Management Using Capacity Planning Cloud computing
> makes use of virtualization - but cloud computing also focuses on allowing
> computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Bug in 1.7.3 1835, Token of a starting company

[Schnell, V. <vol...@ar...>]

Hi

I found another Bug in 1835. Rails-Version 1.7.3
in the SDR 2 Shares of the Bayern were sold (92 > 88). In the same round 
but later the Sax was founded (50% sold shares).
in the following OR Sax operates before the Bayern. see attached saved-file
Thats wrong.

from the Rules (first german, then english)
2.7.1 Sind von einer Gesellschaft mindestens 50% erstmalig verkauft 
worden, ist die Gesellschaft "in Betrieb".
2.7.2 In dem Moment, in dem die Gesellschaft in Betrieb geht, erhält der 
Direktor den entsprechenden Besitzbogen und alle Marker der Gesellschaft.
2.7.3 Einer der Marker wird auf das gekennzeichnete Startposition der AG 
auf der Aktienkurstafel gelegt. Ist das Feld schon von anderen Markern 
belegt, wird er unter diese geschoben.

english.
2.7.1. if 50% Shares of a company are sold for the first time, the 
company "operates"
2.7.2. at the Time, the company operates, the director receives the 
compony sheet and all company-token.
2.7.3. One marker is layed at the marked Position of the company on the 
stock-table. If the field is already occupied by other token, then the 
token is placed under the other token.

greetings

volker

-- 
Volker Schnell
email: vol...@ar...
homepage: home.arcor.de\volker_schnell

Re: [Rails-devel] Bug in 1.7.3 1835, Token of a starting company

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

The save file you attached is from an 18EU game.

On 2012-05-05 14:09, Schnell, Volker wrote:
> Hi
> 
> I found another Bug in 1835. Rails-Version 1.7.3
> in the SDR 2 Shares of the Bayern were sold (92 > 88). In the same round but later the Sax was founded (50% sold shares).
> in the following OR Sax operates before the Bayern. see attached saved-file
> Thats wrong.
> 
> from the Rules (first german, then english)
> 2.7.1 Sind von einer Gesellschaft mindestens 50% erstmalig verkauft worden, ist die Gesellschaft "in Betrieb".
> 2.7.2 In dem Moment, in dem die Gesellschaft in Betrieb geht, erhält der Direktor den entsprechenden Besitzbogen und alle Marker der Gesellschaft.
> 2.7.3 Einer der Marker wird auf das gekennzeichnete Startposition der AG auf der Aktienkurstafel gelegt. Ist das Feld schon von anderen Markern belegt, wird er unter diese geschoben.
> 
> english.
> 2.7.1. if 50% Shares of a company are sold for the first time, the company "operates"
> 2.7.2. at the Time, the company operates, the director receives the compony sheet and all company-token.
> 2.7.3. One marker is layed at the marked Position of the company on the stock-table. If the field is already occupied by other token, then the token is placed under the other token.
> 
> greetings
> 
> volker

If it happened in the first OR, I would agree that that is a bug.
I've seen Sx correctly operate before By (once) if Sx floats in SR2.

Re: [Rails-devel] Bug in 1.7.3 1835, Token of a starting company

[Schnell, V. <vol...@ar...>]

David, thanks for the hint.
here is the right one.


Am 06.05.2012 02:46, schrieb John David Galt:
> The save file you attached is from an 18EU game.
>
> On 2012-05-05 14:09, Schnell, Volker wrote:
>> Hi
>>
>> I found another Bug in 1835. Rails-Version 1.7.3
>> in the SDR 2 Shares of the Bayern were sold (92>  88). In the same round but later the Sax was founded (50% sold shares).
>> in the following OR Sax operates before the Bayern. see attached saved-file
>> Thats wrong.
>>
>> from the Rules (first german, then english)
>> 2.7.1 Sind von einer Gesellschaft mindestens 50% erstmalig verkauft worden, ist die Gesellschaft "in Betrieb".
>> 2.7.2 In dem Moment, in dem die Gesellschaft in Betrieb geht, erhält der Direktor den entsprechenden Besitzbogen und alle Marker der Gesellschaft.
>> 2.7.3 Einer der Marker wird auf das gekennzeichnete Startposition der AG auf der Aktienkurstafel gelegt. Ist das Feld schon von anderen Markern belegt, wird er unter diese geschoben.
>>
>> english.
>> 2.7.1. if 50% Shares of a company are sold for the first time, the company "operates"
>> 2.7.2. at the Time, the company operates, the director receives the compony sheet and all company-token.
>> 2.7.3. One marker is layed at the marked Position of the company on the stock-table. If the field is already occupied by other token, then the token is placed under the other token.
>>
>> greetings
>>
>> volker
> If it happened in the first OR, I would agree that that is a bug.
> I've seen Sx correctly operate before By (once) if Sx floats in SR2.

-- 
Volker Schnell
email: vol...@ar...
homepage: home.arcor.de\volker_schnell

Re: [Rails-devel] Bug in 1.7.3 1835, Token of a starting company

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

Volker:
thanks for catching this.

I have to admit that I did not know that rule by heart myself, I would 
have guessed that the (stock market) token is layed as soon as the 
president's share is available.
(So in effect BY and SX price markets are on the stock chart from the 
start of the game).

Rails currently lays the token as soon as the president's share is 
bought (so similar what I believe is correct for most 18xx), which given 
the rules quoted is wrong.

It seems that is not excessively hard to change that, but I want to wait 
for Erik's opinion on this.

I will delay the 1.7.4 release until this is fixed.

Stefan

PS: Volker do you know if Lemmi's moderator handles this correctly?

And another PS: Does anybody now when in general is the stock market 
token placed for other 18xx with par prices? I do not have time to
check that now, but I had guessed that it usually happens at the same 
time that the par price is set (so after the president shares is bought).


On 05/06/2012 11:07 AM, Schnell, Volker wrote:
> David, thanks for the hint.
> here is the right one.
>
>
> Am 06.05.2012 02:46, schrieb John David Galt:
>> The save file you attached is from an 18EU game.
>>
>> On 2012-05-05 14:09, Schnell, Volker wrote:
>>> Hi
>>>
>>> I found another Bug in 1835. Rails-Version 1.7.3
>>> in the SDR 2 Shares of the Bayern were sold (92> 88). In the same
>>> round but later the Sax was founded (50% sold shares).
>>> in the following OR Sax operates before the Bayern. see attached
>>> saved-file
>>> Thats wrong.
>>>
>>> from the Rules (first german, then english)
>>> 2.7.1 Sind von einer Gesellschaft mindestens 50% erstmalig verkauft
>>> worden, ist die Gesellschaft "in Betrieb".
>>> 2.7.2 In dem Moment, in dem die Gesellschaft in Betrieb geht, erhält
>>> der Direktor den entsprechenden Besitzbogen und alle Marker der
>>> Gesellschaft.
>>> 2.7.3 Einer der Marker wird auf das gekennzeichnete Startposition der
>>> AG auf der Aktienkurstafel gelegt. Ist das Feld schon von anderen
>>> Markern belegt, wird er unter diese geschoben.
>>>
>>> english.
>>> 2.7.1. if 50% Shares of a company are sold for the first time, the
>>> company "operates"
>>> 2.7.2. at the Time, the company operates, the director receives the
>>> compony sheet and all company-token.
>>> 2.7.3. One marker is layed at the marked Position of the company on
>>> the stock-table. If the field is already occupied by other token,
>>> then the token is placed under the other token.
>>>
>>> greetings
>>>
>>> volker
>> If it happened in the first OR, I would agree that that is a bug.
>> I've seen Sx correctly operate before By (once) if Sx floats in SR2.
>
>
>
> ------------------------------------------------------------------------------
> 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] Bug in 1.7.3 1835, Token of a starting company

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

> Volker Schnell wrote:
>> from the Rules (first german, then english)
>> 2.7.1 Sind von einer Gesellschaft mindestens 50% erstmalig verkauft worden, ist >> die Gesellschaft "in Betrieb".
>> 2.7.2 In dem Moment, in dem die Gesellschaft in Betrieb geht, erhält der
>> Direktor den entsprechenden Besitzbogen und alle Marker der Gesellschaft.
>> 2.7.3 Einer der Marker wird auf das gekennzeichnete Startposition der AG auf
>> der Aktienkurstafel gelegt. Ist das Feld schon von anderen Markern belegt, wird
>> er unter diese geschoben.
>>
>> english. [fixed spelling - JDG]
>> 2.7.1. If 50% Shares of a company are sold for the first time, the company
>> "operates"
>> 2.7.2. At the time the company operates, the director receives the company
>> sheet and all company-tokens.
>> 2.7.3. One marker is laid at the marked Position of the company on the stock-
>> table.  If the field is already occupied by other tokens, then the token is
>> placed under the other tokens.

Placing a company's stock market token only when it operates seems wrong,
because normally the positions of the stock market tokens determine the order
in which all the major companies will operate.

Am I right in thinking this means that a company's home station also is laid
when it first operates, and not when it floats?  This would be exactly opposite
to both English versions of the rules (especially the first edition).  In those,
a company's home station is placed on the map during the stock round as soon as
50% is purchased.  (The second edition made BA an exception.)  This will make a
big difference in play -- especially in the case of HE, which often blocks other
companies as soon as it is placed.

I suggest that this behavior be made a setup option, because nobody I know is
going to want to change to your version.

Stefan Frey wrote:
> And another PS: Does anybody now when in general is the stock market 
> token placed for other 18xx with par prices? I do not have time to
> check that now, but I had guessed that it usually happens at the same 
> time that the par price is set (so after the president shares is bought).

That's correct for 1830 and most games with a similar market, because you can
sell shares to the bank pool right away, even if the company hasn't floated
yet.

Re: [Rails-devel] Bug in 1.7.3 1835, Token of a starting company

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

I don't know what you are talking about when you refer to "his version",
Volker was quoting the official, actual, rules. You also seem to be
confusing "only placing a token on the stock market when the company
operates" with "placing a token on the stock market when the company first
operates" - the first is a misinterpretation, the second is correct for
1830.

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): 120506-1, 07/05/2012
Tested on: 7/05/2012 5:46:08 AM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [Rails-devel] Bug in 1.7.3 1835, Token of a starting company

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

On 2012-05-06 12:46, Mike Bourke wrote:
> I don't know what you are talking about when you refer to "his version",

Changing to lay the token on the stock market when the company first operates
instead of during the stock round when it forms (which he has now clarified is
really what he meant).

> Volker was quoting the official, actual, rules. You also seem to be
> confusing "only placing a token on the stock market when the company
> operates" with "placing a token on the stock market when the company first
> operates" - the first is a misinterpretation, the second is correct for
> 1830.

Never has been, never will be.  In all games (except maybe 1835) the stock
market token goes down during a stock round, either when the president's share
is purchased (which is how it works in 1830) or when the company floats.

Re: [Rails-devel] Bug in 1.7.3 1835, Token of a starting company

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

I had not yet received Stefan's earlier reaction when I gave mine, and mine
seems to have been overlooked since.

The quick and simple rule that I had inferred from looking into some rule
sets is, that if a company has a *fixed* starting price, the stock price
token is laid when the company floats.  This at least applies to 1825, 1835,
and indeed 1837 (thanks John).  My question was if that rule holds for all
such games; so far is does.

The discussion now seems to have digressed to the question what happens with
companies that do not have a fixed starting price, but that have both a par
and a market price.
But that was not the issue at stake here, so I'll ignore that issue.

My proposal was and is:

> a) add a provision to show fixed start prices on the Stock Chart, to be
shown only
> if a company hasn't yet floated,

(i.e. not in the form of a token, but just plain text)

> b) for fixed start price companies, postpone stock chart token laying
until
> floating time.
> 
> If exceptions exist, we'll also need a new game parameter to define the
> correct rule for each such game.

No exceptions seen so far.

Erik

> -----Original Message-----
> From: Mike Bourke [mailto:com...@ip...]
> Sent: Sunday, May 06, 2012 9:46 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Bug in 1.7.3 1835, Token of a starting company
> 
> I don't know what you are talking about when you refer to "his version",
> Volker was quoting the official, actual, rules. You also seem to be
confusing
> "only placing a token on the stock market when the company operates" with
> "placing a token on the stock market when the company first operates" -
the
> first is a misinterpretation, the second is correct for 1830.
> 
> 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): 120506-1, 07/05/2012 Tested on: 7/05/2012 5:46:08 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] Bug in 1.7.3 1835, Token of a starting company

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

On further checking I see, that in 1837 only the three merger companies have
a fixed starting price. 

For the other companies, the start price can be chosen, but still is not to
be indicated on the stock chart until floating time - which seems awkward to
me: apparently you'll have to remember the price until that time.  Or lay
the price token upside down initially.

Anyway, a Rails implementation of 1837 is not really on the horizon, and
when it gets there, the stock chart will be special in many more respects.

Erik.

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Sunday, May 06, 2012 10:18 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Bug in 1.7.3 1835, Token of a starting company
> 
> I had not yet received Stefan's earlier reaction when I gave mine, and
mine
> seems to have been overlooked since.
> 
> The quick and simple rule that I had inferred from looking into some rule
sets
> is, that if a company has a *fixed* starting price, the stock price token
is laid
> when the company floats.  This at least applies to 1825, 1835, and indeed
> 1837 (thanks John).  My question was if that rule holds for all such
games; so
> far is does.
> 
> The discussion now seems to have digressed to the question what happens
> with companies that do not have a fixed starting price, but that have both
a
> par and a market price.
> But that was not the issue at stake here, so I'll ignore that issue.
> 
> My proposal was and is:
> 
> > a) add a provision to show fixed start prices on the Stock Chart, to
> > be
> shown only
> > if a company hasn't yet floated,
> 
> (i.e. not in the form of a token, but just plain text)
> 
> > b) for fixed start price companies, postpone stock chart token laying
> until
> > floating time.
> >
> > If exceptions exist, we'll also need a new game parameter to define
> > the correct rule for each such game.
> 
> No exceptions seen so far.
> 
> Erik
> 
> > -----Original Message-----
> > From: Mike Bourke [mailto:com...@ip...]
> > Sent: Sunday, May 06, 2012 9:46 PM
> > To: 'Development list for Rails: an 18xx game'
> > Subject: Re: [Rails-devel] Bug in 1.7.3 1835, Token of a starting
> > company
> >
> > I don't know what you are talking about when you refer to "his
> > version", Volker was quoting the official, actual, rules. You also
> > seem to be
> confusing
> > "only placing a token on the stock market when the company operates"
> > with "placing a token on the stock market when the company first
> > operates" -
> the
> > first is a misinterpretation, the second is correct for 1830.
> >
> > 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): 120506-1, 07/05/2012 Tested on: 7/05/2012
> > 5:46:08 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
> 
> 
>
----------------------------------------------------------------------------
--
> 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