Re: [Rails-devel] 1856 CGR Diesel upgrades

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

Erik Vos wrote:
> 	> FWIW, Dirk Clemens' 18xx moderator enforces train-buying rules,
> but
> 	> does not force the CGR to upgrade a 4 to a Diesel.
> 
> 	This brings up the broader question of the rules language that, as
> 	Dirk believes, requires as follows: CGR *must* acquire a permanent
> 	train ASAP, and cannot pay out or change share price in any way
> until
> 	it has done so.
> 
> 	In my reading of the rules, *all* the requirements in the preceding
> 	sentence are part of the paragraph about what happens when the CGR
> 	borrows a Diesel, and apply only then.  (Meaning that a CGR which
> owns
> 	only 4-trains is free to operate normally in all respects; but if
> CGR
> 	forms with no trains, or it forms with only 4-trains and they die
> 	before it ever owns a permanent train, *only then* it must borrow a
> 	diesel, withhold, and not change price until it buys a permanent
> 	train.)
> 
> Assuming that there is no debate on the following:
> a. the CGR cannot borrow a Diesel if it owns a 4-train,
> b. the CGR price does not change until it has a permanent train,

I disagree with b.

> then I think the only remaining questions are
> c. whether the CGR must withhold if it doesn't yet have a permanent train,
> and
> d. whether it *must* exchange the 4-train for a Diesel as soon as it has the
> money.
> I'm pretty sure that Rails says "yes" to c and (currently) "no" to d,
> but in the latter case only because it never enforces train buying now.
> 
> My personal opinion is that both questions should be answered with "yes",
> but if people want options, it's probably no big deal to add these.
> 
> 	At any rate, 1.1.1 does not yet enforce these requirements.  But if
> 	they are ever implemented, I want the option to have them only apply
> 	when I believe they're supposed to.
> 
> 	* * *
> 
> 	Other noteworthy behaviors I found when trying out 1856 last night:
> 
> 	1.  If I use the options menu to view the map during a stock round,
> 	it still contains text directing the company that ran last to buy a
> 	train or hit Done (even though all action buttons are grayed out).
> 
> Yes, it annoys me too, but so far not enough to do anything about it.
> Perhaps you have given the final push now...
> 
> 	2.  I like the use of separate arrows in the red map areas.
> (Earlier
> 	playings of 18AL and 1830 had them looking like "dits" with tracks
> 	that connected to each other.)
> 
> This is a recent change, that applies to all games.
> 
> 	3.  There are places where "hovering" over the map with the mouse
> 	does not tell you how much a space pays (Goderich for one).
> 
> I'm only aware of Goderich (and the equivalent 18EU Hamburg).
> It's because the city does not show and is not included in the descriptive
> XML,
> which makes the program fail to understand that there is a revenue point.
> Should be easy to fix.
> Are you aware of any other cases?

Not yet.

> 	4.  Adding a "bonus" column to the company table in the map window,
> 	and showing $10 if it has a bridge or tunnel token, is not helpful
> 	because it doesn't say which is which.  I'd write "Br" or "Tu"
> there.
> 	(And purchases of these tokens are still mis-described as if the
> money
> 	were going to the company it's actually coming from.)
> 
> "Br" and "Tu" have in fact already been added.
> 
> 	5.  The CGR formation is unfriendly and wrong.
> 	   a)  Before asking for any player's decision, the program should
> force
> 	       all companies that have at least $100 and any loans to repay
> what
> 	       loans they can from treasury.  This is immediate and
> compulsory.
> 	       (It does do this for each company before asking the question
> for
> 	       that company, but that's too late because it makes some
> companies
> 	       look like they could convert when they can't, when the player
> is
> 	       making his decision for earlier companies.)
> 
> The program literally follows the rules here.
> 
> 	   b)  There shouldn't be ANY dialogs asking "Select number of loans
> of
> 	       [company] to repay".  The decision for each company is all or
> 	       nothing, and each player should be presented with the
> decisions
> 	       for all his companies at once (in one dialog).
> 
> The rules do not say or imply anything like "all or nothing".
> This aspect has been discussed beforehand in this list, and the 
> outcome was that the user should be given all legal options, 
> including partial repayment, however stupid that would be.
> However, I can see your point from a usability POV. 
> 
> The only real deviation from the rules is that each player now does not 
> get a choice in which sequence company repayments will be handled; 
> the program is imposing that sequence. So I can agree with the 
> "in one dialog" part of your request - which, unfortunately,
> may not be so easy to do.
> 
> 	   c)  During those "rescue?" dialogs, the players' cash amounts in
> the
> 	       Game Status window are squeezed horizontally so they can't be
> 	       read (example: $1... instead of $1445), and it's impossible
> to
> 	       fix it by resizing the window because the dialog is modal.
> 
> I'll look at that.

(c) makes (b) worse.  The player may not know whether he can rescue both
companies A and B until after he's decided about A and it's too late.

> 	   d)  After the first decision is made, change the Loans column on
> the
> 	       Game Status window to show "MERGE" for companies that will
> merge.
> 
> Good idea, but it will require some structural changes that make it
> not as easy to do as it might seem.
> 
> 	   e)  When four companies whose current prices were 65, 65, 75, and
> 100
> 	       merged in, the program made CGR's value 200 (and that
> actually
> 	       meant $200 per 5% share).  It's supposed to be the average of
> the
> 	       predecessor companies, but not less than 100, so in this
> example
> 	       it should have been 100, not 200.
> 
> That surprises me; I have only seen reasonable results so far.
> Perhaps you have hit on a boundary condition.
> Do you have saved file that shows it?

Attached.

> 	   f)  Those companies had two 5 trains and a 4 train.  CGR was not
> given
> 	       the option of keeping the 4 train, it was discarded with no
> prompt.
> 
> This has been fixed in the meantime.
> 
> 	   g)  The table of companies in map window is not updated afterward
> to
> 	       show that some companies have disappeared.
> 
> That never happens during an OR. I have toyed with it, but found that the 
> bookkeeping of whose turn it is after CGR formation was tricky enough
> without such a reorganization. Perhaps later.
> 
> 	   h)  The table of companies in Game Status window continues to
> list the
> 	       merged companies for the rest of the game, with their final
> prices
> 	       and the number of loans when they died.  They should no
> longer be
> 	       listed at all (nor should any company that went to the Closed
> box).
> 
> The Game Status window is never cleaned up now. Even the 15 minors 
> in 18EU remain visible long after these have closed. 
> One day it will be fixed, I guess.
> 
> 	   i)  In subsequent rounds, CGR is shown as having TWO $10 bonuses
> (and
> 	       thus takes two lines in the table in the map window) because
> two
> 	       predecessor companies had tunnel tokens.  CGR should inherit
> only
> 	       up to one of each type of token (tunnel and bridge);
> duplicates
> 	       should go back to the bank and become available for sale (if
> 	       played as finite); and in any case, the table should expand
> 	       horizontally, not vertically, if it must expand at all.
> 
> That has been fixed now, except for the expansion aspect, where I'm
> undecided which is best.

Perhaps they should not be listed at all.  That also goes for token
locations (the whole map window got *much* wider when CGR formed and
dropped 7 tokens on the board, it was quite annoying).

> 	6.  The program allows CGR to buy 4-trains after it forms.  It
> can't.
> 
> If that is so, it's a bug. I don't yet have test cases where CGR 
> has less than three trains after formation - can you send me one?

The same save file has that situation.  Indeed, I later wanted to buy
a 6-train with CGR but it was grayed out: I meant to add to this list
"7. CGR's train limit should be 3", because I suspect the program is
imposing a limit of 2.

This was with the 1.1.1 release; I haven't gotten to where I can build
development code yet, but I hope to soon.