rails-devel — List for discussion of Rails development

Re: [Rails-devel] Finally getting around to starting that PBEM game

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

1.0.6 is the latest release, unless you want to check the code
directly out of CVS. :-)

---Brett.
A. P. Herbert  - "A high-brow is someone who looks at a sausage and
thinks of Picasso." -
http://www.brainyquote.com/quotes/authors/a/a_p_herbert.html


On Sat, Jul 4, 2009 at 11:23 AM, Chris Shaffer<chr...@gm...> wrote:
> I'm (finally) about to start a game of 1830 PBEM as a beta test of the Rails
> software (and also to learn 1830 strategies).  Should we use the 1.0.6
> release from last December, or is there a newer version that you would
> prefer us to use for beta testing?
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

[Rails-devel] Finally getting around to starting that PBEM game

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

I'm (finally) about to start a game of 1830 PBEM as a beta test of the Rails
software (and also to learn 1830 strategies).  Should we use the 1.0.6
release from last December, or is there a newer version that you would
prefer us to use for beta testing?

--
Chris

Please consider the environment before printing this e-mail.

[Rails-devel] 1856 CGR start price

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

I have added code to calculate the correct CGR start price.
Testing was limited, as I still only have one test case...

Erik

[Rails-devel] 1856 CGR Formation

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

I have just committed a lot of code dealing with the 1856 CGR Formation. The
only aspect not covered is the CGR start price, which is currently fixed at
$100. I will do that later; it seemed to me that it was about time to set a
milestone.

In fact I had already completed all of this early March, but I wasn't
satisfied with one aspect: the fact that during one round (CGR formation is
handled by a specialised Round subclass) either the StatusWindow (with stock
chart) or the ORWindow (with map) could be shown, depending on whether the
CGRFormationRound would be a subclass of either StockRound or
OperatingRound. 

The CGR formation runs almost automatically, except for three processes
where player interaction msy be required:
1. Optional loan repayments from the president's personal cash. It does not
matter much which window is shown during this action, but as the share
exchange follows, it is preferable to have the StatusWindow visible during
this step.
2. CGR token placement on non-home cities of any of the merged companies, if
the CGR runs out of tokens. Here it is very much preferrable to have the
ORWindow visible.
3. Discarding CGR excess permanent trains (unlikely but possible). Here
again it doesn't really matter.

After a lot of toying around, I concluded that the visible window type
should be decoupled from the back-end round type. GameUIManager will now not
only ask for the active Round subclass, but also for a 'hint' that it can
use to select the UI window to be shown. All existing StockRound and
OperatingRound (sub)classes still only hint their own type, but there is now
a fourth type, which I (lacking fantasy) have called SwitchableUIRound, and
CGRFormationRound is the first class of this type. SwitchableUIRound can
call, and CGRFormationRound actually calls for different UI windows to be
displayed in different steps.

Another thing that has changed is the way the whole program is started. At
one point I concluded, that I needed to subclass GameUIManager. This was not
possible, as this class was instantiated before the configuration was read.
To enable subclassing, I have reversed the startup sequence of Game and
GameUIManager: the former now starts the latter, in stead of the other way
around. (After all I didn't need this GameUIManager subclass, but I'll leave
the startup sequence like this in case we need it in the future.)

There is a lot more to do about 1856, but I think (hope) this was the
biggest hurdle....

Erik Vos

[Rails-devel] 1856 final loan repayment

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

I have committed code to implement the phase 1 of the CGR formation round:
repaying all loans.
For each company having loans, first the company cash is depleted,
then the president gets a change to contribute personal cash.
The displayed message will mention whether or not the president's actions
may ultimately save each company.

So far that's all; the CGR is not yet formed, and the current OR will
continue with the same old companies.
The CGR formation will be phase 2.

Erik Vos

Re: [Rails-devel] 1856 CGR formation

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

Jonathan Ferro wrote:
> I like all these answers, so I only have one additional question:
> 
> If the company has 3 loans and $90, is it allowed for the player to
> add only $10 to pay off only one loan, so that the company will fold
> into the CGR and yet contribute no cash?  I suppose I could go parse
> this out of the rulebook, but might as well cover all the cases in
> open discussion...

Yes, that's allowed.  I've never seen it done.

Re: [Rails-devel] 1856 CGR formation

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

But... if it is legal, and there *possibly* might be a good reason for it, I
might have to give players that option.
Although I'd prefer not to do so. 
Spending $10 to deny CGR $90 of starting cash might in theory in be useful
if you're low on CGR shares. Not so in reality?

Erik.

-----Original Message-----
From: brett lentz [mailto:wak...@gm...] 
Sent: Saturday 24 January 2009 08:04
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856 CGR formation

It's legal, but why would you bother?   If it's going to fold into the
CGR anyway, why throw away your personal cash? As far as I can tell,
all you're doing is voluntarily making it easier for your opponents to
win.

There might be some obscure, situational reason why you might do this,
but in general, there's no reason to do so.

---Brett.

On Fri, Jan 23, 2009 at 5:43 PM, Jonathan Ferro
<jon...@ya...> wrote:
> I like all these answers, so I only have one additional question:
>
> If the company has 3 loans and $90, is it allowed for the player to add
only $10 to pay off only one loan, so that the company will fold into the
CGR and yet contribute no cash?  I suppose I could go parse this out of the
rulebook, but might as well cover all the cases in open discussion...
>
> -- Jonathan
>
>
>
> ----- Original Message ----
> From: John David Galt <jd...@di...>
> To: rai...@li...
> Sent: Thursday, January 22, 2009 3:15:37 PM
> Subject: Re: [Rails-devel] 1856 CGR formation
>
> Erik Vos wrote:
>> Next thing for me to do is the final loan repayment/CGR formation
process.
> [snip]
>> "The loans are repaid in $100 increments. If outstanding loans remain
>> after the treasury is depleted, the player *may* repay the remainder,
>> supplementing the cash remaining in the tresury with personal cash"
>> (my emphasis).
>>
>> Questions:
>>
>> 1. I suppose that "may" means, that adding personal cash is optional.
>
> Right.
>
>> 2. The rules don't say, that paying only part from the remainder by the
>> president is not allowed, but that would clearly be a silly thing to do.
>> So I take it that adding personal cash is in practice a matter of
>> all-or-nothing, i.e. all I have to do asking a yes/no question to
>> the president (if he has enough cash):
>> "Are you going to pay all of the remainder?"
>
> Yes, but the decision is made separately for each railroad that still
> has loans after paying off as many as it can.  Often, a player will be
> president of three or four companies at this point in the game, and he
> has a completely free choice of which companies, if any, to bail out,
> up to the limits of his purse.
>
>> If the president doesn't have enough cash, no question need be asked at
all.
>
> Only if he hasn't the money to save any of his companies.
>
>> 3. I wonder what this sentence about $100 increments means.
>> Say that the company has $300 loans and $150 cash, and the president
>> pays all of the remainder, do company and president then pay $150 each,
>> or $100 and $200 (leaving $50 in the treasury)?
>
> The sentence about $100 increments means the company must automatically
> pay off loans until it has less than $100 left, or until it is debt free.
> So in your example, the company must pay one loan for $100 before its
> president even gets to make a choice.
>
> If the president does contribute any cash from his hand, the company's
> treasury must be used up first, just as it is during a forced train
> purchase.
>
>> 4. And if the president pays nothing, then $100 is repaid and $50 is left
>> to feed the CGR?
>
> Correct.
>
>> 5. "If the player is president of more than one company, the player
>> chooses the order in which those companies repay their loans" -
>> I would think that if payment from personal cash is optional,
>> this order is immaterial. Did I miss something?
>> (I'm asking this because it's a lot easier to have the game engine
>> determine the sequence, and as far as I can see it doesn't matter).
>
> Answered under #2 above.
>
>> On the implementation:
>>
>> I think the mentioned yes/no question is all player interaction
>> in this whole process (except for a few decisions that the new
>> CGR president may need to take regarding trains and tokens).
>> So, once the merging companies are known,
>> the whole repayment/CGR formation process will run
>> automatically in the background, reporting the actions in the
>> Game Report window and I think also in a popup message.
>> The Game Status window will be properly updated.
>>
>> Right?
>
> Mostly yes.  But you need to go around the table asking the question
> in the proper order (clockwise, beginning with the player who bought
> the 6 train), and let each player see the money and holdings of all
> players and the bank pool (and any decisions that were made before
> his) before he makes his decision.
>
> There are exactly enough CGR shares to exchange for 40 shares, so if
> 4 or fewer companies merge in, all shareholders will get to exchange
> their shares 2-for-1 (except for the odd share when the total number
> of merging-company shares held by a player is odd).
>
> But if more than 4 companies merge, some shares will be lost.  Thus
> the player in position to merge a 5th (or later) company may or may
> not want to do it, depending on what shares are held by him and by
> the players who merged their companies first.  Conversely, a player
> in an early position may want to merge more companies than he needs
> to control the CGR, in order to deprive the other players.
>
>
>
----------------------------------------------------------------------------
--
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
----------------------------------------------------------------------------
--
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

----------------------------------------------------------------------------
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856 CGR formation

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

It's legal, but why would you bother?   If it's going to fold into the
CGR anyway, why throw away your personal cash? As far as I can tell,
all you're doing is voluntarily making it easier for your opponents to
win.

There might be some obscure, situational reason why you might do this,
but in general, there's no reason to do so.

---Brett.

On Fri, Jan 23, 2009 at 5:43 PM, Jonathan Ferro
<jon...@ya...> wrote:
> I like all these answers, so I only have one additional question:
>
> If the company has 3 loans and $90, is it allowed for the player to add only $10 to pay off only one loan, so that the company will fold into the CGR and yet contribute no cash?  I suppose I could go parse this out of the rulebook, but might as well cover all the cases in open discussion...
>
> -- Jonathan
>
>
>
> ----- Original Message ----
> From: John David Galt <jd...@di...>
> To: rai...@li...
> Sent: Thursday, January 22, 2009 3:15:37 PM
> Subject: Re: [Rails-devel] 1856 CGR formation
>
> Erik Vos wrote:
>> Next thing for me to do is the final loan repayment/CGR formation process.
> [snip]
>> "The loans are repaid in $100 increments. If outstanding loans remain
>> after the treasury is depleted, the player *may* repay the remainder,
>> supplementing the cash remaining in the tresury with personal cash"
>> (my emphasis).
>>
>> Questions:
>>
>> 1. I suppose that "may" means, that adding personal cash is optional.
>
> Right.
>
>> 2. The rules don't say, that paying only part from the remainder by the
>> president is not allowed, but that would clearly be a silly thing to do.
>> So I take it that adding personal cash is in practice a matter of
>> all-or-nothing, i.e. all I have to do asking a yes/no question to
>> the president (if he has enough cash):
>> "Are you going to pay all of the remainder?"
>
> Yes, but the decision is made separately for each railroad that still
> has loans after paying off as many as it can.  Often, a player will be
> president of three or four companies at this point in the game, and he
> has a completely free choice of which companies, if any, to bail out,
> up to the limits of his purse.
>
>> If the president doesn't have enough cash, no question need be asked at all.
>
> Only if he hasn't the money to save any of his companies.
>
>> 3. I wonder what this sentence about $100 increments means.
>> Say that the company has $300 loans and $150 cash, and the president
>> pays all of the remainder, do company and president then pay $150 each,
>> or $100 and $200 (leaving $50 in the treasury)?
>
> The sentence about $100 increments means the company must automatically
> pay off loans until it has less than $100 left, or until it is debt free.
> So in your example, the company must pay one loan for $100 before its
> president even gets to make a choice.
>
> If the president does contribute any cash from his hand, the company's
> treasury must be used up first, just as it is during a forced train
> purchase.
>
>> 4. And if the president pays nothing, then $100 is repaid and $50 is left
>> to feed the CGR?
>
> Correct.
>
>> 5. "If the player is president of more than one company, the player
>> chooses the order in which those companies repay their loans" -
>> I would think that if payment from personal cash is optional,
>> this order is immaterial. Did I miss something?
>> (I'm asking this because it's a lot easier to have the game engine
>> determine the sequence, and as far as I can see it doesn't matter).
>
> Answered under #2 above.
>
>> On the implementation:
>>
>> I think the mentioned yes/no question is all player interaction
>> in this whole process (except for a few decisions that the new
>> CGR president may need to take regarding trains and tokens).
>> So, once the merging companies are known,
>> the whole repayment/CGR formation process will run
>> automatically in the background, reporting the actions in the
>> Game Report window and I think also in a popup message.
>> The Game Status window will be properly updated.
>>
>> Right?
>
> Mostly yes.  But you need to go around the table asking the question
> in the proper order (clockwise, beginning with the player who bought
> the 6 train), and let each player see the money and holdings of all
> players and the bank pool (and any decisions that were made before
> his) before he makes his decision.
>
> There are exactly enough CGR shares to exchange for 40 shares, so if
> 4 or fewer companies merge in, all shareholders will get to exchange
> their shares 2-for-1 (except for the odd share when the total number
> of merging-company shares held by a player is odd).
>
> But if more than 4 companies merge, some shares will be lost.  Thus
> the player in position to merge a 5th (or later) company may or may
> not want to do it, depending on what shares are held by him and by
> the players who merged their companies first.  Conversely, a player
> in an early position may want to merge more companies than he needs
> to control the CGR, in order to deprive the other players.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1856 CGR formation

[Jonathan F. <jon...@ya...>]

I like all these answers, so I only have one additional question:

If the company has 3 loans and $90, is it allowed for the player to add only $10 to pay off only one loan, so that the company will fold into the CGR and yet contribute no cash?  I suppose I could go parse this out of the rulebook, but might as well cover all the cases in open discussion...

-- Jonathan



----- Original Message ----
From: John David Galt <jd...@di...>
To: rai...@li...
Sent: Thursday, January 22, 2009 3:15:37 PM
Subject: Re: [Rails-devel] 1856 CGR formation

Erik Vos wrote:
> Next thing for me to do is the final loan repayment/CGR formation process.
[snip]
> "The loans are repaid in $100 increments. If outstanding loans remain 
> after the treasury is depleted, the player *may* repay the remainder, 
> supplementing the cash remaining in the tresury with personal cash" 
> (my emphasis).
> 
> Questions:
> 
> 1. I suppose that "may" means, that adding personal cash is optional.

Right.

> 2. The rules don't say, that paying only part from the remainder by the 
> president is not allowed, but that would clearly be a silly thing to do. 
> So I take it that adding personal cash is in practice a matter of 
> all-or-nothing, i.e. all I have to do asking a yes/no question to 
> the president (if he has enough cash): 
> "Are you going to pay all of the remainder?"

Yes, but the decision is made separately for each railroad that still
has loans after paying off as many as it can.  Often, a player will be
president of three or four companies at this point in the game, and he
has a completely free choice of which companies, if any, to bail out,
up to the limits of his purse.

> If the president doesn't have enough cash, no question need be asked at all.

Only if he hasn't the money to save any of his companies.

> 3. I wonder what this sentence about $100 increments means.
> Say that the company has $300 loans and $150 cash, and the president
> pays all of the remainder, do company and president then pay $150 each,
> or $100 and $200 (leaving $50 in the treasury)?

The sentence about $100 increments means the company must automatically
pay off loans until it has less than $100 left, or until it is debt free.
So in your example, the company must pay one loan for $100 before its
president even gets to make a choice.

If the president does contribute any cash from his hand, the company's
treasury must be used up first, just as it is during a forced train
purchase.

> 4. And if the president pays nothing, then $100 is repaid and $50 is left 
> to feed the CGR?

Correct.

> 5. "If the player is president of more than one company, the player
> chooses the order in which those companies repay their loans" - 
> I would think that if payment from personal cash is optional, 
> this order is immaterial. Did I miss something?
> (I'm asking this because it's a lot easier to have the game engine 
> determine the sequence, and as far as I can see it doesn't matter).

Answered under #2 above.

> On the implementation:
> 
> I think the mentioned yes/no question is all player interaction 
> in this whole process (except for a few decisions that the new 
> CGR president may need to take regarding trains and tokens). 
> So, once the merging companies are known, 
> the whole repayment/CGR formation process will run 
> automatically in the background, reporting the actions in the 
> Game Report window and I think also in a popup message. 
> The Game Status window will be properly updated.
> 
> Right?

Mostly yes.  But you need to go around the table asking the question
in the proper order (clockwise, beginning with the player who bought
the 6 train), and let each player see the money and holdings of all
players and the bank pool (and any decisions that were made before
his) before he makes his decision.

There are exactly enough CGR shares to exchange for 40 shares, so if
4 or fewer companies merge in, all shareholders will get to exchange
their shares 2-for-1 (except for the odd share when the total number
of merging-company shares held by a player is odd).

But if more than 4 companies merge, some shares will be lost.  Thus
the player in position to merge a 5th (or later) company may or may
not want to do it, depending on what shares are held by him and by
the players who merged their companies first.  Conversely, a player
in an early position may want to merge more companies than he needs
to control the CGR, in order to deprive the other players.


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856 CGR formation

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

Thanks, that is clear enough.
Erik. 

-----Original Message-----
From: John David Galt [mailto:jd...@di...] 
Sent: Friday 23 January 2009 00:16
To: rai...@li...
Subject: Re: [Rails-devel] 1856 CGR formation

Erik Vos wrote:
> Next thing for me to do is the final loan repayment/CGR formation process.
[snip]
> "The loans are repaid in $100 increments. If outstanding loans remain 
> after the treasury is depleted, the player *may* repay the remainder, 
> supplementing the cash remaining in the tresury with personal cash" 
> (my emphasis).
> 
> Questions:
> 
> 1. I suppose that "may" means, that adding personal cash is optional.

Right.

> 2. The rules don't say, that paying only part from the remainder by the 
> president is not allowed, but that would clearly be a silly thing to do. 
> So I take it that adding personal cash is in practice a matter of 
> all-or-nothing, i.e. all I have to do asking a yes/no question to 
> the president (if he has enough cash): 
> "Are you going to pay all of the remainder?"

Yes, but the decision is made separately for each railroad that still
has loans after paying off as many as it can.  Often, a player will be
president of three or four companies at this point in the game, and he
has a completely free choice of which companies, if any, to bail out,
up to the limits of his purse.

> If the president doesn't have enough cash, no question need be asked at
all.

Only if he hasn't the money to save any of his companies.

> 3. I wonder what this sentence about $100 increments means.
> Say that the company has $300 loans and $150 cash, and the president
> pays all of the remainder, do company and president then pay $150 each,
> or $100 and $200 (leaving $50 in the treasury)?

The sentence about $100 increments means the company must automatically
pay off loans until it has less than $100 left, or until it is debt free.
So in your example, the company must pay one loan for $100 before its
president even gets to make a choice.

If the president does contribute any cash from his hand, the company's
treasury must be used up first, just as it is during a forced train
purchase.

> 4. And if the president pays nothing, then $100 is repaid and $50 is left 
> to feed the CGR?

Correct.

> 5. "If the player is president of more than one company, the player
> chooses the order in which those companies repay their loans" - 
> I would think that if payment from personal cash is optional, 
> this order is immaterial. Did I miss something?
> (I'm asking this because it's a lot easier to have the game engine 
> determine the sequence, and as far as I can see it doesn't matter).

Answered under #2 above.

> On the implementation:
> 
> I think the mentioned yes/no question is all player interaction 
> in this whole process (except for a few decisions that the new 
> CGR president may need to take regarding trains and tokens). 
> So, once the merging companies are known, 
> the whole repayment/CGR formation process will run 
> automatically in the background, reporting the actions in the 
> Game Report window and I think also in a popup message. 
> The Game Status window will be properly updated.
> 
> Right?

Mostly yes.  But you need to go around the table asking the question
in the proper order (clockwise, beginning with the player who bought
the 6 train), and let each player see the money and holdings of all
players and the bank pool (and any decisions that were made before
his) before he makes his decision.

There are exactly enough CGR shares to exchange for 40 shares, so if
4 or fewer companies merge in, all shareholders will get to exchange
their shares 2-for-1 (except for the odd share when the total number
of merging-company shares held by a player is odd).

But if more than 4 companies merge, some shares will be lost.  Thus
the player in position to merge a 5th (or later) company may or may
not want to do it, depending on what shares are held by him and by
the players who merged their companies first.  Conversely, a player
in an early position may want to merge more companies than he needs
to control the CGR, in order to deprive the other players.


----------------------------------------------------------------------------
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856 CGR formation

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

Erik Vos wrote:
> Next thing for me to do is the final loan repayment/CGR formation process.
[snip]
> "The loans are repaid in $100 increments. If outstanding loans remain 
> after the treasury is depleted, the player *may* repay the remainder, 
> supplementing the cash remaining in the tresury with personal cash" 
> (my emphasis).
> 
> Questions:
> 
> 1. I suppose that "may" means, that adding personal cash is optional.

Right.

> 2. The rules don't say, that paying only part from the remainder by the 
> president is not allowed, but that would clearly be a silly thing to do. 
> So I take it that adding personal cash is in practice a matter of 
> all-or-nothing, i.e. all I have to do asking a yes/no question to 
> the president (if he has enough cash): 
> "Are you going to pay all of the remainder?"

Yes, but the decision is made separately for each railroad that still
has loans after paying off as many as it can.  Often, a player will be
president of three or four companies at this point in the game, and he
has a completely free choice of which companies, if any, to bail out,
up to the limits of his purse.

> If the president doesn't have enough cash, no question need be asked at all.

Only if he hasn't the money to save any of his companies.

> 3. I wonder what this sentence about $100 increments means.
> Say that the company has $300 loans and $150 cash, and the president
> pays all of the remainder, do company and president then pay $150 each,
> or $100 and $200 (leaving $50 in the treasury)?

The sentence about $100 increments means the company must automatically
pay off loans until it has less than $100 left, or until it is debt free.
So in your example, the company must pay one loan for $100 before its
president even gets to make a choice.

If the president does contribute any cash from his hand, the company's
treasury must be used up first, just as it is during a forced train
purchase.

> 4. And if the president pays nothing, then $100 is repaid and $50 is left 
> to feed the CGR?

Correct.

> 5. "If the player is president of more than one company, the player
> chooses the order in which those companies repay their loans" - 
> I would think that if payment from personal cash is optional, 
> this order is immaterial. Did I miss something?
> (I'm asking this because it's a lot easier to have the game engine 
> determine the sequence, and as far as I can see it doesn't matter).

Answered under #2 above.

> On the implementation:
> 
> I think the mentioned yes/no question is all player interaction 
> in this whole process (except for a few decisions that the new 
> CGR president may need to take regarding trains and tokens). 
> So, once the merging companies are known, 
> the whole repayment/CGR formation process will run 
> automatically in the background, reporting the actions in the 
> Game Report window and I think also in a popup message. 
> The Game Status window will be properly updated.
> 
> Right?

Mostly yes.  But you need to go around the table asking the question
in the proper order (clockwise, beginning with the player who bought
the 6 train), and let each player see the money and holdings of all
players and the bank pool (and any decisions that were made before
his) before he makes his decision.

There are exactly enough CGR shares to exchange for 40 shares, so if
4 or fewer companies merge in, all shareholders will get to exchange
their shares 2-for-1 (except for the odd share when the total number
of merging-company shares held by a player is odd).

But if more than 4 companies merge, some shares will be lost.  Thus
the player in position to merge a 5th (or later) company may or may
not want to do it, depending on what shares are held by him and by
the players who merged their companies first.  Conversely, a player
in an early position may want to merge more companies than he needs
to control the CGR, in order to deprive the other players.

[Rails-devel] 1856 CGR formation

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

Next thing for me to do is the final loan repayment/CGR formation process.

I have played 1856 only a few times, and seen the CGR form perhaps once,
so I would like to discuss some details here that aren't entirely clear to
me.
None of the clarifications I have seen is helpful on these matters.

"The loans are repaid in $100 increments. If outstanding loans remain 
after the treasury is depleted, the player *may* repay the remainder, 
supplementing the cash remaining in the tresury with personal cash" 
(my emphasis).

Questions:

1. I suppose that "may" means, that adding personal cash is optional.

2. The rules don't say, that paying only part from the remainder by the 
president is not allowed, but that would clearly be a silly thing to do. 
So I take it that adding personal cash is in practice a matter of 
all-or-nothing, i.e. all I have to do asking a yes/no question to 
the president (if he has enough cash): 
"Are you going to pay all of the remainder?"
If the president doesn't have enough cash, no question need be asked at all.

3. I wonder what this sentence about $100 increments means.
Say that the company has $300 loans and $150 cash, and the president
pays all of the remainder, do company and president then pay $150 each,
or $100 and $200 (leaving $50 in the treasury)?

4. And if the president pays nothing, then $100 is repaid and $50 is left 
to feed the CGR?

5. "If the player is president of more than one company, the player
chooses the order in which those companies repay their loans" - 
I would think that if payment from personal cash is optional, 
this order is immaterial. Did I miss something?
(I'm asking this because it's a lot easier to have the game engine 
determine the sequence, and as far as I can see it doesn't matter).

On the implementation:

I think the mentioned yes/no question is all player interaction 
in this whole process (except for a few decisions that the new 
CGR president may need to take regarding trains and tokens). 
So, once the merging companies are known, 
the whole repayment/CGR formation process will run 
automatically in the background, reporting the actions in the 
Game Report window and I think also in a popup message. 
The Game Status window will be properly updated.

Right?

Erik Vos

[Rails-devel] 1856 loan repayment

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

For 1856, I have implemented the loan repayment step at the end of OR turns.

This does not yet include the mandatory loan repayment after the first
6-train is bought.

Erik Vos

Re: [Rails-devel] 1956 loan interest payment

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

Mark,

	You have been busy I see. I have pulled down the updates last night,
and noticed about 100 warnings, 
	which I think today's updates will probably resolve. I was going to
mention it, but you may have them solved.

I had announced it myself after my previous batch of commits. It was a side
effect of the introduction of varargs.
Warnings do no harm, but I had some spare time without the energy to do more
useful things, so why not fix them all.

	I have been scratching my head over where the new icon under
/rails/ui/images directory really needs to live 
	in the archive (distribution directory on my mac) so that it can be
found. And still not sure. 
	When I do the compilation I get it to compile, and copy the icon in,
but it claims it cannot find the icon 
	-- probably because it is trying to find it via a full path
specification, rather than relative to the 
	java class files. All of the tiles images it finds, as well as the
xml data files. Do you search for that 
	icon file in a different way? 

It's in StartRoundWindow:
 
String path = "/rails/ui/images/Inform.gif";
java.net.URL imgURL = getClass().getResource(path);
if (imgURL != null) {
      return new ImageIcon(imgURL, "Info"); 
} 

I think I derived this code from Brett's GIF tile drawing code in
ImageLoader.
If you know a better way to do it, and/or a better way to store the icon,
please go ahead.
 
Erik.
 

Re: [Rails-devel] 1956 loan interest payment

[Mark S. <mar...@gm...>]

Erik,

You have been busy I see. I have pulled down the updates last night, and
noticed about 100 warnings, which I think today's updates will probably
resolve. I was going to mention it, but you may have them solved.

I have been scratching my head over where the new icon under
/rails/ui/images directory really needs to live in the archive (distribution
directory on my mac) so that it can be found. And still not sure. When I do
the compilation I get it to compile, and copy the icon in, but it claims it
cannot find the icon -- probably because it is trying to find it via a full
path specification, rather than relative to the java class files. All of the
tiles images it finds, as well as the xml data files. Do you search for that
icon file in a different way?

Mark

On Wed, Jan 14, 2009 at 3:56 PM, Erik Vos <eri...@hc...> wrote:

>
> I have added 1856 loan interest payment functionality.
>
> It wasn't easy to construct a case where all four possible money sources
> for
> such a payment would occur.
> Consider:
> LPS has $400 loans outstanding and must pay $40 interest.
> LPS has $10 in cash, earns $10 revenue (I make this up, of course),
> the LPS president (Alice) has $12 cash and must therefore raise another $8
> from share sales.
>
> The resulting game report lines are:
>
> LPS earns $10
> LPS must pay $40 loan interest
> Alice must sell shares to raise at least $8 for LPS
> Alice sells 1 10% shares (10%) of GT to Pool for $80.
> GT price goes from $80(E3) to $75(E4).
> LPS pays $10 (of $40) loan interest from its treasury
> LPS pays $10 (of $40) loan interest from its income
> LPS pays $20 (of $40) loan interest from Alice's personal cash
> LPS does not pay a dividend
> LPS price goes from $110(F1) to $100(E1).
>
> and the cash amounts change accordingly, so I think it's all working fine.
>
> Loan repayment remains to be done.
>
> Erik Vos
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] 1956 loan interest payment

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

I have added 1856 loan interest payment functionality.

It wasn't easy to construct a case where all four possible money sources for
such a payment would occur.
Consider:
LPS has $400 loans outstanding and must pay $40 interest.
LPS has $10 in cash, earns $10 revenue (I make this up, of course), 
the LPS president (Alice) has $12 cash and must therefore raise another $8
from share sales.

The resulting game report lines are:

LPS earns $10
LPS must pay $40 loan interest
Alice must sell shares to raise at least $8 for LPS
Alice sells 1 10% shares (10%) of GT to Pool for $80.
GT price goes from $80(E3) to $75(E4).
LPS pays $10 (of $40) loan interest from its treasury
LPS pays $10 (of $40) loan interest from its income
LPS pays $20 (of $40) loan interest from Alice's personal cash
LPS does not pay a dividend
LPS price goes from $110(F1) to $100(E1).

and the cash amounts change accordingly, so I think it's all working fine.

Loan repayment remains to be done.

Erik Vos

[Rails-devel] 1856 loans

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

I have implemented part of the basic "loans" functionality and the specific
way it works in 1856.
This only applies to loans taking. Interest payment and loan repayment
remain to be done.

The 1856 OR window now has a new "Loans" menu, where "Take loan(s)" is
enabled whenever applicable.

As usual, there are some side effects. The main one is, that I have changed
the multi-parameter version of LocalText.getText() to use varargs. This is
now causing a lot of new warnings. I will fix there in the course of time
(unless someone does it ahead of me). The fix simply is removing "new
String[] {" and the corresponding closing brace.

Erik Vos 

[Rails-devel] StartRound item info

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

Just to see what can be achieved in a simple way, I have added a column of
info icons to the StartRoundWindow, one for each start item. Hovering the
mouse over an icon will show up a tooltip describing the item. This
description is mainly composed from the toString() results of the objects
contained in each item.

I have found the icon in the sourceforge icon-collection. It's a simple
20x20 pixel gif, which I have stored in a new folder rails/ui/images. 

I think the descriptions are already pretty good, although I see room for
improvement. Perhaps we should add getDescription() methods to create
descriptions that are better tailored for UI display. Another approach could
be to add some blurb for each start item in CompanyManager.xml, but for a
nice effect I would be in favour to have it HTML-encoded, as it is now.

Please let me know what you think about this all.

Revealing the item status (other than the already available buyable and
biddable tooltips) is not so straightforward if we want to follow the
existing patterns (intended to support the future client/server split). It's
dynamic info that is not yet passed from engine to UI, and the "normal" way
to add it would be through the existing Observable/Observer interface. This
would definitely need more work.

As for the colour coding of the item status: if we want to go that way, I
would be in favour of minimal changes, like:
sold: black on white (as is)
biddable/select for auctioning: black on orange (as is).
buyable: bright green on orange.
not yet available: grey on white.

Erik.


-----Original Message-----
From: Erik Vos [mailto:eri...@hc...] 
Sent: Tuesday 06 January 2009 20:52
To: 'Development list for Rails: an 18xx game'
Subject: Re:
[Rails-devel][Rails-commits]18xx/rails/gameStartRound_1835.java, 1.15, 1.16

In fact, tooltips are already used to indicate whether items can be bought,
bid upon, or selected for bidding (as in 18EU). 
Currently, tooltips are only implemented for the 'active' ClickField UI
objects, not for the 'passive' Field objects; but that should not be
difficult to add. 
Please note, that we are talking about a mix of static info (the private
properties) which can be handled in the UI only, and dynamic info (the item
status), which needs be conveyed from the server. If we really are mixing up
these two bits of info, the Field and ClickField object will get more
complex. Perhaps we should subclass Field to add such tooltips.

Erik.

-----Original Message-----
From: brett lentz [mailto:wak...@gm...] 
Sent: Tuesday 06 January 2009 02:54
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel]
[Rails-commits]18xx/rails/gameStartRound_1835.java, 1.15, 1.16

It shouldn't be hard to do some tooltips for these.

---Brett.

On Mon, Jan 5, 2009 at 3:58 PM, Mark Smith <mar...@gm...> wrote:
> One of the other pieces of information I would like to see on the Start
> Packet info is some way to describe the special features of the item
> (Private Company restrict placement on hex XX, Private Company can be
traded
> for Share of Company YYY, Purchase of item comes with Share of XXX, etc).
> This would be applicable across all games, and would help to remind folks
> what the item does for them.
>
> This could be done with a simple icon, or text of --- ?? -- that is either
a
> hoverable item that shows a pop-up/tool-tip, or an actual hyper link to
> generate a pop-up dialog box.
>
> Mark
>
> On Mon, Jan 5, 2009 at 1:55 PM, brett lentz <wak...@gm...> wrote:
>>
>> I worry that an extra column might add clutter.
>>
>> I like the strikethrough idea or using colors to convey this
>> meta-information.
>>
>> ---Brett.
>>
>> On Mon, Jan 5, 2009 at 10:24 AM, Erik Vos <eri...@hc...> wrote:
>> > Mark,
>> >
>> > What about an extra column in which to display the item status (a short
>> > text)?
>> > Status values could be like "buyable", "biddable", "sold", "low cash",
>> > "not
>> > yet".
>> > Could display these values in different colours as well (e.g. the first
>> > two
>> > in black, the last three in gray).
>> >
>> > Erik.
>> >
>> > ________________________________
>> > From: Mark Smith [mailto:mar...@gm...]
>> > Sent: Monday 05 January 2009 00:13
>> > To: Development list for Rails: an 18xx game
>> > Subject: Re: [Rails-devel] [Rails-commits]
>> > 18xx/rails/gameStartRound_1835.java, 1.15, 1.16
>> >
>> > Erik,
>> >
>> > Yes, now that I went back an re-read the rules I quoted, I see that my
>> > interpretation was in error.
>> >
>> > Part of the reason I was looking at this issue, besides the fact I knew
>> > it
>> > was wrong, was that I was trying to figure out if there was a better
way
>> > to
>> > display the start packet for 1835 (and others) where you have multiple
>> > items
>> > available at the start, but not all. A display by row of everything in
>> > the
>> > row.
>> >
>> > In working with this, I also see that an item becomes un-available if
>> > there
>> > is no sufficient cash for the player to purchase it. But it is not
>> > immediately obvious, unless you look at the price, and the cash. What
>> > would
>> > help is for some way to indicate items that have been SOLD (maybe draw
a
>> > line through), or draw as blank -- and then for those you can't buy due
>> > to
>> > insufficient cash, to have a tool tip explain why it is not available
>> > for
>> > the player.
>> >
>> > Mark
>> >
>> > P.S. I do need to get back to my Tile Tray contribution -- and I
thought
>> > with 4 days at home (New Years) I would find the time. However, the
>> > puppy
>> > kept distracting me.
>> >
>> > On Sun, Jan 4, 2009 at 8:15 AM, Erik Vos <eri...@hc...> wrote:
>> >>
>> >>        Modified Files:
>> >>                StartRound_1835.java
>> >>        Log Message:
>> >>        Improve Start Packet Handling so that only the left most item
>> >> from
>> >> the second available row is for sale, rather than the   entire second
>> >> row.
>> >>
>> >> Mark,
>> >>
>> >> thanks for spotting this error. However, unfortunately your fix was
not
>> >> entirely correct.
>> >> For instance, when the first and second rows were completely sold, the
>> >> entire third row but also the first item of the fourth row became
>> >> available.
>> >>
>> >> The original error was only that item++ was missing after the last
>> >> buyable=true statement.
>> >> I have now fixed it slightly differently: by moving item++ downwards.
>> >>
>> >> Erik.
>> >>
>> >>
>> >>
>> >>
>> >>
----------------------------------------------------------------------------
--
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>> >
>> >
----------------------------------------------------------------------------
--
>> >
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>>
>>
>>
----------------------------------------------------------------------------
--
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
----------------------------------------------------------------------------
--
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

----------------------------------------------------------------------------
--
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel


----------------------------------------------------------------------------
--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] [Rails-commits]18xx/rails/gameStartRound_1835.java, 1.15, 1.16

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

In fact, tooltips are already used to indicate whether items can be bought,
bid upon, or selected for bidding (as in 18EU). 
Currently, tooltips are only implemented for the 'active' ClickField UI
objects, not for the 'passive' Field objects; but that should not be
difficult to add. 
Please note, that we are talking about a mix of static info (the private
properties) which can be handled in the UI only, and dynamic info (the item
status), which needs be conveyed from the server. If we really are mixing up
these two bits of info, the Field and ClickField object will get more
complex. Perhaps we should subclass Field to add such tooltips.

Erik.

-----Original Message-----
From: brett lentz [mailto:wak...@gm...] 
Sent: Tuesday 06 January 2009 02:54
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel]
[Rails-commits]18xx/rails/gameStartRound_1835.java, 1.15, 1.16

It shouldn't be hard to do some tooltips for these.

---Brett.

On Mon, Jan 5, 2009 at 3:58 PM, Mark Smith <mar...@gm...> wrote:
> One of the other pieces of information I would like to see on the Start
> Packet info is some way to describe the special features of the item
> (Private Company restrict placement on hex XX, Private Company can be
traded
> for Share of Company YYY, Purchase of item comes with Share of XXX, etc).
> This would be applicable across all games, and would help to remind folks
> what the item does for them.
>
> This could be done with a simple icon, or text of --- ?? -- that is either
a
> hoverable item that shows a pop-up/tool-tip, or an actual hyper link to
> generate a pop-up dialog box.
>
> Mark
>
> On Mon, Jan 5, 2009 at 1:55 PM, brett lentz <wak...@gm...> wrote:
>>
>> I worry that an extra column might add clutter.
>>
>> I like the strikethrough idea or using colors to convey this
>> meta-information.
>>
>> ---Brett.
>>
>> On Mon, Jan 5, 2009 at 10:24 AM, Erik Vos <eri...@hc...> wrote:
>> > Mark,
>> >
>> > What about an extra column in which to display the item status (a short
>> > text)?
>> > Status values could be like "buyable", "biddable", "sold", "low cash",
>> > "not
>> > yet".
>> > Could display these values in different colours as well (e.g. the first
>> > two
>> > in black, the last three in gray).
>> >
>> > Erik.
>> >
>> > ________________________________
>> > From: Mark Smith [mailto:mar...@gm...]
>> > Sent: Monday 05 January 2009 00:13
>> > To: Development list for Rails: an 18xx game
>> > Subject: Re: [Rails-devel] [Rails-commits]
>> > 18xx/rails/gameStartRound_1835.java, 1.15, 1.16
>> >
>> > Erik,
>> >
>> > Yes, now that I went back an re-read the rules I quoted, I see that my
>> > interpretation was in error.
>> >
>> > Part of the reason I was looking at this issue, besides the fact I knew
>> > it
>> > was wrong, was that I was trying to figure out if there was a better
way
>> > to
>> > display the start packet for 1835 (and others) where you have multiple
>> > items
>> > available at the start, but not all. A display by row of everything in
>> > the
>> > row.
>> >
>> > In working with this, I also see that an item becomes un-available if
>> > there
>> > is no sufficient cash for the player to purchase it. But it is not
>> > immediately obvious, unless you look at the price, and the cash. What
>> > would
>> > help is for some way to indicate items that have been SOLD (maybe draw
a
>> > line through), or draw as blank -- and then for those you can't buy due
>> > to
>> > insufficient cash, to have a tool tip explain why it is not available
>> > for
>> > the player.
>> >
>> > Mark
>> >
>> > P.S. I do need to get back to my Tile Tray contribution -- and I
thought
>> > with 4 days at home (New Years) I would find the time. However, the
>> > puppy
>> > kept distracting me.
>> >
>> > On Sun, Jan 4, 2009 at 8:15 AM, Erik Vos <eri...@hc...> wrote:
>> >>
>> >>        Modified Files:
>> >>                StartRound_1835.java
>> >>        Log Message:
>> >>        Improve Start Packet Handling so that only the left most item
>> >> from
>> >> the second available row is for sale, rather than the   entire second
>> >> row.
>> >>
>> >> Mark,
>> >>
>> >> thanks for spotting this error. However, unfortunately your fix was
not
>> >> entirely correct.
>> >> For instance, when the first and second rows were completely sold, the
>> >> entire third row but also the first item of the fourth row became
>> >> available.
>> >>
>> >> The original error was only that item++ was missing after the last
>> >> buyable=true statement.
>> >> I have now fixed it slightly differently: by moving item++ downwards.
>> >>
>> >> Erik.
>> >>
>> >>
>> >>
>> >>
>> >>
----------------------------------------------------------------------------
--
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>> >
>> >
----------------------------------------------------------------------------
--
>> >
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>>
>>
>>
----------------------------------------------------------------------------
--
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
----------------------------------------------------------------------------
--
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

----------------------------------------------------------------------------
--
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] [Rails-commits] 18xx/rails/gameStartRound_1835.java, 1.15, 1.16

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

It shouldn't be hard to do some tooltips for these.

---Brett.

On Mon, Jan 5, 2009 at 3:58 PM, Mark Smith <mar...@gm...> wrote:
> One of the other pieces of information I would like to see on the Start
> Packet info is some way to describe the special features of the item
> (Private Company restrict placement on hex XX, Private Company can be traded
> for Share of Company YYY, Purchase of item comes with Share of XXX, etc).
> This would be applicable across all games, and would help to remind folks
> what the item does for them.
>
> This could be done with a simple icon, or text of --- ?? -- that is either a
> hoverable item that shows a pop-up/tool-tip, or an actual hyper link to
> generate a pop-up dialog box.
>
> Mark
>
> On Mon, Jan 5, 2009 at 1:55 PM, brett lentz <wak...@gm...> wrote:
>>
>> I worry that an extra column might add clutter.
>>
>> I like the strikethrough idea or using colors to convey this
>> meta-information.
>>
>> ---Brett.
>>
>> On Mon, Jan 5, 2009 at 10:24 AM, Erik Vos <eri...@hc...> wrote:
>> > Mark,
>> >
>> > What about an extra column in which to display the item status (a short
>> > text)?
>> > Status values could be like "buyable", "biddable", "sold", "low cash",
>> > "not
>> > yet".
>> > Could display these values in different colours as well (e.g. the first
>> > two
>> > in black, the last three in gray).
>> >
>> > Erik.
>> >
>> > ________________________________
>> > From: Mark Smith [mailto:mar...@gm...]
>> > Sent: Monday 05 January 2009 00:13
>> > To: Development list for Rails: an 18xx game
>> > Subject: Re: [Rails-devel] [Rails-commits]
>> > 18xx/rails/gameStartRound_1835.java, 1.15, 1.16
>> >
>> > Erik,
>> >
>> > Yes, now that I went back an re-read the rules I quoted, I see that my
>> > interpretation was in error.
>> >
>> > Part of the reason I was looking at this issue, besides the fact I knew
>> > it
>> > was wrong, was that I was trying to figure out if there was a better way
>> > to
>> > display the start packet for 1835 (and others) where you have multiple
>> > items
>> > available at the start, but not all. A display by row of everything in
>> > the
>> > row.
>> >
>> > In working with this, I also see that an item becomes un-available if
>> > there
>> > is no sufficient cash for the player to purchase it. But it is not
>> > immediately obvious, unless you look at the price, and the cash. What
>> > would
>> > help is for some way to indicate items that have been SOLD (maybe draw a
>> > line through), or draw as blank -- and then for those you can't buy due
>> > to
>> > insufficient cash, to have a tool tip explain why it is not available
>> > for
>> > the player.
>> >
>> > Mark
>> >
>> > P.S. I do need to get back to my Tile Tray contribution -- and I thought
>> > with 4 days at home (New Years) I would find the time. However, the
>> > puppy
>> > kept distracting me.
>> >
>> > On Sun, Jan 4, 2009 at 8:15 AM, Erik Vos <eri...@hc...> wrote:
>> >>
>> >>        Modified Files:
>> >>                StartRound_1835.java
>> >>        Log Message:
>> >>        Improve Start Packet Handling so that only the left most item
>> >> from
>> >> the second available row is for sale, rather than the   entire second
>> >> row.
>> >>
>> >> Mark,
>> >>
>> >> thanks for spotting this error. However, unfortunately your fix was not
>> >> entirely correct.
>> >> For instance, when the first and second rows were completely sold, the
>> >> entire third row but also the first item of the fourth row became
>> >> available.
>> >>
>> >> The original error was only that item++ was missing after the last
>> >> buyable=true statement.
>> >> I have now fixed it slightly differently: by moving item++ downwards.
>> >>
>> >> Erik.
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] [Rails-commits] 18xx/rails/gameStartRound_1835.java, 1.15, 1.16

[Mark S. <mar...@gm...>]

One of the other pieces of information I would like to see on the Start
Packet info is some way to describe the special features of the item
(Private Company restrict placement on hex XX, Private Company can be traded
for Share of Company YYY, Purchase of item comes with Share of XXX, etc).
This would be applicable across all games, and would help to remind folks
what the item does for them.

This could be done with a simple icon, or text of --- ?? -- that is either a
hoverable item that shows a pop-up/tool-tip, or an actual hyper link to
generate a pop-up dialog box.

Mark

On Mon, Jan 5, 2009 at 1:55 PM, brett lentz <wak...@gm...> wrote:

> I worry that an extra column might add clutter.
>
> I like the strikethrough idea or using colors to convey this
> meta-information.
>
> ---Brett.
>
> On Mon, Jan 5, 2009 at 10:24 AM, Erik Vos <eri...@hc...> wrote:
> > Mark,
> >
> > What about an extra column in which to display the item status (a short
> > text)?
> > Status values could be like "buyable", "biddable", "sold", "low cash",
> "not
> > yet".
> > Could display these values in different colours as well (e.g. the first
> two
> > in black, the last three in gray).
> >
> > Erik.
> >
> > ________________________________
> > From: Mark Smith [mailto:mar...@gm...]
> > Sent: Monday 05 January 2009 00:13
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] [Rails-commits]
> > 18xx/rails/gameStartRound_1835.java, 1.15, 1.16
> >
> > Erik,
> >
> > Yes, now that I went back an re-read the rules I quoted, I see that my
> > interpretation was in error.
> >
> > Part of the reason I was looking at this issue, besides the fact I knew
> it
> > was wrong, was that I was trying to figure out if there was a better way
> to
> > display the start packet for 1835 (and others) where you have multiple
> items
> > available at the start, but not all. A display by row of everything in
> the
> > row.
> >
> > In working with this, I also see that an item becomes un-available if
> there
> > is no sufficient cash for the player to purchase it. But it is not
> > immediately obvious, unless you look at the price, and the cash. What
> would
> > help is for some way to indicate items that have been SOLD (maybe draw a
> > line through), or draw as blank -- and then for those you can't buy due
> to
> > insufficient cash, to have a tool tip explain why it is not available for
> > the player.
> >
> > Mark
> >
> > P.S. I do need to get back to my Tile Tray contribution -- and I thought
> > with 4 days at home (New Years) I would find the time. However, the puppy
> > kept distracting me.
> >
> > On Sun, Jan 4, 2009 at 8:15 AM, Erik Vos <eri...@hc...> wrote:
> >>
> >>        Modified Files:
> >>                StartRound_1835.java
> >>        Log Message:
> >>        Improve Start Packet Handling so that only the left most item
> from
> >> the second available row is for sale, rather than the   entire second
> row.
> >>
> >> Mark,
> >>
> >> thanks for spotting this error. However, unfortunately your fix was not
> >> entirely correct.
> >> For instance, when the first and second rows were completely sold, the
> >> entire third row but also the first item of the fourth row became
> >> available.
> >>
> >> The original error was only that item++ was missing after the last
> >> buyable=true statement.
> >> I have now fixed it slightly differently: by moving item++ downwards.
> >>
> >> Erik.
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] [Rails-commits] 18xx/rails/gameStartRound_1835.java, 1.15, 1.16

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

I worry that an extra column might add clutter.

I like the strikethrough idea or using colors to convey this meta-information.

---Brett.

On Mon, Jan 5, 2009 at 10:24 AM, Erik Vos <eri...@hc...> wrote:
> Mark,
>
> What about an extra column in which to display the item status (a short
> text)?
> Status values could be like "buyable", "biddable", "sold", "low cash", "not
> yet".
> Could display these values in different colours as well (e.g. the first two
> in black, the last three in gray).
>
> Erik.
>
> ________________________________
> From: Mark Smith [mailto:mar...@gm...]
> Sent: Monday 05 January 2009 00:13
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] [Rails-commits]
> 18xx/rails/gameStartRound_1835.java, 1.15, 1.16
>
> Erik,
>
> Yes, now that I went back an re-read the rules I quoted, I see that my
> interpretation was in error.
>
> Part of the reason I was looking at this issue, besides the fact I knew it
> was wrong, was that I was trying to figure out if there was a better way to
> display the start packet for 1835 (and others) where you have multiple items
> available at the start, but not all. A display by row of everything in the
> row.
>
> In working with this, I also see that an item becomes un-available if there
> is no sufficient cash for the player to purchase it. But it is not
> immediately obvious, unless you look at the price, and the cash. What would
> help is for some way to indicate items that have been SOLD (maybe draw a
> line through), or draw as blank -- and then for those you can't buy due to
> insufficient cash, to have a tool tip explain why it is not available for
> the player.
>
> Mark
>
> P.S. I do need to get back to my Tile Tray contribution -- and I thought
> with 4 days at home (New Years) I would find the time. However, the puppy
> kept distracting me.
>
> On Sun, Jan 4, 2009 at 8:15 AM, Erik Vos <eri...@hc...> wrote:
>>
>>        Modified Files:
>>                StartRound_1835.java
>>        Log Message:
>>        Improve Start Packet Handling so that only the left most item from
>> the second available row is for sale, rather than the   entire second row.
>>
>> Mark,
>>
>> thanks for spotting this error. However, unfortunately your fix was not
>> entirely correct.
>> For instance, when the first and second rows were completely sold, the
>> entire third row but also the first item of the fourth row became
>> available.
>>
>> The original error was only that item++ was missing after the last
>> buyable=true statement.
>> I have now fixed it slightly differently: by moving item++ downwards.
>>
>> Erik.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] [Rails-commits] 18xx/rails/gameStartRound_1835.java, 1.15, 1.16

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

Mark,
 
What about an extra column in which to display the item status (a short
text)? 
Status values could be like "buyable", "biddable", "sold", "low cash", "not
yet".
Could display these values in different colours as well (e.g. the first two
in black, the last three in gray).
 
Erik.


  _____  

From: Mark Smith [mailto:mar...@gm...] 
Sent: Monday 05 January 2009 00:13
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] [Rails-commits]
18xx/rails/gameStartRound_1835.java, 1.15, 1.16


Erik,

Yes, now that I went back an re-read the rules I quoted, I see that my
interpretation was in error. 

Part of the reason I was looking at this issue, besides the fact I knew it
was wrong, was that I was trying to figure out if there was a better way to
display the start packet for 1835 (and others) where you have multiple items
available at the start, but not all. A display by row of everything in the
row. 

In working with this, I also see that an item becomes un-available if there
is no sufficient cash for the player to purchase it. But it is not
immediately obvious, unless you look at the price, and the cash. What would
help is for some way to indicate items that have been SOLD (maybe draw a
line through), or draw as blank -- and then for those you can't buy due to
insufficient cash, to have a tool tip explain why it is not available for
the player.

Mark

P.S. I do need to get back to my Tile Tray contribution -- and I thought
with 4 days at home (New Years) I would find the time. However, the puppy
kept distracting me. 


On Sun, Jan 4, 2009 at 8:15 AM, Erik Vos <eri...@hc...> wrote:


       Modified Files:
               StartRound_1835.java
       Log Message:
       Improve Start Packet Handling so that only the left most item from
the second available row is for sale, rather than the   entire second row.


Mark,

thanks for spotting this error. However, unfortunately your fix was not
entirely correct.
For instance, when the first and second rows were completely sold, the
entire third row but also the first item of the fourth row became available.

The original error was only that item++ was missing after the last
buyable=true statement.
I have now fixed it slightly differently: by moving item++ downwards.

Erik.


----------------------------------------------------------------------------
--
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] [Rails-commits] 18xx/rails/game StartRound_1835.java, 1.15, 1.16

[Mark S. <mar...@gm...>]

Erik,

Yes, now that I went back an re-read the rules I quoted, I see that my
interpretation was in error.

Part of the reason I was looking at this issue, besides the fact I knew it
was wrong, was that I was trying to figure out if there was a better way to
display the start packet for 1835 (and others) where you have multiple items
available at the start, but not all. A display by row of everything in the
row.

In working with this, I also see that an item becomes un-available if there
is no sufficient cash for the player to purchase it. But it is not
immediately obvious, unless you look at the price, and the cash. What would
help is for some way to indicate items that have been SOLD (maybe draw a
line through), or draw as blank -- and then for those you can't buy due to
insufficient cash, to have a tool tip explain why it is not available for
the player.

Mark

P.S. I do need to get back to my Tile Tray contribution -- and I thought
with 4 days at home (New Years) I would find the time. However, the puppy
kept distracting me.

On Sun, Jan 4, 2009 at 8:15 AM, Erik Vos <eri...@hc...> wrote:

>        Modified Files:
>                StartRound_1835.java
>        Log Message:
>        Improve Start Packet Handling so that only the left most item from
> the second available row is for sale, rather than the   entire second row.
>
> Mark,
>
> thanks for spotting this error. However, unfortunately your fix was not
> entirely correct.
> For instance, when the first and second rows were completely sold, the
> entire third row but also the first item of the fourth row became
> available.
>
> The original error was only that item++ was missing after the last
> buyable=true statement.
> I have now fixed it slightly differently: by moving item++ downwards.
>
> Erik.
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Rails 1.0.6

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

John, 

	3.	KBS's director had to contribute 246 from hand to fund 
	purchase of a 6 train for 600, and then subsequently issued shares 
	during the last element of the operating round.  But the KBS
treasury 
	shares as issued were deducted from the treasury so that KBS ended
up 
	with a negative treasury balance of 270 (3 shares @ 90).  This then 
	meant the KBS was not allowed by the program to lay any track at all

	because its cash was less than zero.  (I fixed this for game
purposes 
	by giving the KBS a hugely large dividend equal to twice the 
	difference between the negative amount it had and the positive
amount 
	it should have had, and then splitting.  Of course, I then had to 
	make a mental adjustment of the players' cash totals to discount the

	phantom dividend.)

Again, I'm unable to reproduce this error. I would need a more detailed
description of how you got to this game status, or (much better) a saved
file.

Erik.