rails-devel — List for discussion of Rails development

Re: [Rails-devel] Bug fix for train exchange

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

Question to Erik:

There was even a TODO comment inside the BuyTrain action:
               trainsForExchangeUniqueIds[i] = trains.get(i).getName();
                // TODO: Must be replaced by unique Ids

It was not the important line (that is the one which defines the 
exchangedTrainUniqueId variable).
But still any reason why you have used getName() at the time of 
implementation?


[EV] Don't remember that. Obvious possibilities:

1. It might have enabled me to reuse old saved files.
2. For some reason I might have thought this change required more thought -
and then forgot about it.
3. Overlooked this case when introducing uniqueIds.

Anyway, fine that you have spotted and fixed this one. 
By now I'd say that we should not worry too much about old saved files any
more, in particular with 1835.

Erik.

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo duringCGRformation hangs game

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

Stefan,

Thanks for your analysis. Yes, I agree that Rails should be further hardened
in the aspects you mentioned.
Anyway, I think I'll remain in bug-fixing-and-hardening mode for some time!

Erik. 

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Wednesday 23 June 2010 23:35
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo duringCGRformation
hangs game

Erik,
I agree that Baden is more obvious case/bug and thus easier to fix and 
identify. In that case only the ordering of a stack/list was not observed 
during undoing or transfer. Thus it was for example to the fix of the 
PriceTokenMove, where the stack order is stored and allows the undo to 
preserve the previous ordering.

The case from Aliza's savefile is less obvious, much more tricky, as it has
to 
combine several conditions to create the problem. 

In that case three major ingredients are involved:
1) Actions on interchangeable objects
2) The first action stores only the object property, whereas the other
action 
stores the object id
3) Undoing the first action and redoing it, chooses a different object

Your suggestion will only work if the first action chooses the object in a 
deterministic way (thus for example from an ArrayList). However the
portfolio 
class contains some HashMaps and on the first glance I suspect that in some 
cases actions retrieve their objects from those non-deterministic 
collections. In that case this has to be replaced by an ordered collection, 
before the undo mechanism makes sense.

My take is to try to learn from that and try to build several layers of 
protection:

A) Everything in Rails that changes any state should work deterministically.

This includes cases that operate on objects, which are interchangable (like 
share certificates, trains, tokens, tiles).
For non-interchangable object this already a prerequisite for the automated 
testing. 

B) Interchangable objects should be identified by an identifiers. Actions 
working on those should use those identifiers instead of the object 
properties. (Thus do not store selling 20%, but which certificates exactly).

This also helps in the case of certificates with different share values.

C) Undo of actions should keep the ordering of objects, including the
ordering 
of interchangable objects.

Another idea might be to store the undo actions in the save files and replay

those after the reload.

All this is not done in one step and requires a deeper code review, but I 
suspect that similar problem might be responsible for some of the
unaccounted 
broken save files. Obeying rule B) might also required breaking the save
file 
compatibility, so this might be a good task for Rails 2.0?

Stefan

On Wednesday 23 June 2010 21:39:42 Erik Vos wrote:
> Stefan,
>
> Superficially the Baden issue looks similar. The problem there was that a
> buy from IPO always took the top share. Undo does mix up the share order,
> but another problem was even worse: moving the Baden shares from
> Unavailable to IPO reverses the share order!
>
> I have fixed the Baden case by giving all certificates a sequence number
> (index) per company, and checking that a buy from the IPO always takes the
> one with the lowest index. This makes at least IPO buy actions independent
> of the list order.
>
> >From a first glance to Aliza's problem I'm not sure how far the above can
>
> explain that issue. If I'm right, problems have also been reported about
> token order errors after Undo. Perhaps we should think about ways to make
> Undo exactly restore any previous list order, for instance by recording
the
> old list index in the Move.
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Sunday 20 June 2010 20:11
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during
> CGRformation hangs game
>
> Erik:
> some follow up on the issue with the broken save file in Aliza's bug
> report: As I had the hope I could easily make the file at least
reloadable,
> I believe
> I found a trace to the potential problem:
>
> The save file breaks at the following action:
> Action 378 delft: SellShares: 1 of 10% CPR at $110 apiece
>
> But delft should still have the share, as he bought CPR twice before (at
> actions 238, 244) and sold only once (action 323).
>
> The problematic action is the following:
> Action 330 azure: BuyCertificate: CPR 10% share from Pool price=$110
>
> which gets executed on the reload as:
> 2010-06-20 19:58:33 DEBUG  Action (azure): BuyCertificate: CPR 10% share
> from
> Pool price=$110
> 2010-06-20 19:58:33 DEBUG  >>> Start MoveSet(index=330)
> 2010-06-20 19:58:33 INFO   azure buys a 10% share of CPR from delft for
> $110.
> 2010-06-20 19:58:33 DEBUG  Done: Move PublicCertificate: CPR 10% share
from
> delft to azure
>
> Thus Rails assume that the certificate bought stems from delf instead from
> the
> Pool! It seems that action does not correctly identify the certificate
> bought. I checked that this is defined by the certificate ids.
>
> Thus I guess, that due to some undo the stack of certificates got mixed,
> either those in the IPO or in the possession of Delft (similar to the
Baden
> issue in 1835). Thus in the game played the other certificate in the
> possession of Delft was sold to the Pool in 323 and then on the reload
> Rails
>
> moves the wrong one out of Delft portfolio at action 330 instead getting
> that
> out of the Pool.
>
> I hope this is of some help, however I do not know how to resolve that
> issue
>
> easily, as I do not know, what is required to keep the ordering of
> certificates in portfolios "undo-robust". It might be the better solution
> in
>
> the long run to identify the certificates by their properties (thus share
> percentage and previous owner) and be agnostic about which one exactly to
> take.
>
> At least one should check that the current owner of the certificate is
> identical to the previous owner implied by the action, but this does not
> fix
>
> the reload problem.
>
> I have attached two trimmed save files, one before and one after the error
> occurs.
>
> Stefan
>
> On Sunday 20 June 2010 14:54:55 Stefan Frey wrote:
> > Aliza:
> > thanks for the savefile.
> > Most of the issues have to be addressed by Erik, but for the revenue
> >
> > calculation I can give some feedback:
> > > (1)  When I undo a tile lay and do something else, the route is not
> > > recalculated.  If I don't pay attention and calculate manually, I get
> > > the run from the previous OR.
> >
> > Unfortunately I cannot recreate the issue you report here:
> > I have the same problem with reloading the file, thus I wonder if the
>
> issue
>
> > occured anytime during the game or only at the specific time you
>
> originally
>
> > saved the game?
> >
> > Do you remember what was the case (but I fear some questions are too
> > detailed):
> >
> > - You were in the revenue phase already, did undo and went to lay tile
> > directly (as the company did not have any token)? Or have you done twice
>
> an
>
> > undo? Was a special tile lay of a private company involved? Which
company
> > was operating?
> >
> > - After undoing, did the revenue run disappear (as it should)?
> >
> > - Did the system calculate the revenue run (thus you got the messagebox
> > with the run), but did not take the new (different) tile lay into
> > account?
> >
> > - Or did simply nothing happened at all, thus the old revenue value was
> > still entered?
> >
> > I was able to confuse the tile/token laying mechansim by undos somehow,
>
> but
>
> > even in those cases the revenue calculation still worked. But maybe
> > fixing those errors might fix the (potentially missing) activation of
the
> > revenue calculation as well. I will look into that.
> >
> > Stefan
>
>
---------------------------------------------------------------------------
>
> >--- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > lucky parental unit.  See the prize list and enter to win:
> > http://p.sf.net/sfu/thinkgeek-promo
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
---------------------------------------------------------------------------
>--- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel



----------------------------------------------------------------------------
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Prussian token lays

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

The Prussian home base is Berlin, the original home of the M2 minor.
However, this is not yet specified in the XML, so that could be the cause of
your problem.
I'll sort it out!

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Friday 25 June 2010 10:44
To: Development list for Rails: an 18xx game
Subject: [Rails-devel] Prussian token lays

Where is the Prussians home base for the calculation of token lays?

Currently rails doesn't let the Pr lay a token (the option is provided
but clicking the button does nothing) but I wondered how the cost for
Pr tokens is calculated.  I cannot find this clarified in the rules.

Phil

----------------------------------------------------------------------------
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Improvements to the UI functions

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

Question to Erik here:
>From the Scale class it seems that the scale is 15 and then rescaled
depending 
on the screen resolution, as soon as the Scale class is setup
But that  is overwritten by a call from MapPanel:
Scale.set(16);
which overwrites that with 16 and no rescaling is done.
Is that the true intention or is this a code artifact?

[EV] I'm not sure, it is Brett who wrote the initial Map UI including this
Scale class. 
I suppose it was an initial attempt to scaling that might in fact have been
superceded by later developments.
It might also have been a heritage from Colossus, where Brett derived his
initial code from.

I'd say that by now Scale is redundant.

Erik.

[Rails-devel] Prussian token lays

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

Where is the Prussians home base for the calculation of token lays?

Currently rails doesn't let the Pr lay a token (the option is provided
but clicking the button does nothing) but I wondered how the cost for
Pr tokens is calculated.  I cannot find this clarified in the rules.

Phil

[Rails-devel] Improvements to the UI functions

[Stefan F. (web.de) <ste...@we...>]

Not too exciting world-cup games invite to play around with the user 
interface. 

A) Auto-Scrolling
The map scrolls automatically to center the display on the route network
of the active company. Only done at the start of the tile laying step and only 
if the current zoom step requires scrolling.

Currently default on, but can be switched off in the my.properties-file:
map.autoscroll=no

Any opinion if this should be the default or is this too hectic? Another 
option is to add a similar function that does an auto-zoom (out), if the 
route network of the active company cannot be displayed in the current 
map panel. But this might be too obtrusive? And should it return to some 
standard zoomstep (but which?), when the next company starts operating?

B) Change of fonts for user interface possible
All settings done in my.properties

font.ui.scale allows to scale relative to the default (12pt)
font.ui.name allows to choose available fonts on the system
font.ui.style allows to switch between plain/bold style

This is done globally for all fonts used. It still requires some tweaks on 
some panels to accomodate large font sizes. 
The font sizes used on the map should also be handled separately in the 
future.

C) Game specific settings possible
The settings defined for the options above allow game specific overrides.
For this simply append the game name to the option.

Example:
font.ui.scale.18EU=0.8 
changes the font scale for 18EU only.

Another option defined is
map.zoomstep, which allows to initialize the zoomstep.

Here game specific settings are also helpful.

D) Refactoring of the HexMap classes
In the process of adding the options, I refactored the HexMap classes slightly 
to avoid some redundancies in the coordinate calculations. I also hope that 
this a remedy to some of the problems with the zoom function, which I 
observed regularely. If anyone experience any new problems with the map 
display, please report.

Question to Erik here:
From the Scale class it seems that the scale is 15 and then rescaled depending 
on the screen resolution, as soon as the Scale class is setup
But that  is overwritten by a call from MapPanel:
Scale.set(16);
which overwrites that with 16 and no rescaling is done.
Is that the true intention or is this a code artifact?

Stefan

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGRformation hangs game

[Stefan F. (web.de) <ste...@we...>]

Erik,
I agree that Baden is more obvious case/bug and thus easier to fix and 
identify. In that case only the ordering of a stack/list was not observed 
during undoing or transfer. Thus it was for example to the fix of the 
PriceTokenMove, where the stack order is stored and allows the undo to 
preserve the previous ordering.

The case from Aliza's savefile is less obvious, much more tricky, as it has to 
combine several conditions to create the problem. 

In that case three major ingredients are involved:
1) Actions on interchangeable objects
2) The first action stores only the object property, whereas the other action 
stores the object id
3) Undoing the first action and redoing it, chooses a different object

Your suggestion will only work if the first action chooses the object in a 
deterministic way (thus for example from an ArrayList). However the portfolio 
class contains some HashMaps and on the first glance I suspect that in some 
cases actions retrieve their objects from those non-deterministic 
collections. In that case this has to be replaced by an ordered collection, 
before the undo mechanism makes sense.

My take is to try to learn from that and try to build several layers of 
protection:

A) Everything in Rails that changes any state should work deterministically. 
This includes cases that operate on objects, which are interchangable (like 
share certificates, trains, tokens, tiles).
For non-interchangable object this already a prerequisite for the automated 
testing. 

B) Interchangable objects should be identified by an identifiers. Actions 
working on those should use those identifiers instead of the object 
properties. (Thus do not store selling 20%, but which certificates exactly). 
This also helps in the case of certificates with different share values.

C) Undo of actions should keep the ordering of objects, including the ordering 
of interchangable objects.

Another idea might be to store the undo actions in the save files and replay 
those after the reload.

All this is not done in one step and requires a deeper code review, but I 
suspect that similar problem might be responsible for some of the unaccounted 
broken save files. Obeying rule B) might also required breaking the save file 
compatibility, so this might be a good task for Rails 2.0?

Stefan

On Wednesday 23 June 2010 21:39:42 Erik Vos wrote:
> Stefan,
>
> Superficially the Baden issue looks similar. The problem there was that a
> buy from IPO always took the top share. Undo does mix up the share order,
> but another problem was even worse: moving the Baden shares from
> Unavailable to IPO reverses the share order!
>
> I have fixed the Baden case by giving all certificates a sequence number
> (index) per company, and checking that a buy from the IPO always takes the
> one with the lowest index. This makes at least IPO buy actions independent
> of the list order.
>
> >From a first glance to Aliza's problem I'm not sure how far the above can
>
> explain that issue. If I'm right, problems have also been reported about
> token order errors after Undo. Perhaps we should think about ways to make
> Undo exactly restore any previous list order, for instance by recording the
> old list index in the Move.
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Sunday 20 June 2010 20:11
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during
> CGRformation hangs game
>
> Erik:
> some follow up on the issue with the broken save file in Aliza's bug
> report: As I had the hope I could easily make the file at least reloadable,
> I believe
> I found a trace to the potential problem:
>
> The save file breaks at the following action:
> Action 378 delft: SellShares: 1 of 10% CPR at $110 apiece
>
> But delft should still have the share, as he bought CPR twice before (at
> actions 238, 244) and sold only once (action 323).
>
> The problematic action is the following:
> Action 330 azure: BuyCertificate: CPR 10% share from Pool price=$110
>
> which gets executed on the reload as:
> 2010-06-20 19:58:33 DEBUG  Action (azure): BuyCertificate: CPR 10% share
> from
> Pool price=$110
> 2010-06-20 19:58:33 DEBUG  >>> Start MoveSet(index=330)
> 2010-06-20 19:58:33 INFO   azure buys a 10% share of CPR from delft for
> $110.
> 2010-06-20 19:58:33 DEBUG  Done: Move PublicCertificate: CPR 10% share from
> delft to azure
>
> Thus Rails assume that the certificate bought stems from delf instead from
> the
> Pool! It seems that action does not correctly identify the certificate
> bought. I checked that this is defined by the certificate ids.
>
> Thus I guess, that due to some undo the stack of certificates got mixed,
> either those in the IPO or in the possession of Delft (similar to the Baden
> issue in 1835). Thus in the game played the other certificate in the
> possession of Delft was sold to the Pool in 323 and then on the reload
> Rails
>
> moves the wrong one out of Delft portfolio at action 330 instead getting
> that
> out of the Pool.
>
> I hope this is of some help, however I do not know how to resolve that
> issue
>
> easily, as I do not know, what is required to keep the ordering of
> certificates in portfolios "undo-robust". It might be the better solution
> in
>
> the long run to identify the certificates by their properties (thus share
> percentage and previous owner) and be agnostic about which one exactly to
> take.
>
> At least one should check that the current owner of the certificate is
> identical to the previous owner implied by the action, but this does not
> fix
>
> the reload problem.
>
> I have attached two trimmed save files, one before and one after the error
> occurs.
>
> Stefan
>
> On Sunday 20 June 2010 14:54:55 Stefan Frey wrote:
> > Aliza:
> > thanks for the savefile.
> > Most of the issues have to be addressed by Erik, but for the revenue
> >
> > calculation I can give some feedback:
> > > (1)  When I undo a tile lay and do something else, the route is not
> > > recalculated.  If I don't pay attention and calculate manually, I get
> > > the run from the previous OR.
> >
> > Unfortunately I cannot recreate the issue you report here:
> > I have the same problem with reloading the file, thus I wonder if the
>
> issue
>
> > occured anytime during the game or only at the specific time you
>
> originally
>
> > saved the game?
> >
> > Do you remember what was the case (but I fear some questions are too
> > detailed):
> >
> > - You were in the revenue phase already, did undo and went to lay tile
> > directly (as the company did not have any token)? Or have you done twice
>
> an
>
> > undo? Was a special tile lay of a private company involved? Which company
> > was operating?
> >
> > - After undoing, did the revenue run disappear (as it should)?
> >
> > - Did the system calculate the revenue run (thus you got the messagebox
> > with the run), but did not take the new (different) tile lay into
> > account?
> >
> > - Or did simply nothing happened at all, thus the old revenue value was
> > still entered?
> >
> > I was able to confuse the tile/token laying mechansim by undos somehow,
>
> but
>
> > even in those cases the revenue calculation still worked. But maybe
> > fixing those errors might fix the (potentially missing) activation of the
> > revenue calculation as well. I will look into that.
> >
> > Stefan
>
> ---------------------------------------------------------------------------
>
> >--- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > lucky parental unit.  See the prize list and enter to win:
> > http://p.sf.net/sfu/thinkgeek-promo
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>--- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGRformation hangs game

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

Stefan,

Superficially the Baden issue looks similar. The problem there was that a
buy from IPO always took the top share. Undo does mix up the share order,
but another problem was even worse: moving the Baden shares from Unavailable
to IPO reverses the share order!

I have fixed the Baden case by giving all certificates a sequence number
(index) per company, and checking that a buy from the IPO always takes the
one with the lowest index. This makes at least IPO buy actions independent
of the list order.

>From a first glance to Aliza's problem I'm not sure how far the above can
explain that issue. If I'm right, problems have also been reported about
token order errors after Undo. Perhaps we should think about ways to make
Undo exactly restore any previous list order, for instance by recording the
old list index in the Move.

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Sunday 20 June 2010 20:11
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during
CGRformation hangs game

Erik:
some follow up on the issue with the broken save file in Aliza's bug report:
As I had the hope I could easily make the file at least reloadable, I
believe 
I found a trace to the potential problem:

The save file breaks at the following action:
Action 378 delft: SellShares: 1 of 10% CPR at $110 apiece

But delft should still have the share, as he bought CPR twice before (at 
actions 238, 244) and sold only once (action 323).

The problematic action is the following:
Action 330 azure: BuyCertificate: CPR 10% share from Pool price=$110

which gets executed on the reload as:
2010-06-20 19:58:33 DEBUG  Action (azure): BuyCertificate: CPR 10% share
from 
Pool price=$110
2010-06-20 19:58:33 DEBUG  >>> Start MoveSet(index=330)
2010-06-20 19:58:33 INFO   azure buys a 10% share of CPR from delft for
$110.
2010-06-20 19:58:33 DEBUG  Done: Move PublicCertificate: CPR 10% share from 
delft to azure

Thus Rails assume that the certificate bought stems from delf instead from
the 
Pool! It seems that action does not correctly identify the certificate 
bought. I checked that this is defined by the certificate ids.

Thus I guess, that due to some undo the stack of certificates got mixed, 
either those in the IPO or in the possession of Delft (similar to the Baden 
issue in 1835). Thus in the game played the other certificate in the 
possession of Delft was sold to the Pool in 323 and then on the reload Rails

moves the wrong one out of Delft portfolio at action 330 instead getting
that 
out of the Pool.

I hope this is of some help, however I do not know how to resolve that issue

easily, as I do not know, what is required to keep the ordering of 
certificates in portfolios "undo-robust". It might be the better solution in

the long run to identify the certificates by their properties (thus share 
percentage and previous owner) and be agnostic about which one exactly to 
take. 

At least one should check that the current owner of the certificate is 
identical to the previous owner implied by the action, but this does not fix

the reload problem.

I have attached two trimmed save files, one before and one after the error 
occurs. 

Stefan



On Sunday 20 June 2010 14:54:55 Stefan Frey wrote:
> Aliza:
> thanks for the savefile.
> Most of the issues have to be addressed by Erik, but for the revenue
>
> calculation I can give some feedback:
> > (1)  When I undo a tile lay and do something else, the route is not
> > recalculated.  If I don't pay attention and calculate manually, I get
> > the run from the previous OR.
>
> Unfortunately I cannot recreate the issue you report here:
> I have the same problem with reloading the file, thus I wonder if the
issue
> occured anytime during the game or only at the specific time you
originally
> saved the game?
>
> Do you remember what was the case (but I fear some questions are too
> detailed):
>
> - You were in the revenue phase already, did undo and went to lay tile
> directly (as the company did not have any token)? Or have you done twice
an
> undo? Was a special tile lay of a private company involved? Which company
> was operating?
>
> - After undoing, did the revenue run disappear (as it should)?
>
> - Did the system calculate the revenue run (thus you got the messagebox
> with the run), but did not take the new (different) tile lay into account?
>
> - Or did simply nothing happened at all, thus the old revenue value was
> still entered?
>
> I was able to confuse the tile/token laying mechansim by undos somehow,
but
> even in those cases the revenue calculation still worked. But maybe fixing
> those errors might fix the (potentially missing) activation of the revenue
> calculation as well. I will look into that.
>
> Stefan
>
>
>
>
---------------------------------------------------------------------------
>--- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Bug fix for train exchange

[Stefan F. (web.de) <ste...@we...>]

Starting to get an overview about the usage of ids versus types to identify
interchangable objects I realized that there is a bug still lingering in the 
wild: For a train exchange the id of the train exchanged was not saved, as it 
used the train(type) name instead of the unique id. Unfortunately this was 
not working.

I fixed that now, however: I suspect, that (at least in version 1.3) all games 
with a train exchange cannot be loaded beyond that point. At least a save 
file from my latest play of 1889 supports my assumption.

And I hope that there is no case where trains are selected by train type 
instead of train ids, as this could imply that a train which is somewhere 
else already gets exchanged (given an unfortunate sequence of undos).

Question to Erik:

There was even a TODO comment inside the BuyTrain action:
               trainsForExchangeUniqueIds[i] = trains.get(i).getName();
                // TODO: Must be replaced by unique Ids

It was not the important line (that is the one which defines the 
exchangedTrainUniqueId variable).
But still any reason why you have used getName() at the time of 
implementation?

Stefan

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR formation hangs game

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

On 21 June 2010 18:36, Stefan Frey <ste...@we...> wrote:
> The reason is a combination of issues:
> 1) The BuyCertificates action stores certificate by id
> 2) The SellShares action only stores percentages sold
> 3) The Undoing of share moves does not keep the order of certificates


I discovered today in 1835 that if you are 1 below the cert limit,
rails will not let you purchase one of the 20% shares because it
thinks it is two certificates.  I suspect this is a similar sort of
issue.  It sounds like there are a few niggles where cert and share
are considered interchangeable which will lead to problems with games
where a cert can be more or less than 10% of a corp

Phil

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR formation hangs game

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

Erik:
Just some follow-up to the issue. I explain it with an example, as it 
might be an instructive case to remember for potential issues with the
undo-function in Rails.

This bug is easily reproducible under simplified conditions. I attach the save 
file for the example.

There are several steps involved (see example file)
A) Owner of AR (player David, owns 50%) sells a (single) certificate
B) Undo this action
C) Player A sells a (single) certificate again
D) Other player (Alice) buys that share from the pool
E) Save Game: 
Until then everything looks fine: David owns 40%. Alice owns 10%
F) Reload game: 
Now David owns only 30%, Alice owns 10%, the Pool has 10%!

What happened internally: You have to be aware, that certificates are 
internally identified by ids. Assume that David has single certificates 
called AR-1 to AR-3.

A) David sells 10% certificate (assume that this is certificate AR-1)
B) Undo that action (now AR-1 comes to the bottom of his certificates)
C) David sells 10% again, but now this is certificate AR-2
D) Alice buys AR-2 from the pool
E) save only saves actions, which were not undone (thus actions C and D)
F) on the reload for C) AR-1 gets sold to the Pool, but in D) Alice still buys 
AR-2, but the previous owner is now not the Pool, but David!

The reason is a combination of issues:
1) The BuyCertificates action stores certificate by id
2) The SellShares action only stores percentages sold
3) The Undoing of share moves does not keep the order of certificates

By changing any of the three the problem can be solved.
The main issue is mixing addressing interchangeable objects once by ids and in 
the other case by type. This can only work, if evey selection by type works 
deterministically (thus never from unordered collections etc.) and the undo 
mechanism strictly restores the previous ordering.

Stefan



On Sunday 20 June 2010 20:11:06 Stefan Frey wrote:
> Erik:
> some follow up on the issue with the broken save file in Aliza's bug
> report: As I had the hope I could easily make the file at least reloadable,
> I believe I found a trace to the potential problem:
>
> The save file breaks at the following action:
> Action 378 delft: SellShares: 1 of 10% CPR at $110 apiece
>
> But delft should still have the share, as he bought CPR twice before (at
> actions 238, 244) and sold only once (action 323).
>
> The problematic action is the following:
> Action 330 azure: BuyCertificate: CPR 10% share from Pool price=$110
>
> which gets executed on the reload as:
> 2010-06-20 19:58:33 DEBUG  Action (azure): BuyCertificate: CPR 10% share
> from Pool price=$110
> 2010-06-20 19:58:33 DEBUG  >>> Start MoveSet(index=330)
> 2010-06-20 19:58:33 INFO   azure buys a 10% share of CPR from delft for
> $110. 2010-06-20 19:58:33 DEBUG  Done: Move PublicCertificate: CPR 10%
> share from delft to azure
>
> Thus Rails assume that the certificate bought stems from delf instead from
> the Pool! It seems that action does not correctly identify the certificate
> bought. I checked that this is defined by the certificate ids.
>
> Thus I guess, that due to some undo the stack of certificates got mixed,
> either those in the IPO or in the possession of Delft (similar to the Baden
> issue in 1835). Thus in the game played the other certificate in the
> possession of Delft was sold to the Pool in 323 and then on the reload
> Rails moves the wrong one out of Delft portfolio at action 330 instead
> getting that out of the Pool.
>
> I hope this is of some help, however I do not know how to resolve that
> issue easily, as I do not know, what is required to keep the ordering of
> certificates in portfolios "undo-robust". It might be the better solution
> in the long run to identify the certificates by their properties (thus
> share percentage and previous owner) and be agnostic about which one
> exactly to take.
>
> At least one should check that the current owner of the certificate is
> identical to the previous owner implied by the action, but this does not
> fix the reload problem.
>
> I have attached two trimmed save files, one before and one after the error
> occurs.
>
> Stefan
>
> On Sunday 20 June 2010 14:54:55 Stefan Frey wrote:
> > Aliza:
> > thanks for the savefile.
> > Most of the issues have to be addressed by Erik, but for the revenue
> >
> > calculation I can give some feedback:
> > > (1)  When I undo a tile lay and do something else, the route is not
> > > recalculated.  If I don't pay attention and calculate manually, I get
> > > the run from the previous OR.
> >
> > Unfortunately I cannot recreate the issue you report here:
> > I have the same problem with reloading the file, thus I wonder if the
> > issue occured anytime during the game or only at the specific time you
> > originally saved the game?
> >
> > Do you remember what was the case (but I fear some questions are too
> > detailed):
> >
> > - You were in the revenue phase already, did undo and went to lay tile
> > directly (as the company did not have any token)? Or have you done twice
> > an undo? Was a special tile lay of a private company involved? Which
> > company was operating?
> >
> > - After undoing, did the revenue run disappear (as it should)?
> >
> > - Did the system calculate the revenue run (thus you got the messagebox
> > with the run), but did not take the new (different) tile lay into
> > account?
> >
> > - Or did simply nothing happened at all, thus the old revenue value was
> > still entered?
> >
> > I was able to confuse the tile/token laying mechansim by undos somehow,
> > but even in those cases the revenue calculation still worked. But maybe
> > fixing those errors might fix the (potentially missing) activation of the
> > revenue calculation as well. I will look into that.
> >
> > Stefan
> >
> >
> >
> > -------------------------------------------------------------------------
> >-- --- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > lucky parental unit.  See the prize list and enter to win:
> > http://p.sf.net/sfu/thinkgeek-promo
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails under Win7 64-bit

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

Terry,

The batch file doesn't run under windows 7, it doesn't put Java on the path
for some reason.  If you double click the rails1-3.jar file, it should load
anyway.

Phil

On 21 June 2010 11:39, Terry Laven <tj_...@ya...> wrote:

> Hi I'm having trouble getting rails to run under Win7.   It runs
> beautifully on my VISTA laptop, but I get the error message-" 'java' is not
> recognized as an internal or external command, operable program or batch
> file".
>
> I have downloaded and installed the latest java runtime environment from
> Sun's website, and rebooted my PC.
>
> What am I missing?
>
> Thanks.   Really impressed with Rails - just saw it for first time
> yesterday.
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

[Rails-devel] Rails under Win7 64-bit

[Terry L. <tj_...@ya...>]

Hi I'm having trouble getting rails to run under Win7.   It runs beautifully on my VISTA laptop, but I get the error message-" 'java' is not recognized as an internal or external command, operable program or batch file".
 
I have downloaded and installed the latest java runtime environment from Sun's website, and rebooted my PC.
 
What am I missing?
 
Thanks.   Really impressed with Rails - just saw it for first time yesterday.


      

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR formation hangs game

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

Erik:
some follow up on the issue with the broken save file in Aliza's bug report:
As I had the hope I could easily make the file at least reloadable, I believe 
I found a trace to the potential problem:

The save file breaks at the following action:
Action 378 delft: SellShares: 1 of 10% CPR at $110 apiece

But delft should still have the share, as he bought CPR twice before (at 
actions 238, 244) and sold only once (action 323).

The problematic action is the following:
Action 330 azure: BuyCertificate: CPR 10% share from Pool price=$110

which gets executed on the reload as:
2010-06-20 19:58:33 DEBUG  Action (azure): BuyCertificate: CPR 10% share from 
Pool price=$110
2010-06-20 19:58:33 DEBUG  >>> Start MoveSet(index=330)
2010-06-20 19:58:33 INFO   azure buys a 10% share of CPR from delft for $110.
2010-06-20 19:58:33 DEBUG  Done: Move PublicCertificate: CPR 10% share from 
delft to azure

Thus Rails assume that the certificate bought stems from delf instead from the 
Pool! It seems that action does not correctly identify the certificate 
bought. I checked that this is defined by the certificate ids.

Thus I guess, that due to some undo the stack of certificates got mixed, 
either those in the IPO or in the possession of Delft (similar to the Baden 
issue in 1835). Thus in the game played the other certificate in the 
possession of Delft was sold to the Pool in 323 and then on the reload Rails 
moves the wrong one out of Delft portfolio at action 330 instead getting that 
out of the Pool.

I hope this is of some help, however I do not know how to resolve that issue 
easily, as I do not know, what is required to keep the ordering of 
certificates in portfolios "undo-robust". It might be the better solution in 
the long run to identify the certificates by their properties (thus share 
percentage and previous owner) and be agnostic about which one exactly to 
take. 

At least one should check that the current owner of the certificate is 
identical to the previous owner implied by the action, but this does not fix 
the reload problem.

I have attached two trimmed save files, one before and one after the error 
occurs. 

Stefan



On Sunday 20 June 2010 14:54:55 Stefan Frey wrote:
> Aliza:
> thanks for the savefile.
> Most of the issues have to be addressed by Erik, but for the revenue
>
> calculation I can give some feedback:
> > (1)  When I undo a tile lay and do something else, the route is not
> > recalculated.  If I don't pay attention and calculate manually, I get
> > the run from the previous OR.
>
> Unfortunately I cannot recreate the issue you report here:
> I have the same problem with reloading the file, thus I wonder if the issue
> occured anytime during the game or only at the specific time you originally
> saved the game?
>
> Do you remember what was the case (but I fear some questions are too
> detailed):
>
> - You were in the revenue phase already, did undo and went to lay tile
> directly (as the company did not have any token)? Or have you done twice an
> undo? Was a special tile lay of a private company involved? Which company
> was operating?
>
> - After undoing, did the revenue run disappear (as it should)?
>
> - Did the system calculate the revenue run (thus you got the messagebox
> with the run), but did not take the new (different) tile lay into account?
>
> - Or did simply nothing happened at all, thus the old revenue value was
> still entered?
>
> I was able to confuse the tile/token laying mechansim by undos somehow, but
> even in those cases the revenue calculation still worked. But maybe fixing
> those errors might fix the (potentially missing) activation of the revenue
> calculation as well. I will look into that.
>
> Stefan
>
>
>
> ---------------------------------------------------------------------------
>--- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR formation hangs game

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

Aliza:
thanks for the savefile. 
Most of the issues have to be addressed by Erik, but for the revenue 
calculation I can give some feedback:

> (1)  When I undo a tile lay and do something else, the route is not
> recalculated.  If I don't pay attention and calculate manually, I get
> the run from the previous OR.

Unfortunately I cannot recreate the issue you report here:
I have the same problem with reloading the file, thus I wonder if the issue 
occured anytime during the game or only at the specific time you originally 
saved the game?

Do you remember what was the case (but I fear some questions are too 
detailed):

- You were in the revenue phase already, did undo and went to lay tile 
directly (as the company did not have any token)? Or have you done twice an 
undo? Was a special tile lay of a private company involved? Which company was 
operating?

- After undoing, did the revenue run disappear (as it should)?

- Did the system calculate the revenue run (thus you got the messagebox 
with the run), but did not take the new (different) tile lay into account?

- Or did simply nothing happened at all, thus the old revenue value was still 
entered?

I was able to confuse the tile/token laying mechansim by undos somehow, but 
even in those cases the revenue calculation still worked. But maybe fixing 
those errors might fix the (potentially missing) activation of the revenue 
calculation as well. I will look into that.

Stefan

Re: [Rails-devel] 1835 playtest report - Rails 1.3

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

Erik:
to continue the discussion, see my comments / questions:

> The rule enforcing for tile laying in Rails has not changed (yet).
> Enforcement is on my list, but it requires a more drastic change of the
> current UI implementation. It will also consider the various approaches
> (permissive, restrictive, semi-restrictive), with the default set
> accordingly
> for each game.
>
> [EV] A permissive check would be easy to add. All that's needed is adding a
> call to a method that returns if a given track on a given hexside is part
> of a route (to be inserted in GUITile around line 115). The other
> approaches would require some more coding but need the same method call.

What currently stops me somehow from implementing it there is the more general 
question, if those validity checks should be part of the UI-code or better 
handled by the backend?
Most likely for the current implementation it does not matter, but in the 
longer run (at least for my understanding) the backend should provide the 
information about valid tile lays for the UI. This information should be 
passed to the UI via the action objects?
I have not searched the archive of the development for the issue of 
client/server separation exactly, so I do not know, what your planning there, 
but I would have guessed, that you prefer to have as much in the backend as 
possible.

But you are right: I can add a method to the algorithm package, which checks 
if a tile can be laid in any valid orientation on a specified hex, given the 
current network structure. Then this could be used either by the backend or 
the GUI to check the validitity. The only thing that might be different is 
the way to pass the handle to the networkgraph instance.

>
>
> [EV] I'm on (or under) Windows, but I don't have any such problem either.
> BTW I find the current tile description somewhat confusing. Someone
> (Stefan?) has added the number of remaining tiles, which is good, but the #
> sign in front of that is more commonly used to prefix the tile number, as
> it is done in the Remaining Tiles panel. I would have put the number of
> tiles in parentheses, as is also done to indicate the number of remaining
> trains.
>

That was me, it was first used only for the panel with the correction mode 
activated (to test the constraints). But players complained, that they would 
like to have that in the standard panel as well, I merged the code there.
And I remembered the usage of "#", but thought that would imply the number of 
remaining tiles , instead of the tile number (may be a Math deformation).
Can be easily changed to parentheses.


> The error popup on zero cash change is the standard implementation in
> Rails,
>
> if you select a non-valid parameter, as those checks are done by the
> backend.
> Sorry for trapping the game by this.
>
> [EV] Accepting 0 as a no-op should easily fix that.
>

You mean that a zero entered should leave the correction mode? This is 
difficult as the deactivation of the correction mode uses a different action, 
than the cash correction itself. But I could capture it by the UI already 
with a different message (for example, that you have to use the menu to 
deactivate), that is true.

Stefan

[Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR formation hangs game

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

The attached savefile is from a test game with 3 bugs, probably all
related to undo actions:

(1)  When I undo a tile lay and do something else, the route is not
recalculated.  If I don't pay attention and calculate manually, I get
the run from the previous OR.

(2) If I try an undo during CGR formation (Oh wait, I forgot to buy
the 5-train over...), the game hangs and cannot be continued.

The CGR ended up with 2 5-trains and 4 4-trains.The next company was
unable to lay a tile. ;-)

(3) The savefile in question, when I reload it, is complaining about
an illegal stock action in the round before the CGR formed.  Since I
started the game in Rails 1.3 and played it through without saving
until the CGR formed, I would expect any illegal stock move to have
been noticed earlier. ;-)

 - Aliza

Re: [Rails-devel] 1835 playtest report - Rails 1.3

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

Some comments inserted below.
Erik. 

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Friday 18 June 2010 00:37
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1835 playtest report - Rails 1.3

Hi John,
thanks a lot for the detailed report. 
Most issues were already addressed, but I would still like to add some
details 
for the parts I am responsible.

> But while that logic "knows" about route connections, the tile rotation
> logic doesn't.  That is, you're still allowed (and sometimes offered as
> first choice) the ability to place a new tile rotated so that it doesn't
> connect to your route.

You are right with your complain, the (current) highlighting only indicates 
the hexes were the route network has open ends.
The rule enforcing for tile laying in Rails has not changed (yet).
Enforcement is on my list, but it requires a more drastic change of the 
current UI implementation. It will also consider the various approaches 
(permissive, restrictive, semi-restrictive), with the default set
accordingly 
for each game. 

[EV] A permissive check would be easy to add. All that's needed is adding a
call to a method that returns if a given track on a given hexside is part of
a route (to be inserted in GUITile around line 115). The other approaches
would require some more coding but need the same method call. 


>
> Also, the controls to place a tile seem annoyingly finicky -- you have to
> click directly on the image of the tile you want to place, even though its
> description takes up a larger space that looks like a button.

The controls are those in the panel on the left to the map to select the 
tiles? On my system it is sufficient to click on the description and it 
neither takes up a larger space than the tile.
But I have a linux system, so my observation does not imply a lot.

[EV] I'm on (or under) Windows, but I don't have any such problem either.
BTW I find the current tile description somewhat confusing. Someone
(Stefan?) has added the number of remaining tiles, which is good, but the #
sign in front of that is more commonly used to prefix the tile number, as it
is done in the Remaining Tiles panel. I would have put the number of tiles
in parentheses, as is also done to indicate the number of remaining trains.


> I also tried out the "Cash Correction" mode just to see if it would help,
> and found that once you select it you can't cancel it without changing
> anything.  Entering zero gets you an error popup.
    
I admit that I deliberately decided to block the usual game actions as long
as 
(any) correction mode is active. My intention was to highlight that the 
actions available during correction allows the violation of game rules.
And I admit that I have not considered what happens if someone does not
figure 
out how to leave that mode. Maybe there should be some status bar, that 
indicates that you can leave the correction modes by deactivating them in
the 
menu.
The error popup on zero cash change is the standard implementation in Rails,

if you select a non-valid parameter, as those checks are done by the
backend. 
Sorry for trapping the game by this.

[EV] Accepting 0 as a no-op should easily fix that.

Re: [Rails-devel] 1835 playtest report - Rails 1.3

[Stefan F. (web.de) <ste...@we...>]

Hi John,
thanks a lot for the detailed report. 
Most issues were already addressed, but I would still like to add some details 
for the parts I am responsible.

> But while that logic "knows" about route connections, the tile rotation
> logic doesn't.  That is, you're still allowed (and sometimes offered as
> first choice) the ability to place a new tile rotated so that it doesn't
> connect to your route.

You are right with your complain, the (current) highlighting only indicates 
the hexes were the route network has open ends.
The rule enforcing for tile laying in Rails has not changed (yet).
Enforcement is on my list, but it requires a more drastic change of the 
current UI implementation. It will also consider the various approaches 
(permissive, restrictive, semi-restrictive), with the default set accordingly 
for each game. 

>
> Also, the controls to place a tile seem annoyingly finicky -- you have to
> click directly on the image of the tile you want to place, even though its
> description takes up a larger space that looks like a button.

The controls are those in the panel on the left to the map to select the 
tiles? On my system it is sufficient to click on the description and it 
neither takes up a larger space than the tile.
But I have a linux system, so my observation does not imply a lot.

>
> The route calculation logic seems correct when it gives an answer at all.
> But in most turns it did not even guess at a revenue number for By.

Most likely the graph generator or the revenue calculator ran into bug. 
It would be great, if you could share your save file to fix that, as for my 
own test cases no (such) bug occurs anymore. 

>
> I also tried out the "Cash Correction" mode just to see if it would help,
> and found that once you select it you can't cancel it without changing
> anything.  Entering zero gets you an error popup.
    
I admit that I deliberately decided to block the usual game actions as long as 
(any) correction mode is active. My intention was to highlight that the 
actions available during correction allows the violation of game rules.
And I admit that I have not considered what happens if someone does not figure 
out how to leave that mode. Maybe there should be some status bar, that 
indicates that you can leave the correction modes by deactivating them in the 
menu.
The error popup on zero cash change is the standard implementation in Rails, 
if you select a non-valid parameter, as those checks are done by the backend. 
Sorry for trapping the game by this.

Stefan

[Rails-devel] 1835 IPO order messed up.

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

I have fixed the 1835 IPO order problem, where Undo did mess up the order of
the 10%/20% certificates of e.g. the Badische.
Erik.

Re: [Rails-devel] 1835: Later Prussian formation rounds

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

Three other things I just noticed that can be derived from the same
saved game (that is likely now totally broken!)

1. the privates close on the sale of the first 5 but any PrePrussian
privates stay in players hands and you are no longer prompted to
convert them at the start of future rounds (the HB in my case)

2. during phase '5' (the 5 train just bought, just to be clear) the
Prussian has a train limit of 2, not 3

3. Net worth calculation seems a little off, I think it's getting
confused particularly with the Prussian certs.

If you want I can log all this on the bug tracker, but short of
replaying the game again (which I can do if it helps) I don't have
another test case other than the one I've already sent

Phil

On 17 June 2010 08:19, Phil Davies <de...@gm...> wrote:
> Oh, since the Pr has to be formed now if it hasn't already?  Hmm, yes,
> it would make sense to only run that step if it isn't already running
> I would think
>
> On 16 June 2010 22:13, Erik Vos <eri...@xs...> wrote:
>> This saved file no longer loads because the PR must now discard its excess
>> trains at the right time, i.e. in an earlier stage.
>>
>> The reason that in your game the PR got this prompt after the 4+4 is bought
>> probably is, that I'm at that point also starting a PR formation round.
>> Thinking about it, I should probably only do that if the PR has not been
>> started earlier. If that is the general opinion, I will change accordingly.
>>
>> Erik.
>>
>> -----Original Message-----
>> From: Phil Davies [mailto:de...@gm...]
>> Sent: Tuesday 15 June 2010 19:53
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] 1835: Later Prussian formation rounds
>>
>> It gets a little weirder with the sale of the 4+4, which as I'm aware
>> shouldn't do anything except cause the 2+2 to rust.  The Pr is forced
>> to discard one of it's 3s or 4s after it discards it's 2+2 in the
>> attached save...
>>
>> Phil
>>
>> On 13 June 2010 20:10, Phil Davies <de...@gm...> wrote:
>>>
>>>
>>> On 12 Jun 2010, at 20:33, "Erik Vos" <eri...@xs...> wrote:
>>>
>>>>
>>>> [EV] Answers below.
>>>>
>>>> Leaving the Pr with 2+2, 3, 3, 4
>>>>
>>>> Firstly, does the president of the Pr not get to choose which trains
>>>> are discarded?
>>>>
>>>> [EV] Yes, he does. The PR train discard step at the end of a merge round
>>>> isn't implemented yet (just forgotten, I'm afraid).
>>>>
>>>
>>> No worries Erik, half the reason I chose to play 1835 this time was to
>> give
>>> you some playteting feedback :) this is easily an issue we can carry on
>>> with.
>>>
>>>> Secondly, at this stage (4+4 not yet bought) is the
>>>> train limit not 3?
>>>>
>>>> [EV] Yes, but the PR may own one extra train.
>>>>
>>>
>>> Ok, I wasn't sure on this, the 18xx difference list states that the Pr can
>>> have 3 when everyone else has 2 but it isn't as clear on whether this
>>> happens in the earlier phases.
>>>
>>>>
>>>>
>>>>
>>>>
>> ----------------------------------------------------------------------------
>> --
>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>> lucky parental unit.  See the prize list and enter to win:
>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>

Re: [Rails-devel] 1835: Later Prussian formation rounds

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

Oh, since the Pr has to be formed now if it hasn't already?  Hmm, yes,
it would make sense to only run that step if it isn't already running
I would think

On 16 June 2010 22:13, Erik Vos <eri...@xs...> wrote:
> This saved file no longer loads because the PR must now discard its excess
> trains at the right time, i.e. in an earlier stage.
>
> The reason that in your game the PR got this prompt after the 4+4 is bought
> probably is, that I'm at that point also starting a PR formation round.
> Thinking about it, I should probably only do that if the PR has not been
> started earlier. If that is the general opinion, I will change accordingly.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Tuesday 15 June 2010 19:53
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1835: Later Prussian formation rounds
>
> It gets a little weirder with the sale of the 4+4, which as I'm aware
> shouldn't do anything except cause the 2+2 to rust.  The Pr is forced
> to discard one of it's 3s or 4s after it discards it's 2+2 in the
> attached save...
>
> Phil
>
> On 13 June 2010 20:10, Phil Davies <de...@gm...> wrote:
>>
>>
>> On 12 Jun 2010, at 20:33, "Erik Vos" <eri...@xs...> wrote:
>>
>>>
>>> [EV] Answers below.
>>>
>>> Leaving the Pr with 2+2, 3, 3, 4
>>>
>>> Firstly, does the president of the Pr not get to choose which trains
>>> are discarded?
>>>
>>> [EV] Yes, he does. The PR train discard step at the end of a merge round
>>> isn't implemented yet (just forgotten, I'm afraid).
>>>
>>
>> No worries Erik, half the reason I chose to play 1835 this time was to
> give
>> you some playteting feedback :) this is easily an issue we can carry on
>> with.
>>
>>> Secondly, at this stage (4+4 not yet bought) is the
>>> train limit not 3?
>>>
>>> [EV] Yes, but the PR may own one extra train.
>>>
>>
>> Ok, I wasn't sure on this, the 18xx difference list states that the Pr can
>> have 3 when everyone else has 2 but it isn't as clear on whether this
>> happens in the earlier phases.
>>
>>>
>>>
>>>
>>>
> ----------------------------------------------------------------------------
> --
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1835: Later Prussian formation rounds

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

This saved file no longer loads because the PR must now discard its excess
trains at the right time, i.e. in an earlier stage.

The reason that in your game the PR got this prompt after the 4+4 is bought
probably is, that I'm at that point also starting a PR formation round.
Thinking about it, I should probably only do that if the PR has not been
started earlier. If that is the general opinion, I will change accordingly.

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Tuesday 15 June 2010 19:53
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1835: Later Prussian formation rounds

It gets a little weirder with the sale of the 4+4, which as I'm aware
shouldn't do anything except cause the 2+2 to rust.  The Pr is forced
to discard one of it's 3s or 4s after it discards it's 2+2 in the
attached save...

Phil

On 13 June 2010 20:10, Phil Davies <de...@gm...> wrote:
>
>
> On 12 Jun 2010, at 20:33, "Erik Vos" <eri...@xs...> wrote:
>
>>
>> [EV] Answers below.
>>
>> Leaving the Pr with 2+2, 3, 3, 4
>>
>> Firstly, does the president of the Pr not get to choose which trains
>> are discarded?
>>
>> [EV] Yes, he does. The PR train discard step at the end of a merge round
>> isn't implemented yet (just forgotten, I'm afraid).
>>
>
> No worries Erik, half the reason I chose to play 1835 this time was to
give
> you some playteting feedback :) this is easily an issue we can carry on
> with.
>
>> Secondly, at this stage (4+4 not yet bought) is the
>> train limit not 3?
>>
>> [EV] Yes, but the PR may own one extra train.
>>
>
> Ok, I wasn't sure on this, the 18xx difference list states that the Pr can
> have 3 when everyone else has 2 but it isn't as clear on whether this
> happens in the earlier phases.
>
>>
>>
>>
>>
----------------------------------------------------------------------------
--
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1835: Later Prussian formation rounds

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

Yes, Cancel is probably redundant here. I'll consider removing it (at least
in this case).
Erik. 

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Tuesday 15 June 2010 22:46
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1835: Later Prussian formation rounds

I notice on the Pr formation popup dialogs that you get both a cancel
and an Ok button.  It's entirely likely thinking about it that I see
'ticking nothing and clicking OK' exactly the same as 'clicking
cancel' since in both cases I'm saying I do not want to merge anything
at this time.  I'd imagine the difference is that cancel counts as a
sort of back up step to previous?  But in this case it's only offered
at the start of the round.  There is probably an argument here to
remove the cancel button and have just the OK button as the way to
progress so that users don't get as confused?



On 15 June 2010 21:32, Erik Vos <eri...@xs...> wrote:
> This wasn't so simple as it looked, but I think it now works correctly.
>
> Your saved file had something strange. In previous PR formation rounds,
Phil
> (correctly) got a turn (to exchange HB) before Chris (to exchange the
three
> minors). However, in this final case Phil's turn was skipped; it's not
clear
> to me why. In any case, to make it loadable, I had to truncate the last
> action from this saved file. That gave me a nice test case.
>
> To all helpful bug reporters: I'll definitely check out all your reports,
as
> well as the Sourceforge bugs list, but for various reasons I'm progressing
> pretty slowly these days.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Friday 11 June 2010 17:31
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] 1835: Later Prussian formation rounds
>
> Okay, putting this one down here since I can't explain this behaviour
> either with my understanding of the rules or using the FAQ Erik linked
> earlier
>
> End of SR7, the Pr has a 3 and a 4
>
> On everyone passing, one player chooses to merge 3 of his minors,
> gifting the Pr a 2+2, 3 and another 3
>
> ++++++++++++++++++++++++
> Starting Pr formation round
> ++++++++++++++++++++++++
> Chris merges minor M5 into Pr, with 180M cash and 1 train(s)
> Chris gets a 5% share of Pr from IPO in exchange for M5
> Chris merges minor M1 into Pr, with 155M cash and 1 train(s)
> Chris gets a 5% share of Pr from IPO in exchange for M1
> Pr exchanges the M1 base token on H2/1
> Chris merges minor M4 into Pr, with 70M cash and 1 train(s)
> Chris gets a 10% share of Pr from IPO in exchange for M4
> Pr exchanges the M4 base token on G5/1
> ---
> Pr discards a 3-train to Pool
>
> Leaving the Pr with 2+2, 3, 3, 4
>
> Firstly, does the president of the Pr not get to choose which trains
> are discarded? Secondly, at this stage (4+4 not yet bought) is the
> train limit not 3?
>
> Saved file attached immediately after this scenario
>
> Phil
>
>
>
----------------------------------------------------------------------------
--
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

----------------------------------------------------------------------------
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835: Later Prussian formation rounds

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

I notice on the Pr formation popup dialogs that you get both a cancel
and an Ok button.  It's entirely likely thinking about it that I see
'ticking nothing and clicking OK' exactly the same as 'clicking
cancel' since in both cases I'm saying I do not want to merge anything
at this time.  I'd imagine the difference is that cancel counts as a
sort of back up step to previous?  But in this case it's only offered
at the start of the round.  There is probably an argument here to
remove the cancel button and have just the OK button as the way to
progress so that users don't get as confused?



On 15 June 2010 21:32, Erik Vos <eri...@xs...> wrote:
> This wasn't so simple as it looked, but I think it now works correctly.
>
> Your saved file had something strange. In previous PR formation rounds, Phil
> (correctly) got a turn (to exchange HB) before Chris (to exchange the three
> minors). However, in this final case Phil's turn was skipped; it's not clear
> to me why. In any case, to make it loadable, I had to truncate the last
> action from this saved file. That gave me a nice test case.
>
> To all helpful bug reporters: I'll definitely check out all your reports, as
> well as the Sourceforge bugs list, but for various reasons I'm progressing
> pretty slowly these days.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Friday 11 June 2010 17:31
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] 1835: Later Prussian formation rounds
>
> Okay, putting this one down here since I can't explain this behaviour
> either with my understanding of the rules or using the FAQ Erik linked
> earlier
>
> End of SR7, the Pr has a 3 and a 4
>
> On everyone passing, one player chooses to merge 3 of his minors,
> gifting the Pr a 2+2, 3 and another 3
>
> ++++++++++++++++++++++++
> Starting Pr formation round
> ++++++++++++++++++++++++
> Chris merges minor M5 into Pr, with 180M cash and 1 train(s)
> Chris gets a 5% share of Pr from IPO in exchange for M5
> Chris merges minor M1 into Pr, with 155M cash and 1 train(s)
> Chris gets a 5% share of Pr from IPO in exchange for M1
> Pr exchanges the M1 base token on H2/1
> Chris merges minor M4 into Pr, with 70M cash and 1 train(s)
> Chris gets a 10% share of Pr from IPO in exchange for M4
> Pr exchanges the M4 base token on G5/1
> ---
> Pr discards a 3-train to Pool
>
> Leaving the Pr with 2+2, 3, 3, 4
>
> Firstly, does the president of the Pr not get to choose which trains
> are discarded? Secondly, at this stage (4+4 not yet bought) is the
> train limit not 3?
>
> Saved file attached immediately after this scenario
>
> Phil
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>