rails-devel — List for discussion of Rails development

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.

Re: [Rails-devel] 1856 CGR Diesel upgrades

[Aliza P. <ali...@gm...>]

The CGR formation decisions are done by players, not companies, in
player order rather than by company order, and the rules specifically
state that the player may handle their companies in any order they
choose.

Since players can't sell shares to help finance this, there's no real
benefit to allowing them to choose order among their companies, but
letting them see the big picture would be useful, especially for
hotseat play.

(I'll also mention that it was rather disconcerting to have the map
hide itself during the CGR formation dialog.  While players should
have already made the save/toss decision for each company beforehand,
some might want to consult the map to see a company's potential.)

 - Aliza

Re: [Rails-devel] 1856 CGR Diesel upgrades

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

On Tue, Dec 29, 2009 at 3:39 AM, Erik Vos <eri...@xs...> wrote:
>           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.
>
> Erik.

I disagree on this point.

The player is acting on behalf of the company.  Otherwise, the loans
are not the player's to repay. The player's responsibility to repay
the loans only exists insofar as that player is president of the
company that possesses the loans.

If I own companies A and B, and A has some number of loans, they can
only be repaid during company A's turn, not during company B's turn.
It is not legal to repay loans outside of the owing company's turn.

So, in this case, what rails does is correct.

However, that's not to say that the manner in which it's presented to
the user is ideal. There's always room for tuning the UI to make it
easier to work with.

---Brett.

Re: [Rails-devel] 1856 CGR Diesel upgrades

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

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


Yes, options are good, as I have played with people who thought the answer
to both questions was no.


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

I submitted a feature request for this.

In regard to the discussion of the order of the CGR formation actions, I
suspect the best solution would be to provide more information to the
players about which companies might merge, which have already merged, etc.
Perhaps a completely separate summary window screen would work?  I have no
idea how difficult that would be to provide.

          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 submitted a feature request for these.


> --
Chris

Please consider the environment before printing this e-mail.

Re: [Rails-devel] 1856 CGR Diesel upgrades

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

	> 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,
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?

	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.

	   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?

	   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.

	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?

Erik.

Re: [Rails-devel] How to check out the code from CVS (was: 1856: CGR Formation stalls when keeping all trains)

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

While I'm not super-familiar with how CVS deals with permissions, I
suspect that, for an authenticated user, there is no such thing as
"read-only" access.  So, being authenticated may mean possessing the
ability to commit.  (I'm sure google knows, I'm just too lazy to look
it up at the moment. ;-) )

If anonymous  checkouts succeed, I recommend using that for now.

---Brett.



On Mon, Dec 28, 2009 at 10:07 PM, Chris Shaffer <chr...@gm...> wrote:
> I've checked the project out anonymously using command line cvs because I
> got permission errors when authenticating.  I figured I'd try authenticated
> with Eclipse and also got a permission error.
>
> ***
> cvs co -d "18xx" -P -A "/18xx"
>     cvs checkout: Updating 18xx
>     cvs checkout: failed to create lock directory for `/cvsroot/rails/18xx'
> (/cvsroot/rails/18xx/#cvs.lock): Permission denied
>     cvs checkout: failed to obtain dir lock in repository
> `/cvsroot/rails/18xx'
>     cvs [checkout aborted]: read lock failed - giving up
> The server reported an error while performing the "cvs checkout" command.
> (took 0:00.387)
>    Error: : cvs checkout: failed to create lock directory for
> `/cvsroot/rails/18xx' (/cvsroot/rails/18xx/#cvs.lock): Permission denied
>    Error: : cvs checkout: failed to obtain dir lock in repository
> `/cvsroot/rails/18xx'
>    Error: : cvs [checkout aborted]: read lock failed - giving up
> ***
>
> Does one need to be added to an authorized user list to check it out while
> authenticated?
>
> p.s. Eclipse checked out the project fine with anonymous pserver.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
> On Sun, Dec 27, 2009 at 6:40 PM, brett lentz <wak...@gm...> wrote:
>>
>> It's even easier than that.
>>
>> 1. Download/Install Eclipse from http://www.eclipse.org/downloads/ ;
>> You'll want the "Eclipse IDE for Java Developers".
>> 2. In Eclipse, select File > New > Project
>> 3. Select Projects from CVS.
>> 4a. If you have a sourceforge.net login, use these settings:
>>
>> Host: rails.cvs.sourceforge.net
>> Repository Path: /cvsroot/rails
>> Connection Type:  extssh
>>
>> User and Password should be self-explanatory.
>>
>> 4b. If you don't have a sourceforge.net login, the only difference are
>> these two things:
>>
>> Connection Type: pserver
>> User: anonymous
>>
>>
>> This should check out the current codebase from CVS.
>>
>> Once you've got that, you can right-click on the project folder (or
>> click the Run menu), and select Run As, and select Java Application.
>> It should try to locate the main() method to run.  The one you want is
>> in rails.util.RunGame.
>>
>>
>> ---Brett.
>>
>>
>>
>> On Sun, Dec 27, 2009 at 3:05 PM, Erik Vos <eri...@xs...> wrote:
>> > Aliza,
>> >
>> > I have trimmed the save file, which I'll send separately to your private
>> > mail address.
>> > It now works with the new code base, giving the CGR its first turn.
>> >
>> > To run Rails from the code base, you should
>> > 1. Download the entire code tree as stored on Sourceforge,
>> > 2. Install Eclipse,
>> > 3. Create a new project from the downloaded source,
>> > 4. Create a Run entry for Rails.
>> > None of this is very difficult, I could help if needed.
>> > Otherwise, you'll have to wait for the next release, which I suppose
>> > will
>> > not take long.
>> >
>> > Erik.
>> >
>> > -----Original Message-----
>> > From: Aliza Panitz [mailto:ali...@gm...]
>> > Sent: Sunday 27 December 2009 21:15
>> > To: Development list for Rails: an 18xx game
>> > Subject: Re: [Rails-devel] 1856: CGR Formation stalls when keeping all
>> > trains
>> >
>> > Erik:
>> >
>> > I'm glad that my playtesting is useful!
>> >
>> > The only earlier savefile I have from this game is quite a bit
>> > earlier, when I saved the session to file a bug report on buying
>> > tunnel tokens after the first 5-train was bought. That's file
>> > 1856_20091224_2344-lps-cant-buy-tunnel-token.rails attached to my bug
>> > report from Dec. 24th.
>> >
>> > Clearly I'm used to different play styles than you are, as the CGR
>> > almost never drops its 4-trains in my experience. (However, I find it
>> > quite difficult to play "fair" with my imaginary friends, so my test
>> > games do develop a bit oddly at times.  )
>> >
>> > I'd be glad to play forward with your fixes, but I don't have a Java
>> > build environment on my laptop.  (I've never programmed anything in
>> > Java, and haven't done anything but shell and Perl scripts in quite a
>> > few years.)
>> >
>> >  - Aliza
>> >
>> > On Sun, Dec 27, 2009 at 10:45 AM, Erik Vos <eri...@xs...> wrote:
>> >> You're really good at finding bugs in untested dark corners
>> >> (i.e. special combinations of circumstances that have escaped
>> >> everyone's attention so far... :-)
>> >>
>> >> This time there were two:
>> >>
>> >> 1. If CGR did not discard a non-permanent train when offered
>> >> the chance to do so, the player action did not close that step,
>> >> i.e. the program started repeatedly asking the same question.
>> >>
>> >> 2. If, after CGR formation, all of the remaining companies
>> >> already have operated, the current OR must be finished and
>> >> a new OR must be started. That is what happened, but the
>> >> whole complex sequence of steps was incorrectly wrapped up,
>> >> so that in fact the old OR was trying to continue with a
>> >> company that already had been closed (in this case, the GT).
>> >>
>> >> I have uploaded fixes. However, your saved file still cannot
>> >> be processed because it contains a large sequence of DiscardTrain
>> >> actions, where only one is now expected by the fixed code.
>> >>
>> >> Do you still have a saved file from an earlier time?
>> >>
>> >> I am considering building a tool that would enable fixing
>> >> such unprocessible save files by removing invalid *trailing*
>> >> actions, but that may take a bit of time.
>> >>
>> >> Erik.
>> >>
>> >> -----Original Message-----
>> >> From: Aliza Panitz [mailto:ali...@gm...]
>> >> Sent: Friday 25 December 2009 02:18
>> >> To: Development list for Rails: an 18xx game
>> >> Subject: Re: [Rails-devel] 1856: CGR Formation stalls when keeping all
>> >> trains
>> >>
>> >> The savefile is too big, so my message is being held for moderator
>> > approval.
>> >>
>> >> On Thu, Dec 24, 2009 at 5:14 PM, Aliza Panitz <ali...@gm...>
>> >> wrote:
>> >>> Attached is a savefile from a game where the CGR forms with a 4 and
>> >>> two 5 trains.  Rails will not let me keep all three trains, although
>> >>> the CGR has a train limit of 3.
>> >>>
>> >>> Even if I discard a train, there doesn't appear to be a "done" button
>> >>> to let me proceed with play.
>> >>>
>> >>> I will also mention that having the map disappear as people are being
>> >>> asked to decide about CGR formation is quite disconcerting, as map
>> >>> position can be a factor in deciding whether or not to keep a
>> >>> struggling company. (There was no way to bring it back up.)
>> >>>
>> >>> I saved and reloaded the game, but it still appears to be stuck.
>> >>>
>> >>>  - Aliza
>> >>>
>> >>
>> >>
>> >
>> > ----------------------------------------------------------------------------
>> >> --
>> >> This SF.Net email is sponsored by the Verizon Developer Community
>> >> Take advantage of Verizon's best-in-class app development support
>> >> A streamlined, 14 day to market process makes app distribution fast and
>> > easy
>> >> Join now and get one step closer to millions of Verizon customers
>> >> http://p.sf.net/sfu/verizon-dev2dev
>> >>
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >>
>> >>
>> >>
>> >
>> > ----------------------------------------------------------------------------
>> > --
>> >> This SF.Net email is sponsored by the Verizon Developer Community
>> >> Take advantage of Verizon's best-in-class app development support
>> >> A streamlined, 14 day to market process makes app distribution fast and
>> > easy
>> >> Join now and get one step closer to millions of Verizon customers
>> >> http://p.sf.net/sfu/verizon-dev2dev
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >>
>> >
>> >
>> > ----------------------------------------------------------------------------
>> > --
>> > This SF.Net email is sponsored by the Verizon Developer Community
>> > Take advantage of Verizon's best-in-class app development support
>> > A streamlined, 14 day to market process makes app distribution fast and
>> > easy
>> > Join now and get one step closer to millions of Verizon customers
>> > http://p.sf.net/sfu/verizon-dev2dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > This SF.Net email is sponsored by the Verizon Developer Community
>> > Take advantage of Verizon's best-in-class app development support
>> > A streamlined, 14 day to market process makes app distribution fast and
>> > easy
>> > Join now and get one step closer to millions of Verizon customers
>> > http://p.sf.net/sfu/verizon-dev2dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and
>> easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] How to check out the code from CVS (was: 1856: CGR Formation stalls when keeping all trains)

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

I've checked the project out anonymously using command line cvs because I
got permission errors when authenticating.  I figured I'd try authenticated
with Eclipse and also got a permission error.

***
cvs co -d "18xx" -P -A "/18xx"
    cvs checkout: Updating 18xx
    cvs checkout: failed to create lock directory for `/cvsroot/rails/18xx'
(/cvsroot/rails/18xx/#cvs.lock): Permission denied
    cvs checkout: failed to obtain dir lock in repository
`/cvsroot/rails/18xx'
    cvs [checkout aborted]: read lock failed - giving up
The server reported an error while performing the "cvs checkout" command.
(took 0:00.387)
   Error: : cvs checkout: failed to create lock directory for
`/cvsroot/rails/18xx' (/cvsroot/rails/18xx/#cvs.lock): Permission denied
   Error: : cvs checkout: failed to obtain dir lock in repository
`/cvsroot/rails/18xx'
   Error: : cvs [checkout aborted]: read lock failed - giving up
***

Does one need to be added to an authorized user list to check it out while
authenticated?

p.s. Eclipse checked out the project fine with anonymous pserver.

--
Chris

Please consider the environment before printing this e-mail.


On Sun, Dec 27, 2009 at 6:40 PM, brett lentz <wak...@gm...> wrote:

> It's even easier than that.
>
> 1. Download/Install Eclipse from http://www.eclipse.org/downloads/ ;
> You'll want the "Eclipse IDE for Java Developers".
> 2. In Eclipse, select File > New > Project
> 3. Select Projects from CVS.
> 4a. If you have a sourceforge.net login, use these settings:
>
> Host: rails.cvs.sourceforge.net
> Repository Path: /cvsroot/rails
> Connection Type:  extssh
>
> User and Password should be self-explanatory.
>
> 4b. If you don't have a sourceforge.net login, the only difference are
> these two things:
>
> Connection Type: pserver
> User: anonymous
>
>
> This should check out the current codebase from CVS.
>
> Once you've got that, you can right-click on the project folder (or
> click the Run menu), and select Run As, and select Java Application.
> It should try to locate the main() method to run.  The one you want is
> in rails.util.RunGame.
>
>
> ---Brett.
>
>
>
> On Sun, Dec 27, 2009 at 3:05 PM, Erik Vos <eri...@xs...> wrote:
> > Aliza,
> >
> > I have trimmed the save file, which I'll send separately to your private
> > mail address.
> > It now works with the new code base, giving the CGR its first turn.
> >
> > To run Rails from the code base, you should
> > 1. Download the entire code tree as stored on Sourceforge,
> > 2. Install Eclipse,
> > 3. Create a new project from the downloaded source,
> > 4. Create a Run entry for Rails.
> > None of this is very difficult, I could help if needed.
> > Otherwise, you'll have to wait for the next release, which I suppose will
> > not take long.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Aliza Panitz [mailto:ali...@gm...]
> > Sent: Sunday 27 December 2009 21:15
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 1856: CGR Formation stalls when keeping all
> > trains
> >
> > Erik:
> >
> > I'm glad that my playtesting is useful!
> >
> > The only earlier savefile I have from this game is quite a bit
> > earlier, when I saved the session to file a bug report on buying
> > tunnel tokens after the first 5-train was bought. That's file
> > 1856_20091224_2344-lps-cant-buy-tunnel-token.rails attached to my bug
> > report from Dec. 24th.
> >
> > Clearly I'm used to different play styles than you are, as the CGR
> > almost never drops its 4-trains in my experience. (However, I find it
> > quite difficult to play "fair" with my imaginary friends, so my test
> > games do develop a bit oddly at times.  )
> >
> > I'd be glad to play forward with your fixes, but I don't have a Java
> > build environment on my laptop.  (I've never programmed anything in
> > Java, and haven't done anything but shell and Perl scripts in quite a
> > few years.)
> >
> >  - Aliza
> >
> > On Sun, Dec 27, 2009 at 10:45 AM, Erik Vos <eri...@xs...> wrote:
> >> You're really good at finding bugs in untested dark corners
> >> (i.e. special combinations of circumstances that have escaped
> >> everyone's attention so far... :-)
> >>
> >> This time there were two:
> >>
> >> 1. If CGR did not discard a non-permanent train when offered
> >> the chance to do so, the player action did not close that step,
> >> i.e. the program started repeatedly asking the same question.
> >>
> >> 2. If, after CGR formation, all of the remaining companies
> >> already have operated, the current OR must be finished and
> >> a new OR must be started. That is what happened, but the
> >> whole complex sequence of steps was incorrectly wrapped up,
> >> so that in fact the old OR was trying to continue with a
> >> company that already had been closed (in this case, the GT).
> >>
> >> I have uploaded fixes. However, your saved file still cannot
> >> be processed because it contains a large sequence of DiscardTrain
> >> actions, where only one is now expected by the fixed code.
> >>
> >> Do you still have a saved file from an earlier time?
> >>
> >> I am considering building a tool that would enable fixing
> >> such unprocessible save files by removing invalid *trailing*
> >> actions, but that may take a bit of time.
> >>
> >> Erik.
> >>
> >> -----Original Message-----
> >> From: Aliza Panitz [mailto:ali...@gm...]
> >> Sent: Friday 25 December 2009 02:18
> >> To: Development list for Rails: an 18xx game
> >> Subject: Re: [Rails-devel] 1856: CGR Formation stalls when keeping all
> >> trains
> >>
> >> The savefile is too big, so my message is being held for moderator
> > approval.
> >>
> >> On Thu, Dec 24, 2009 at 5:14 PM, Aliza Panitz <ali...@gm...>
> >> wrote:
> >>> Attached is a savefile from a game where the CGR forms with a 4 and
> >>> two 5 trains.  Rails will not let me keep all three trains, although
> >>> the CGR has a train limit of 3.
> >>>
> >>> Even if I discard a train, there doesn't appear to be a "done" button
> >>> to let me proceed with play.
> >>>
> >>> I will also mention that having the map disappear as people are being
> >>> asked to decide about CGR formation is quite disconcerting, as map
> >>> position can be a factor in deciding whether or not to keep a
> >>> struggling company. (There was no way to bring it back up.)
> >>>
> >>> I saved and reloaded the game, but it still appears to be stuck.
> >>>
> >>>  - Aliza
> >>>
> >>
> >>
> >
> ----------------------------------------------------------------------------
> >> --
> >> This SF.Net email is sponsored by the Verizon Developer Community
> >> Take advantage of Verizon's best-in-class app development support
> >> A streamlined, 14 day to market process makes app distribution fast and
> > easy
> >> Join now and get one step closer to millions of Verizon customers
> >> http://p.sf.net/sfu/verizon-dev2dev
> >>
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >>
> >>
> >
> ----------------------------------------------------------------------------
> > --
> >> This SF.Net email is sponsored by the Verizon Developer Community
> >> Take advantage of Verizon's best-in-class app development support
> >> A streamlined, 14 day to market process makes app distribution fast and
> > easy
> >> Join now and get one step closer to millions of Verizon customers
> >> http://p.sf.net/sfu/verizon-dev2dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >
> >
> ----------------------------------------------------------------------------
> > --
> > This SF.Net email is sponsored by the Verizon Developer Community
> > Take advantage of Verizon's best-in-class app development support
> > A streamlined, 14 day to market process makes app distribution fast and
> easy
> > Join now and get one step closer to millions of Verizon customers
> > http://p.sf.net/sfu/verizon-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Verizon Developer Community
> > Take advantage of Verizon's best-in-class app development support
> > A streamlined, 14 day to market process makes app distribution fast and
> easy
> > Join now and get one step closer to millions of Verizon customers
> > http://p.sf.net/sfu/verizon-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1856 CGR Diesel upgrades

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

Aliza Panitz wrote:
> A question on the Yahoo 18xx mailing list would split the group into
> two factions, each loudly insisting the other was wrong. :-)

Depends on the question.  We all agree on some things, and if a
question DOES produce two factions then it's likely the program ought
to give users a choice.

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

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

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

3.  There are places where "hovering" over the map with the mouse
does not tell you how much a space pays (Goderich for one).

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

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.)
   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).
   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.
   d)  After the first decision is made, change the Loans column on the
       Game Status window to show "MERGE" for companies that will merge.
   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.
   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.
   g)  The table of companies in map window is not updated afterward to
       show that some companies have disappeared.
   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).
   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.

6.  The program allows CGR to buy 4-trains after it forms.  It can't.

Re: [Rails-devel] 1856 CGR Diesel upgrades

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

	Does Rails enforce the rule about "the CGRs token does not move
	normally until it has a permanent train"?

It should.

Re: [Rails-devel] 1856 CGR Diesel upgrades

[Aliza P. <ali...@gm...>]

On Mon, Dec 28, 2009 at 7:25 AM, Erik Vos <eri...@xs...> wrote:
> [...]
>
> Train buying is never enforced (that was a recent change), but
> in my interpretation of the rules, the CGR would be required
> to exchange the 4-train in this case. But indeed the rules are
> silent on this matter.
> A question in the 18xx Yahoo group might get you a more
> authoritive answer.
>

A question on the Yahoo 18xx mailing list would split the group into
two factions, each loudly insisting the other was wrong. :-)

FWIW, Dirk Clemens' 18xx moderator enforces train-buying rules, but
does not force the CGR to upgrade a 4 to a Diesel.

I'm in a PBEM where we decided to go with whatever Rails enforced, but
it looks like Rails is also silent on the matter. ;-) (That's why I
was playing this particular test game -- I wanted to see what Rails
did once the CGR had accumulated $750 to go with the 4-train.  It
appears that I also needed to play through until the CGR had $1100.)

If I manage to built the new code I will run a test game through --
I've never managed to get to the CGR operation yet.

Does Rails enforce the rule about "the CGRs token does not move
normally until it has a permanent train"?

 - Aliza

Re: [Rails-devel] 1856 bridge/tunnel tokens

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

OK, 1856 now has a new "Unlimited bonus tokens" game option. 
The default remains "no", which is also applied if older saved 
files are loaded, in which the choice for this option does not 
yet exist.

Train buying is never enforced (that was a recent change), but
in my interpretation of the rules, the CGR would be required
to exchange the 4-train in this case. But indeed the rules are 
silent on this matter.
A question in the 18xx Yahoo group might get you a more
authoritive answer.

I found and fixed another bug: if the CGR had excess trains so
that it would need to discard any 4-trains, it actually discarded
all 4-trains. 

Erik.

-----Original Message-----
From: Aliza Panitz [mailto:ali...@gm...] 
Sent: Saturday 26 December 2009 21:51
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856 bridge/tunnel tokens

A choice would be wonderful.

Speaking of 1856 rules that are subject to interpretation, it is not
at all clear whether the CGR is required to upgrade a 4-train to a
Diesel if it has the money to do so, and no permanent train. There are
strong opinions in both directions.  (I was trying to run a hotseat
1856 through to this point in the game to verify which way Rails went,
but I've never managed to have a game that got past the CGR formation
without running into a fatal bug...)

On Sat, Dec 26, 2009 at 5:48 AM, Erik Vos <eri...@xs...> wrote:
> Any opinions on this matter?
>
> I could
> (1) allow infinite token buys, or
> (2) add a game option to select between 3 and infinite, or
> (3) leave it as is.
>
> Erik.

----------------------------------------------------------------------------
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] How to check out the code from CVS (was: 1856: CGR Formation stalls when keeping all trains)

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

It's even easier than that.

1. Download/Install Eclipse from http://www.eclipse.org/downloads/ ;
You'll want the "Eclipse IDE for Java Developers".
2. In Eclipse, select File > New > Project
3. Select Projects from CVS.
4a. If you have a sourceforge.net login, use these settings:

Host: rails.cvs.sourceforge.net
Repository Path: /cvsroot/rails
Connection Type:  extssh

User and Password should be self-explanatory.

4b. If you don't have a sourceforge.net login, the only difference are
these two things:

Connection Type: pserver
User: anonymous


This should check out the current codebase from CVS.

Once you've got that, you can right-click on the project folder (or
click the Run menu), and select Run As, and select Java Application.
It should try to locate the main() method to run.  The one you want is
in rails.util.RunGame.


---Brett.



On Sun, Dec 27, 2009 at 3:05 PM, Erik Vos <eri...@xs...> wrote:
> Aliza,
>
> I have trimmed the save file, which I'll send separately to your private
> mail address.
> It now works with the new code base, giving the CGR its first turn.
>
> To run Rails from the code base, you should
> 1. Download the entire code tree as stored on Sourceforge,
> 2. Install Eclipse,
> 3. Create a new project from the downloaded source,
> 4. Create a Run entry for Rails.
> None of this is very difficult, I could help if needed.
> Otherwise, you'll have to wait for the next release, which I suppose will
> not take long.
>
> Erik.
>
> -----Original Message-----
> From: Aliza Panitz [mailto:ali...@gm...]
> Sent: Sunday 27 December 2009 21:15
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856: CGR Formation stalls when keeping all
> trains
>
> Erik:
>
> I'm glad that my playtesting is useful!
>
> The only earlier savefile I have from this game is quite a bit
> earlier, when I saved the session to file a bug report on buying
> tunnel tokens after the first 5-train was bought. That's file
> 1856_20091224_2344-lps-cant-buy-tunnel-token.rails attached to my bug
> report from Dec. 24th.
>
> Clearly I'm used to different play styles than you are, as the CGR
> almost never drops its 4-trains in my experience. (However, I find it
> quite difficult to play "fair" with my imaginary friends, so my test
> games do develop a bit oddly at times.  )
>
> I'd be glad to play forward with your fixes, but I don't have a Java
> build environment on my laptop.  (I've never programmed anything in
> Java, and haven't done anything but shell and Perl scripts in quite a
> few years.)
>
>  - Aliza
>
> On Sun, Dec 27, 2009 at 10:45 AM, Erik Vos <eri...@xs...> wrote:
>> You're really good at finding bugs in untested dark corners
>> (i.e. special combinations of circumstances that have escaped
>> everyone's attention so far... :-)
>>
>> This time there were two:
>>
>> 1. If CGR did not discard a non-permanent train when offered
>> the chance to do so, the player action did not close that step,
>> i.e. the program started repeatedly asking the same question.
>>
>> 2. If, after CGR formation, all of the remaining companies
>> already have operated, the current OR must be finished and
>> a new OR must be started. That is what happened, but the
>> whole complex sequence of steps was incorrectly wrapped up,
>> so that in fact the old OR was trying to continue with a
>> company that already had been closed (in this case, the GT).
>>
>> I have uploaded fixes. However, your saved file still cannot
>> be processed because it contains a large sequence of DiscardTrain
>> actions, where only one is now expected by the fixed code.
>>
>> Do you still have a saved file from an earlier time?
>>
>> I am considering building a tool that would enable fixing
>> such unprocessible save files by removing invalid *trailing*
>> actions, but that may take a bit of time.
>>
>> Erik.
>>
>> -----Original Message-----
>> From: Aliza Panitz [mailto:ali...@gm...]
>> Sent: Friday 25 December 2009 02:18
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] 1856: CGR Formation stalls when keeping all
>> trains
>>
>> The savefile is too big, so my message is being held for moderator
> approval.
>>
>> On Thu, Dec 24, 2009 at 5:14 PM, Aliza Panitz <ali...@gm...>
>> wrote:
>>> Attached is a savefile from a game where the CGR forms with a 4 and
>>> two 5 trains.  Rails will not let me keep all three trains, although
>>> the CGR has a train limit of 3.
>>>
>>> Even if I discard a train, there doesn't appear to be a "done" button
>>> to let me proceed with play.
>>>
>>> I will also mention that having the map disappear as people are being
>>> asked to decide about CGR formation is quite disconcerting, as map
>>> position can be a factor in deciding whether or not to keep a
>>> struggling company. (There was no way to bring it back up.)
>>>
>>> I saved and reloaded the game, but it still appears to be stuck.
>>>
>>>  - Aliza
>>>
>>
>>
> ----------------------------------------------------------------------------
>> --
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and
> easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and
> easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
> ----------------------------------------------------------------------------
> --
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1856: CGR Formation stalls when keeping all trains

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

Aliza,

I have trimmed the save file, which I'll send separately to your private
mail address.
It now works with the new code base, giving the CGR its first turn. 

To run Rails from the code base, you should
1. Download the entire code tree as stored on Sourceforge,
2. Install Eclipse,
3. Create a new project from the downloaded source,
4. Create a Run entry for Rails.
None of this is very difficult, I could help if needed.
Otherwise, you'll have to wait for the next release, which I suppose will
not take long.

Erik. 

-----Original Message-----
From: Aliza Panitz [mailto:ali...@gm...] 
Sent: Sunday 27 December 2009 21:15
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856: CGR Formation stalls when keeping all
trains

Erik:

I'm glad that my playtesting is useful!

The only earlier savefile I have from this game is quite a bit
earlier, when I saved the session to file a bug report on buying
tunnel tokens after the first 5-train was bought. That's file
1856_20091224_2344-lps-cant-buy-tunnel-token.rails attached to my bug
report from Dec. 24th.

Clearly I'm used to different play styles than you are, as the CGR
almost never drops its 4-trains in my experience. (However, I find it
quite difficult to play "fair" with my imaginary friends, so my test
games do develop a bit oddly at times.  )

I'd be glad to play forward with your fixes, but I don't have a Java
build environment on my laptop.  (I've never programmed anything in
Java, and haven't done anything but shell and Perl scripts in quite a
few years.)

 - Aliza

On Sun, Dec 27, 2009 at 10:45 AM, Erik Vos <eri...@xs...> wrote:
> You're really good at finding bugs in untested dark corners
> (i.e. special combinations of circumstances that have escaped
> everyone's attention so far... :-)
>
> This time there were two:
>
> 1. If CGR did not discard a non-permanent train when offered
> the chance to do so, the player action did not close that step,
> i.e. the program started repeatedly asking the same question.
>
> 2. If, after CGR formation, all of the remaining companies
> already have operated, the current OR must be finished and
> a new OR must be started. That is what happened, but the
> whole complex sequence of steps was incorrectly wrapped up,
> so that in fact the old OR was trying to continue with a
> company that already had been closed (in this case, the GT).
>
> I have uploaded fixes. However, your saved file still cannot
> be processed because it contains a large sequence of DiscardTrain
> actions, where only one is now expected by the fixed code.
>
> Do you still have a saved file from an earlier time?
>
> I am considering building a tool that would enable fixing
> such unprocessible save files by removing invalid *trailing*
> actions, but that may take a bit of time.
>
> Erik.
>
> -----Original Message-----
> From: Aliza Panitz [mailto:ali...@gm...]
> Sent: Friday 25 December 2009 02:18
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856: CGR Formation stalls when keeping all
> trains
>
> The savefile is too big, so my message is being held for moderator
approval.
>
> On Thu, Dec 24, 2009 at 5:14 PM, Aliza Panitz <ali...@gm...>
> wrote:
>> Attached is a savefile from a game where the CGR forms with a 4 and
>> two 5 trains.  Rails will not let me keep all three trains, although
>> the CGR has a train limit of 3.
>>
>> Even if I discard a train, there doesn't appear to be a "done" button
>> to let me proceed with play.
>>
>> I will also mention that having the map disappear as people are being
>> asked to decide about CGR formation is quite disconcerting, as map
>> position can be a factor in deciding whether or not to keep a
>> struggling company. (There was no way to bring it back up.)
>>
>> I saved and reloaded the game, but it still appears to be stuck.
>>
>>  - Aliza
>>
>
>
----------------------------------------------------------------------------
> --
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
----------------------------------------------------------------------------
--
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

----------------------------------------------------------------------------
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856: CGR Formation stalls when keeping all trains

[Aliza P. <ali...@gm...>]

Erik:

I'm glad that my playtesting is useful!

The only earlier savefile I have from this game is quite a bit
earlier, when I saved the session to file a bug report on buying
tunnel tokens after the first 5-train was bought. That's file
1856_20091224_2344-lps-cant-buy-tunnel-token.rails attached to my bug
report from Dec. 24th.

Clearly I'm used to different play styles than you are, as the CGR
almost never drops its 4-trains in my experience. (However, I find it
quite difficult to play "fair" with my imaginary friends, so my test
games do develop a bit oddly at times.  )

I'd be glad to play forward with your fixes, but I don't have a Java
build environment on my laptop.  (I've never programmed anything in
Java, and haven't done anything but shell and Perl scripts in quite a
few years.)

 - Aliza

On Sun, Dec 27, 2009 at 10:45 AM, Erik Vos <eri...@xs...> wrote:
> You're really good at finding bugs in untested dark corners
> (i.e. special combinations of circumstances that have escaped
> everyone's attention so far... :-)
>
> This time there were two:
>
> 1. If CGR did not discard a non-permanent train when offered
> the chance to do so, the player action did not close that step,
> i.e. the program started repeatedly asking the same question.
>
> 2. If, after CGR formation, all of the remaining companies
> already have operated, the current OR must be finished and
> a new OR must be started. That is what happened, but the
> whole complex sequence of steps was incorrectly wrapped up,
> so that in fact the old OR was trying to continue with a
> company that already had been closed (in this case, the GT).
>
> I have uploaded fixes. However, your saved file still cannot
> be processed because it contains a large sequence of DiscardTrain
> actions, where only one is now expected by the fixed code.
>
> Do you still have a saved file from an earlier time?
>
> I am considering building a tool that would enable fixing
> such unprocessible save files by removing invalid *trailing*
> actions, but that may take a bit of time.
>
> Erik.
>
> -----Original Message-----
> From: Aliza Panitz [mailto:ali...@gm...]
> Sent: Friday 25 December 2009 02:18
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856: CGR Formation stalls when keeping all
> trains
>
> The savefile is too big, so my message is being held for moderator approval.
>
> On Thu, Dec 24, 2009 at 5:14 PM, Aliza Panitz <ali...@gm...>
> wrote:
>> Attached is a savefile from a game where the CGR forms with a 4 and
>> two 5 trains.  Rails will not let me keep all three trains, although
>> the CGR has a train limit of 3.
>>
>> Even if I discard a train, there doesn't appear to be a "done" button
>> to let me proceed with play.
>>
>> I will also mention that having the map disappear as people are being
>> asked to decide about CGR formation is quite disconcerting, as map
>> position can be a factor in deciding whether or not to keep a
>> struggling company. (There was no way to bring it back up.)
>>
>> I saved and reloaded the game, but it still appears to be stuck.
>>
>>  - Aliza
>>
>
> ----------------------------------------------------------------------------
> --
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1856: CGR Formation stalls when keeping all trains

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

You're really good at finding bugs in untested dark corners 
(i.e. special combinations of circumstances that have escaped 
everyone's attention so far... :-)

This time there were two:

1. If CGR did not discard a non-permanent train when offered 
the chance to do so, the player action did not close that step, 
i.e. the program started repeatedly asking the same question.

2. If, after CGR formation, all of the remaining companies 
already have operated, the current OR must be finished and 
a new OR must be started. That is what happened, but the 
whole complex sequence of steps was incorrectly wrapped up,
so that in fact the old OR was trying to continue with a
company that already had been closed (in this case, the GT).

I have uploaded fixes. However, your saved file still cannot 
be processed because it contains a large sequence of DiscardTrain
actions, where only one is now expected by the fixed code.

Do you still have a saved file from an earlier time?

I am considering building a tool that would enable fixing
such unprocessible save files by removing invalid *trailing* 
actions, but that may take a bit of time.

Erik.

-----Original Message-----
From: Aliza Panitz [mailto:ali...@gm...] 
Sent: Friday 25 December 2009 02:18
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856: CGR Formation stalls when keeping all
trains

The savefile is too big, so my message is being held for moderator approval.

On Thu, Dec 24, 2009 at 5:14 PM, Aliza Panitz <ali...@gm...>
wrote:
> Attached is a savefile from a game where the CGR forms with a 4 and
> two 5 trains.  Rails will not let me keep all three trains, although
> the CGR has a train limit of 3.
>
> Even if I discard a train, there doesn't appear to be a "done" button
> to let me proceed with play.
>
> I will also mention that having the map disappear as people are being
> asked to decide about CGR formation is quite disconcerting, as map
> position can be a factor in deciding whether or not to keep a
> struggling company. (There was no way to bring it back up.)
>
> I saved and reloaded the game, but it still appears to be stuck.
>
>  - Aliza
>

----------------------------------------------------------------------------
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 

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

Re: [Rails-devel] 1856 bridge/tunnel tokens

[Aliza P. <ali...@gm...>]

A choice would be wonderful.

Speaking of 1856 rules that are subject to interpretation, it is not
at all clear whether the CGR is required to upgrade a 4-train to a
Diesel if it has the money to do so, and no permanent train. There are
strong opinions in both directions.  (I was trying to run a hotseat
1856 through to this point in the game to verify which way Rails went,
but I've never managed to have a game that got past the CGR formation
without running into a fatal bug...)

On Sat, Dec 26, 2009 at 5:48 AM, Erik Vos <eri...@xs...> wrote:
> Any opinions on this matter?
>
> I could
> (1) allow infinite token buys, or
> (2) add a game option to select between 3 and infinite, or
> (3) leave it as is.
>
> Erik.

Re: [Rails-devel] 1856 bridge/tunnel tokens

[Steve U. <ste...@gm...>]

Option 2 also seems the best to me.

Steve Undy
st...@ro...



On Sat, Dec 26, 2009 at 6:48 AM, Erik Vos <eri...@xs...> wrote:
> Any opinions on this matter?
>
> I could
> (1) allow infinite token buys, or
> (2) add a game option to select between 3 and infinite, or
> (3) leave it as is.
>
> Erik.
>
> -----Original Message-----
> From: Aliza Panitz [mailto:ali...@gm...]
> Sent: Friday 25 December 2009 01:06
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856 bridge/tunnel tokens
>
> Also, it appears that rails implements a hard limit of 3 bridge
> tokens.  This is a supportable reading of the rules, but it would be
> good to document this somewhere.  (Many people, and That Other 18xx
> Moderator, play with a rule that bridge and tunnel tokens are
> infinite.)
>
>  - Aliza
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1856 bridge/tunnel tokens

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

Game option seems best to me.

--
Chris

Please consider the environment before printing this e-mail.


On Sat, Dec 26, 2009 at 5:48 AM, Erik Vos <eri...@xs...> wrote:

> Any opinions on this matter?
>
> I could
> (1) allow infinite token buys, or
> (2) add a game option to select between 3 and infinite, or
> (3) leave it as is.
>
> Erik.
>
> -----Original Message-----
> From: Aliza Panitz [mailto:ali...@gm...]
> Sent: Friday 25 December 2009 01:06
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856 bridge/tunnel tokens
>
> Also, it appears that rails implements a hard limit of 3 bridge
> tokens.  This is a supportable reading of the rules, but it would be
> good to document this somewhere.  (Many people, and That Other 18xx
> Moderator, play with a rule that bridge and tunnel tokens are
> infinite.)
>
>  - Aliza
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1856 bridge/tunnel tokens

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

Any opinions on this matter?  

I could
(1) allow infinite token buys, or
(2) add a game option to select between 3 and infinite, or
(3) leave it as is.

Erik.

-----Original Message-----
From: Aliza Panitz [mailto:ali...@gm...] 
Sent: Friday 25 December 2009 01:06
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856 bridge/tunnel tokens

Also, it appears that rails implements a hard limit of 3 bridge
tokens.  This is a supportable reading of the rules, but it would be
good to document this somewhere.  (Many people, and That Other 18xx
Moderator, play with a rule that bridge and tunnel tokens are
infinite.)

 - Aliza

Re: [Rails-devel] 1856 bridge/tunnel tokens

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

Aliza,
Thanks for reporting this. I found there were quite some bugs in this area. 
These should now all be fixed.
Erik.

-----Original Message-----
From: Aliza Panitz [mailto:ali...@gm...] 
Sent: Friday 25 December 2009 01:06
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856 bridge/tunnel tokens

I have noticed all along that buying bridge/tunnel tokens had slightly
wrong text -- when company A buys a token from company B, the text
says "Buy token from company A".  However, the money moved correctly.

I'm attaching a savefile from a 1.1.1 game that is even worse -- the
bridge private was sold in to a major, but the tunnel company
evaporated with a 5 train.  I should be able to buy tunnel tokens from
the bank, but that is not shown as an option. I can still buy bridge
tokens with the money going to the company that formerly owned the
bridge private -- but the money should be going to the bank now.

The rule is:
If a player owns the bridge private, tokens may not be bought.
If a Company owns the bridge private, tokens may be bought, with money
going to the company
After the 5-train, tokens may be bought, with money going to the bank.

Re: [Rails-devel] 1856: report text for conditional float

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

Actually, the 1856 rules book doesn't even mention the 
concept of "floating", so it could also be argued that 
the "float" message should be removed entirely in 1856.

However, these messages come from a generic part of the code,
and some code restructuring will be needed to implement
either solution as a game-specific deviation. 

Technically, floating in Rails only means that the company
will be included in the list of companies that need be
considered in the Operating Rounds. Normally, they will operate,
only 1856 has this exception of an additional check to be
performed. A clear message is displayed if a company listed
in the OR window will not operate in 1856.

Although I fully agree that your remark makes sense, 
I'm not sure that this minor issue is worth the required
structural code changes. But I'll keep it in mind
as a potential improvement. To ensure that it's not forgotten
you might want to enter your request as a Feature Request 
on the Sourceforge Rails project site.

Erik.

-----Original Message-----
From: Aliza Panitz [mailto:ali...@gm...] 
Sent: Wednesday 23 December 2009 21:59
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856: report text for conditional float

nit-pick and feature request:

Report window, Rails 1.1.1 :
Joshua starts WR at $90 and pays $180 for 2 shares (20%) to WR
WR floats

This could be misleading to newer players of 1856.  WR will not
operate unless there is a 2-train available when its turn comes to
operate for the first time.

In 1856, companies float when 6 shares are sold, and they
provisionally float when as many shares have sold as the currently
available train. (Rails enforces this rule, I believe  correctly.)

Suggestion: change text to

Joshua starts WR at $90 and pays $180 for 2 shares (20%) to WR
WR provisionally floats

[...]
[Joshua buys his 6th share of a new railroad later in the game]
GW unconditionally floats

----------------------------------------------------------------------------
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856: CGR Formation stalls when keeping all trains

[Aliza P. <ali...@gm...>]

The savefile is too big, so my message is being held for moderator approval.

On Thu, Dec 24, 2009 at 5:14 PM, Aliza Panitz <ali...@gm...> wrote:
> Attached is a savefile from a game where the CGR forms with a 4 and
> two 5 trains.  Rails will not let me keep all three trains, although
> the CGR has a train limit of 3.
>
> Even if I discard a train, there doesn't appear to be a "done" button
> to let me proceed with play.
>
> I will also mention that having the map disappear as people are being
> asked to decide about CGR formation is quite disconcerting, as map
> position can be a factor in deciding whether or not to keep a
> struggling company. (There was no way to bring it back up.)
>
> I saved and reloaded the game, but it still appears to be stuck.
>
>  - Aliza
>

Re: [Rails-devel] 1856: CGR Formation stalls when keeping all trains

[Aliza P. <ali...@gm...>]

Attached is a savefile from a game where the CGR forms with a 4 and
two 5 trains.  Rails will not let me keep all three trains, although
the CGR has a train limit of 3.

Even if I discard a train, there doesn't appear to be a "done" button
to let me proceed with play.

I will also mention that having the map disappear as people are being
asked to decide about CGR formation is quite disconcerting, as map
position can be a factor in deciding whether or not to keep a
struggling company. (There was no way to bring it back up.)

I saved and reloaded the game, but it still appears to be stuck.

 - Aliza

Re: [Rails-devel] 1856 bridge/tunnel tokens

[Aliza P. <ali...@gm...>]

I have noticed all along that buying bridge/tunnel tokens had slightly
wrong text -- when company A buys a token from company B, the text
says "Buy token from company A".  However, the money moved correctly.

I'm attaching a savefile from a 1.1.1 game that is even worse -- the
bridge private was sold in to a major, but the tunnel company
evaporated with a 5 train.  I should be able to buy tunnel tokens from
the bank, but that is not shown as an option. I can still buy bridge
tokens with the money going to the company that formerly owned the
bridge private -- but the money should be going to the bank now.

The rule is:
If a player owns the bridge private, tokens may not be bought.
If a Company owns the bridge private, tokens may be bought, with money
going to the company
After the 5-train, tokens may be bought, with money going to the bank.

Also, it appears that rails implements a hard limit of 3 bridge
tokens.  This is a supportable reading of the rules, but it would be
good to document this somewhere.  (Many people, and That Other 18xx
Moderator, play with a rule that bridge and tunnel tokens are
infinite.)

 - Aliza

Re: [Rails-devel] 1856: report text for conditional float

[Aliza P. <ali...@gm...>]

nit-pick and feature request:

Report window, Rails 1.1.1 :
Joshua starts WR at $90 and pays $180 for 2 shares (20%) to WR
WR floats

This could be misleading to newer players of 1856.  WR will not
operate unless there is a 2-train available when its turn comes to
operate for the first time.

In 1856, companies float when 6 shares are sold, and they
provisionally float when as many shares have sold as the currently
available train. (Rails enforces this rule, I believe  correctly.)

Suggestion: change text to

Joshua starts WR at $90 and pays $180 for 2 shares (20%) to WR
WR provisionally floats

[...]
[Joshua buys his 6th share of a new railroad later in the game]
GW unconditionally floats