rails-devel — List for discussion of Rails development

[Rails-devel] Tile 4 missing revenue

[Phil D. <de...@gm...>]

I just logged 2928210 about tile 4 missing revenue both on the hover
and on the drawing of the tile itself.

I note that the Tiles.xml for each game does hold the revenue value
but I would imagine you build the tile set for each game using a
script or similar?  The tiles/TileDictionary.18t and .xml files both
seem to not have an attribute listing a value for the 4 tile granting
a revenue for the town.  I'm guessing one of these two files need
updating and then propagate changes from there?

Phil

[Rails-devel] Modality

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

I have managed to get a non-modal version of CheckBoxDialog to work.
This means, that the following popups no longer block all other windows:
- Reach Destinations (1856, under the Special menu),
- Exchange of non-home tokens during CGR formation.

The code has been committed and will be included in the upcoming new version
1.1.2, so you can check it out.

The other dialogs are standard modal ones and must be customized to get the
same effect; that will take more time.

Erik.

Re: [Rails-devel] Docs for new games?

[Rick W. <wes...@pu...>]

     Thanks for the advice Brett and Erik.  I should have said 
OpenOffice-compatible instead of Word-compatible.  More open that way.  
:-)    The advantage of HTML or OO/Word-format over plain text is the 
ability to use bold, different font sizes, etc.   Of course there are 
converter programs between formats.   I'll see what I end up using.  
Probably HTML.

-- 
Rick Westerman wes...@pu...

Re: [Rails-devel] Docs for new games?

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

Personally, I have no particular preference.
Word is fine, but not really open source.
HTML would be best if we can publish it on some web site,
not sure if that can be done on Sourceforge.

Brett, any suggestions?

Erik. 

-----Original Message-----
From: Rick Westerman [mailto:wes...@pu...] 
Sent: Wednesday 06 January 2010 19:50
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Docs for new games?

     Erik: Thanks for the specific options advice.  One more question.  
What format would you like docs in?  Word ... HTML ... text ... other?


-- 
Rick Westerman wes...@pu...

----------------------------------------------------------------------------
--
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] Docs for new games?

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

Depends on where you intend the docs to be viewed.

Anything that will just be in CVS alongside the code should be plain text.

Stuff intended to be posted to the web site can be HTML.

---Brett.



On Wed, Jan 6, 2010 at 10:50 AM, Rick Westerman <wes...@pu...> wrote:
>     Erik: Thanks for the specific options advice.  One more question.
> What format would you like docs in?  Word ... HTML ... text ... other?
>
>
> --
> Rick Westerman wes...@pu...
>
> ------------------------------------------------------------------------------
> 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] Docs for new games?

[Rick W. <wes...@pu...>]

     Erik: Thanks for the specific options advice.  One more question.  
What format would you like docs in?  Word ... HTML ... text ... other?


-- 
Rick Westerman wes...@pu...

Re: [Rails-devel] Docs for new games?

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

In some places the XML contains some documentation 
(mainly in some of the 1830 files) but unfortunately 
that's an exception rather than the rule.
For me it's easy: I look it up in the code. 
But I realize that we aren’t well prepared yet for 
other contributors to configure new games.

The alternative to <PoolPaysOut> is <IPOPaysOut> 
(in fact both can be present, although that never
happens in practice). Looking back at it now, 
I'd say that these items should have been moved into
the <Payout> tag that was introduced in a later version;
perhaps I'll do that at some point in time.

<LayCost>: there already is an alternative called
"distance", which is used in 1835. But the code to use
that value still has to be written.

Several more tags and values exist that aren't used yet, 
for instance the <Reach> and <Score> tags in Game.xml
under <TrainManager>, as well as the majorStops
attribute of <Train>.

Feel free to ask any more questions.

Erik.


-----Original Message-----
From: brett lentz [mailto:wak...@gm...] 
Sent: Wednesday 06 January 2010 19:14
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Docs for new games?

As with most small projects, the documentation is minimal and usually
out of date. ;-)

You're on the right track, the XML tends to be the best documentation
of existing features.  In general, the options that exist, are the
ones used by the XML already.  Any new features that we may need, will
need to be created.

If the games don't add any new game mechanics, they should be easy
additions. 18Kaas was fairly simple to add, as I recall, exactly
because we had 1830 working and it's just uses the 1830 rules on a
different map. So, if you compare the 1830 and 18Kaas XML, you should
be able to get an idea of how to add in other 1830-style games.

The other place to that documents what's possible is the various
ConfigureFromXML() methods within the code. Those methods handle the
XML parsing, and more or less define the things we're expecting to
find in the XML.

If you're interested in adding real documentation, it's definitely
something we'd love to have.

---Brett.



On Wed, Jan 6, 2010 at 9:50 AM, Rick Westerman <wes...@pu...> wrote:
>  From the small bit I did searching the archives I suspect that the
> answer to this question is a resounding "NO" but ... are there any docs
> on how to create a new game and especially the options available to
> modify the game's parameters?
>
>    I can certainly go through the existing games' xml files and try to
> figure out what needs to be placed where, but it would be handy to know
> what some of the options mean without have to parse the code.  For
> example, in the 'CompanyManager.xml'  there are options such as
> 'PoolPaysOut' -- which is clear but makes me wonder what other options
> are possible; e.g., 'PoolRetains' or just perhaps not including the
> 'PoolPaysOut' line is sufficient?  And in the 'LayCost' option there is
> a method.  The particular file I am looking at has the method
> 'sequence'.  Are there others available?  And so on.
>
>    If there is no such document then I will try to make one up as I
> create a couple of games.  BTW:  At the moment I am working on 1800 and
> 1876 -- these are some very simple 1830-style games which should not
> (knock on wood!) give too many config problems.
>
> TIA.
>
> --
> Rick Westerman wes...@pu...
>
>
----------------------------------------------------------------------------
--
> 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] Docs for new games?

[Rick W. <wes...@pu...>]

brett lentz wrote:
> ...
>
> If you're interested in adding real documentation, it's definitely
> something we'd love to have.
>
> -
    I'll see what I can do.   I am planning to "work hard" (as much as 
real-work, home-activities, and outside activities permit) on this for 
the next week and the will probably taper off after that.  The ultimate 
goal is to get some games working that we can play in the car on the way 
to ChatCon 8 days hence.  Yes, I know, last-minute-Rick here!   But if I 
can get excited about the 'rails' project then maybe, despite minimal 
Java skills, I might be able to contribute something useful.



-- 
Rick Westerman wes...@pu...

Re: [Rails-devel] Docs for new games?

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

As with most small projects, the documentation is minimal and usually
out of date. ;-)

You're on the right track, the XML tends to be the best documentation
of existing features.  In general, the options that exist, are the
ones used by the XML already.  Any new features that we may need, will
need to be created.

If the games don't add any new game mechanics, they should be easy
additions. 18Kaas was fairly simple to add, as I recall, exactly
because we had 1830 working and it's just uses the 1830 rules on a
different map. So, if you compare the 1830 and 18Kaas XML, you should
be able to get an idea of how to add in other 1830-style games.

The other place to that documents what's possible is the various
ConfigureFromXML() methods within the code. Those methods handle the
XML parsing, and more or less define the things we're expecting to
find in the XML.

If you're interested in adding real documentation, it's definitely
something we'd love to have.

---Brett.



On Wed, Jan 6, 2010 at 9:50 AM, Rick Westerman <wes...@pu...> wrote:
>  From the small bit I did searching the archives I suspect that the
> answer to this question is a resounding "NO" but ... are there any docs
> on how to create a new game and especially the options available to
> modify the game's parameters?
>
>    I can certainly go through the existing games' xml files and try to
> figure out what needs to be placed where, but it would be handy to know
> what some of the options mean without have to parse the code.  For
> example, in the 'CompanyManager.xml'  there are options such as
> 'PoolPaysOut' -- which is clear but makes me wonder what other options
> are possible; e.g., 'PoolRetains' or just perhaps not including the
> 'PoolPaysOut' line is sufficient?  And in the 'LayCost' option there is
> a method.  The particular file I am looking at has the method
> 'sequence'.  Are there others available?  And so on.
>
>    If there is no such document then I will try to make one up as I
> create a couple of games.  BTW:  At the moment I am working on 1800 and
> 1876 -- these are some very simple 1830-style games which should not
> (knock on wood!) give too many config problems.
>
> TIA.
>
> --
> Rick Westerman wes...@pu...
>
> ------------------------------------------------------------------------------
> 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
>

[Rails-devel] Docs for new games?

[Rick W. <wes...@pu...>]

 From the small bit I did searching the archives I suspect that the 
answer to this question is a resounding "NO" but ... are there any docs 
on how to create a new game and especially the options available to 
modify the game's parameters?  

    I can certainly go through the existing games' xml files and try to 
figure out what needs to be placed where, but it would be handy to know 
what some of the options mean without have to parse the code.  For 
example, in the 'CompanyManager.xml'  there are options such as 
'PoolPaysOut' -- which is clear but makes me wonder what other options 
are possible; e.g., 'PoolRetains' or just perhaps not including the 
'PoolPaysOut' line is sufficient?  And in the 'LayCost' option there is 
a method.  The particular file I am looking at has the method 
'sequence'.  Are there others available?  And so on.

    If there is no such document then I will try to make one up as I 
create a couple of games.  BTW:  At the moment I am working on 1800 and 
1876 -- these are some very simple 1830-style games which should not 
(knock on wood!) give too many config problems.

TIA.

-- 
Rick Westerman wes...@pu...

[Rails-devel] Patch: 18EU game notes fix

[Phil D. <de...@gm...>]

Very basic fix to the GamesList.xml that corrects the notes for 18EU
(they stated that mountain upgrade costs were not implemented yet -
which they are).

Phil

Re: [Rails-devel] Maintenance release?

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

Sounds good to me.

---Brett.



On Tue, Jan 5, 2010 at 1:04 PM, Erik Vos <eri...@xs...> wrote:
> By now I have fixed all of the real bugs and implemented several of the
> suggestions that came in since the previous release.
>
> Brett, if nothing else shows up this week, I would suggest to create a
> maintenance release 1.1.2 so that everybody can take advantage of all that.
>
> The next thing I'll work on, before getting on to other games, is trying to
> get around the modal dialogs that prevent people to do anything else than
> just answering to such dialogs. But that is not trivial stuff.
>
> 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
>

[Rails-devel] Maintenance release?

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

By now I have fixed all of the real bugs and implemented several of the
suggestions that came in since the previous release.

Brett, if nothing else shows up this week, I would suggest to create a
maintenance release 1.1.2 so that everybody can take advantage of all that.

The next thing I'll work on, before getting on to other games, is trying to
get around the modal dialogs that prevent people to do anything else than
just answering to such dialogs. But that is not trivial stuff.

Erik.

Re: [Rails-devel] Creating patches/commits

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

Anyone can send patches to the mailing list.  If they look good, we'll
apply them to the cvs tree.

Frequent patch submission will earn you access to commit directly, if
you want it.

---Brett.



On Tue, Jan 5, 2010 at 9:12 AM, Phil Davies <de...@gm...> wrote:
> How do you handle changes or submissions to the codebase?  I've
> noticed that the game notes for 18EU are incorrect since they say that
> the mountain tile upgrade costs are not implemented yet, when as far
> as I can tell (through looking at code and by playing to that stage)
> they are working fine.
>
> Seems pointless creating a bug for something so quick to fix, I'll go
> and poke it myself but didn't really know how you handle code control.
>  Just create a patch and send it to someone for approval or request
> access for direct commit (seems dangerous to me!)
>
> I'm keen to help out in whatever small way I can :)
>
> Phil Davies
>
> ------------------------------------------------------------------------------
> 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
>

[Rails-devel] Creating patches/commits

[Phil D. <de...@gm...>]

How do you handle changes or submissions to the codebase?  I've
noticed that the game notes for 18EU are incorrect since they say that
the mountain tile upgrade costs are not implemented yet, when as far
as I can tell (through looking at code and by playing to that stage)
they are working fine.

Seems pointless creating a bug for something so quick to fix, I'll go
and poke it myself but didn't really know how you handle code control.
 Just create a patch and send it to someone for approval or request
access for direct commit (seems dangerous to me!)

I'm keen to help out in whatever small way I can :)

Phil Davies

Re: [Rails-devel] 1856 CGR Diesel upgrades

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

   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 company row in GameStatus is now immediately made invisible if a
company is closed.
  If there is any interest for, it would be easy to add a menu item to
show/hide rows of closed companies.

This now also applies to the OR/Map window.

Erik.

[Rails-devel] Save now also possible at game start

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

Games can now also be saved at game start, as appears to be useful for PBEM
play.
This fixes the first half of bug report #2923608.

The second half is unrelated and has been copied to a new bug report
#2924585.
This is about modal dialogs that must be reponded to by a different player
than the one who did the last move.
For PBEM play it would be useful if a Save would be possible in between.
However, that requires the invention of a non-modal way to get prompts
answered, which doesn't yet exist in Rails.
(This problem therefore IS closely related to the map visibility problem
during the CGR formation, as discussed a few days ago).

Erik.

Re: [Rails-devel] 1856 CGR Diesel upgrades

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

   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 company row in GameStatus is now immediately made invisible if a company
is closed.
If there is any interest for, it would be easy to add a menu item to
show/hide rows of closed companies.

Erik.

Re: [Rails-devel] 1856 CGR Diesel upgrades

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

   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.

Fixed.

Re: [Rails-devel] Fixes

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

    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?

I have added code to prevent CGR from buying 4-trains. 
But I don't have a working test case yet, so I can't confirm that it works. 


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

  The map now remains visible, but it still cannot be raised because
  the dialogs are modal. I'll see if it's doable to create nonmodal
  dialogs (unfortunately this is not a matter of just switching 
  a toggle; it requires custom dialogs to be written).

I have tried to make the token exchange popup (which is already 
a custom JDialog) nonmodal, but I can't get it working, despite 
trying to follow some examples found via Google. If anyone can 
show me a non-modal JDialog subclass that works, I'd be grateful.

The map now is set on top of other windows during the token
exchange dialog, so the it can be viewed, but not scrolled.


Erik.

Re: [Rails-devel] 1856 CGR Diesel upgrades

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

Oh.  Guess I'm wrong then.  Sorry for any confusion.

--
Chris

Please consider the environment before printing this e-mail.


On Tue, Dec 29, 2009 at 12:51 PM, Erik Vos <eri...@xs...> wrote:

>  Here I disagree.
> The third paragraph on page 24 of the rules is very clear on this point:
> "Until the CGR has a permanent train ... its token on the stock market is
> not adjusted from its starting position for any reason..."
>
>  ------------------------------
> *From:* Chris Shaffer [mailto:chr...@gm...]
> *Sent:* Tuesday 29 December 2009 21:42
> *To:* Development list for Rails: an 18xx game
> *Subject:* Re: [Rails-devel] 1856 CGR Diesel upgrades
>
>   > 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.
>>
>
> Oh, right, b should be an option too.  I played once where the CGR stock
> price was only frozen if it was running a borrowed train.  Seems a
> reasonable interpretation of the rules to me.
>
> --
> Chris
>
>
>
> ------------------------------------------------------------------------------
> 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

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

Here I disagree.
The third paragraph on page 24 of the rules is very clear on this point:
"Until the CGR has a permanent train ... its token on the stock market is
not adjusted from its starting position for any reason..."


  _____  

From: Chris Shaffer [mailto:chr...@gm...] 
Sent: Tuesday 29 December 2009 21:42
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856 CGR Diesel upgrades



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



Oh, right, b should be an option too.  I played once where the CGR stock
price was only frozen if it was running a borrowed train.  Seems a
reasonable interpretation of the rules to me.

--
Chris 

Re: [Rails-devel] 1856 CGR Diesel upgrades

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

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

Oh, right, b should be an option too.  I played once where the CGR stock
price was only frozen if it was running a borrowed train.  Seems a
reasonable interpretation of the rules to me.

--
Chris

Re: [Rails-devel] 1856 CGR Diesel upgrades

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

On Tue, Dec 29, 2009 at 12:16 PM, John David Galt
<jd...@di...> wrote:
>>> John David Galt 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).
>
>> Erik Vos wrote:
>>> 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.
>
> brett lentz wrote:
>> 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.
>
> I don't buy it.  I believe this special "repayment round" has player
> turns, not company turns.
>

Ah ha.  I see where I was confused.  You're talking about loan
repayment during CGR formation, not loan repayment in general.  My
mistake.

Yeah, in that case, I do agree... Loan repayment during CGR formation
goes player-by-player, not company-by-company. It's a special case.

I suspect we need two types of loan repayment classes. One for normal
play (during the course of a company's turn during an OR), and one for
government-run company formation (which happens outside the normal OR
turn sequence).

---Brett.

Re: [Rails-devel] 1856 CGR Diesel upgrades

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

>> John David Galt 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).

> Erik Vos wrote:
>> 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.

brett lentz wrote:
> 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.

I don't buy it.  I believe this special "repayment round" has player
turns, not company turns.