rails-devel

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

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] 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 CGRformation hangs game

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

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

[EV] No, this was a long standing coding error that only now has come to
light: the (two) additional shares were counted in stead if the (one)
certificate. Fixed.

Erik.

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

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 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] 1856 bugs in Rails 1.3 -- undo duringCGRformation hangs game

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

Erik,
just a follow-up, which I forgot to report from my code review:
In the brown section of the stock market, several certificates can be bought 
in one step. Actually the UI and the action in principle seem support that. 

However even if one buys several shares, only one gets moved into your 
possession, but you still have to pay the full price :-( 
On first glance the issue could stem from the fact that the action only allows 
to store the id of one certificate bought. 
This is the flip-side of the sell shares action, which works for several 
shares, but does not store any ids.

Most likely it is easier for you to fix that as you know those actions much 
better and it might have sideeffects to the changes for 1835 with all those 
special certificates.

Stefan

On Friday 25 June 2010 11:15:35 Erik Vos wrote:
> 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
>
>
> ---------------------------------------------------------------------------
>--- 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 duringCGRformationhangs game

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

Well, it once worked, so something must have gone wrong. Side effects... 
I will investigate.
Erik. 

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Sunday 27 June 2010 00:17
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo
duringCGRformationhangs game

Erik,
just a follow-up, which I forgot to report from my code review:
In the brown section of the stock market, several certificates can be bought

in one step. Actually the UI and the action in principle seem support that. 

However even if one buys several shares, only one gets moved into your 
possession, but you still have to pay the full price :-( 
On first glance the issue could stem from the fact that the action only
allows 
to store the id of one certificate bought. 
This is the flip-side of the sell shares action, which works for several 
shares, but does not store any ids.

Most likely it is easier for you to fix that as you know those actions much 
better and it might have sideeffects to the changes for 1835 with all those 
special certificates.

Stefan

On Friday 25 June 2010 11:15:35 Erik Vos wrote:
> 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
>
>
>
---------------------------------------------------------------------------
>--- 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



----------------------------------------------------------------------------
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undoduringCGRformationhangs game

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

This was a very small and very stupid coding error. Easy to fix once spotted
(thanks!).

Erik. 

-----Original Message-----
From: Erik Vos [mailto:eri...@xs...] 
Sent: Sunday 27 June 2010 00:35
To: 'Development list for Rails: an 18xx game'
Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 --
undoduringCGRformationhangs game

Well, it once worked, so something must have gone wrong. Side effects... 
I will investigate.
Erik. 

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Sunday 27 June 2010 00:17
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo
duringCGRformationhangs game

Erik,
just a follow-up, which I forgot to report from my code review:
In the brown section of the stock market, several certificates can be bought

in one step. Actually the UI and the action in principle seem support that. 

However even if one buys several shares, only one gets moved into your 
possession, but you still have to pay the full price :-( 
On first glance the issue could stem from the fact that the action only
allows 
to store the id of one certificate bought. 
This is the flip-side of the sell shares action, which works for several 
shares, but does not store any ids.

Most likely it is easier for you to fix that as you know those actions much 
better and it might have sideeffects to the changes for 1835 with all those 
special certificates.

Stefan

On Friday 25 June 2010 11:15:35 Erik Vos wrote:
> 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
>
>
>
---------------------------------------------------------------------------
>--- 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



----------------------------------------------------------------------------
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel


----------------------------------------------------------------------------
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

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

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

Erik:
I agree that hardening Rails is important, and I believe that this includes 
improving the internal structure: Before starting the route calculation I was 
looking into some core mechanisms in Rail and I would like to return to this 
task now:

In the process of planning the changes required for 1870, I realized that some 
additional structures would help to deal with some of challenges, that new 
18xx might bring to the table. 

I will shortly outline my ideas, before I make more detailed suggestions 
and/or provide some prototype implementation. I hope for some feedback?

The proposals are mainly independent, but they link with each other well.

A) Triggerable Events
18xx games have a major class of triggers: Purchases of trains can change the 
(game) Phase, which themselves (potentially) impact any dimension of the game 
play.

Rails implements that already with the Phase/PhaseManager class. 
But digging deeper, nearly every 18xx has some actions, which have 
side-effect, but are not (full) phase changes. Even in 1830 there is at least 
one example: The purchase of the first train by public B&O closes the private 
B&O.

A very striking case is the destination run in 1870. Each tile lay a public 
company can trigger this sequence of several actions for any other company.

On the first glance I believe there should be a a trigger / triggerable 
interface combination. But Rails already has a potential trigger 
infrastructure in the state/move objects. Thus triggerable objects should 
define the potential moves/state changes and register themselves to those 
changes.

B) Round/Turn Sequence and Queuing
The sequence of rounds and that of activities inside of rounds is currently 
managed inside the classes implementing the executing logic. There is no 
(additional) framework/classes controlling the sequence alone. 
Any interruption of the standard sequence requires some tweaks to make that 
happen. And one has to be carefull to make it undo-proof.

There are several examples already in Rails for such interruptions (especially 
the treasury shares and merger rounds). 1870 would add for example share 
protection here, which changes the sequence inside a stock round.

A general framework (call it SequenceManager) which controls the sequence of 
rounds and turns (activities inside a round) would make thoses cases easier.
New rounds/turns would register themselves with the SequenceManager, which 
should also support the queueing of rounds/turns (take merger rounds as 
example, which might occur only after the round/set of rounds is finished). 
It also manages the consequences of undoing those sequence changes.

C) Splitting of the Round Classes
The two subclasses of Round are currently the swiss army knives of Rails: 
StockRound and OperatingRound are the main generator and consumer of actions 
(in addition they are responsible for the correct sequence of activities 
during Rounds, see above).

This has some benefits (espcially synergies with respect to joint variables 
and commonly used methods), but would work not very well with the more 
flexible structure suggested in B. To gain the full benefits breaking up of 
the round classes into smaller sub-units is required, at least from my point 
of view.

My suggestion here is to use an action type as the atomic unit for such a 
split. Thus for example a LayTile action works in parallel with a 
LayTileController, which generates the action and processes the actions.

The final configuration would look like that (somehow simplified):

A (simplified) OperatingRound controls the sequence by adding the different 
Controllers (LayTile, LayToken, Revenue, BuyTrain) to the SequenceManager.

The SequenceManager would activate the controllers according to the defined 
sequence. The controllers would generate actions and process the responses 
from the UI. After executing their actions the controllers would deregister 
themself from the SequenceManager.

How does a destination run in 1870 work?
This special (game specific) object is triggerable by TileMoves and checks if 
the conditions for a destination run is met: If so, it adds itself (or if 
possible a modified Revenue and LayToken controller) to the SequenceManager 
with the instruction that those actions are queued at the end of the turn of 
the acting company.

I have already some ideas, how that structure offers better support for 
optional actions and special properties, but I want to focus on the general 
ideas first. 

So what are you comments? All of this will for sure not be done in a single 
step, but only step-by-step. 

Stefan


On Friday 25 June 2010 11:15:35 Erik Vos wrote:
> 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.

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

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

See below. 

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Saturday 26 June 2010 00:24
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo
duringCGRformationhangs game

A) Triggerable Events
18xx games have a major class of triggers: Purchases of trains can change
the 
(game) Phase, which themselves (potentially) impact any dimension of the
game 
play.

Rails implements that already with the Phase/PhaseManager class. 
But digging deeper, nearly every 18xx has some actions, which have 
side-effect, but are not (full) phase changes. Even in 1830 there is at
least 
one example: The purchase of the first train by public B&O closes the
private 
B&O.

A very striking case is the destination run in 1870. Each tile lay a public 
company can trigger this sequence of several actions for any other company.

On the first glance I believe there should be a a trigger / triggerable 
interface combination. But Rails already has a potential trigger 
infrastructure in the state/move objects. Thus triggerable objects should 
define the potential moves/state changes and register themselves to those 
changes.

[EV] Perhaps a better example is the existing Phase.addObjectToClose()
method, which in fact provides a register-for-callback function. It's
currently used to close/remove some specific privates, bonuses and bonus
tokens; in this case, on phase changes only. Indeed I already had in mind
for some time to extend this function for wider use.
Closeable could be extended to (or become a subinterface of) Triggerable.

[EV] I doubt if it would be wise to overload State/Move with such new
functionality. It's low-level, and IMO should stay so.


B) Round/Turn Sequence and Queuing
The sequence of rounds and that of activities inside of rounds is currently 
managed inside the classes implementing the executing logic. There is no 
(additional) framework/classes controlling the sequence alone. 
Any interruption of the standard sequence requires some tweaks to make that 
happen. And one has to be carefull to make it undo-proof.

There are several examples already in Rails for such interruptions
(especially 
the treasury shares and merger rounds). 1870 would add for example share 
protection here, which changes the sequence inside a stock round.

A general framework (call it SequenceManager) which controls the sequence of

rounds and turns (activities inside a round) would make thoses cases easier.
New rounds/turns would register themselves with the SequenceManager, which 
should also support the queueing of rounds/turns (take merger rounds as 
example, which might occur only after the round/set of rounds is finished). 
It also manages the consequences of undoing those sequence changes.

[EV] This reminds me of an idea that Brett and I have discussed several
years ago (should be in the archive): to make the [OR] actions and their
sequence configurable (in Game.xml). Some actions can only be done in the
proper sequence, like tile/token laying. Some steps are optional or
conditional (e.g. must have the money to lay a token). Some can be executed
at any time (private buying). An XML structure should be designed to cover
all such possibilities.

[EV] Currently, sequence management is shared between the rounds and the
game manager. I don't know how that could be pulled out into a separate
structure, and whether it should, but it might be an idea worth further
consideration.


C) Splitting of the Round Classes
The two subclasses of Round are currently the swiss army knives of Rails: 
StockRound and OperatingRound are the main generator and consumer of actions

(in addition they are responsible for the correct sequence of activities 
during Rounds, see above).

This has some benefits (espcially synergies with respect to joint variables 
and commonly used methods), but would work not very well with the more 
flexible structure suggested in B. To gain the full benefits breaking up of 
the round classes into smaller sub-units is required, at least from my point

of view.

My suggestion here is to use an action type as the atomic unit for such a 
split. Thus for example a LayTile action works in parallel with a 
LayTileController, which generates the action and processes the actions.

The final configuration would look like that (somehow simplified):

A (simplified) OperatingRound controls the sequence by adding the different 
Controllers (LayTile, LayToken, Revenue, BuyTrain) to the SequenceManager.

The SequenceManager would activate the controllers according to the defined 
sequence. The controllers would generate actions and process the responses 
from the UI. After executing their actions the controllers would deregister 
themself from the SequenceManager.

[EV] How about the fact that several different actions types might be
allowed simultaneously? Such as private buying and loan taking, that in many
games can be done at all times during an OR turn?

How does a destination run in 1870 work?
This special (game specific) object is triggerable by TileMoves and checks
if 
the conditions for a destination run is met: If so, it adds itself (or if 
possible a modified Revenue and LayToken controller) to the SequenceManager 
with the instruction that those actions are queued at the end of the turn of

the acting company.

[EV] OK, this kind of answers my question above. However, I would rather
trigger it by the LayTileController finding that the action is/can be/has
been executed, rather than the TileMove, which is only the physical
execution phase. See my comment above.

I have already some ideas, how that structure offers better support for 
optional actions and special properties, but I want to focus on the general 
ideas first. 

So what are you comments? All of this will for sure not be done in a single 
step, but only step-by-step. 

[EV] I wonder to what extent this can be done 'step by step'. In particular
C) will be hard to do stepwise. 
I would propose to start with a pretty isolated case, like the 18EU start
round. Or the 1835 start round, which has old code that needs an overhaul
anyway.

[EV] It's too early to give a final answer to your ideas, but it all sounds
rather good, and, as said, partially fits with ideas I already had. But you
are going a lot further, and I can't yet quite oversee everything. An actual
working case might make it much clearer.

Erik.

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

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

Erik,
I know it is still a lot of underspecified ideas. It is good to know that it 
does not raise immediate and spontaneous rejection. 
And the best way to address concerns is to provide working and readable code 
examples, thus that will be something I will work on.

The step-by-step approach is two-fold:

1) Working on smaller bits (StartRound or ShareRounds instead of 
OperatingRound) or special classes

2) Keeping the new structure side-by-side to the existing code and only 
activate it for the test case 1870 in the beginnig. This is easy to do, as 
there are several hooks to activate different classes for game and round 
management.

After that you can still decide to follow that path or not, considering the 
implementation examples.

A few comments / replies to encourage more discussion:

* My own first idea was to use a specific trigger interface and require 
triggers to be explicitly defined. But I realized that the moves are 
excellent triggers and the Moveset a very good place to pass the messages.
Moveset could still delegate the task to a TriggerManager, if a better 
separation is required.

And I want low-level triggers, to avoid that every (high-level) implementation 
has to remember to call the trigger.

Take the example: A candidate in the long run ist the function that checks if 
a company is floated. Every (high-level) method that moves shares out of IPO 
has to check if the company has floated. If the trigger is used, this is done 
automatically. This would also cover special cases in games, which are not 
yet implemented.

(However it might be optimal to provide a generic version of ObjectMove to 
simplify that).

* I agree, the break-up into actions/action controllers and the separate 
sequence control provides the granularity/modularity that is required to 
configure the flow of actions by an XML file. But the XML file itself is for 
sure the end and not the start of the process. 

And you are right: The sequence manager should take care of the different 
types of action (availablity and conditionality). Currently I see three major 
classes of actions:
A) Required
B) Optional, but in sequence
C) Optional, always available 

The basic OR consists of:
1) Tile Lay - B
2) Token Lay - B
3) Train Run and Payout Decision - A
4) Buy Trains - B
5) Buy Privates - C

I intend to have two modes for the action availibility:
Beginner mode: Always offer the next A or B action
Expert mode: Offer all actions in sequence until the next A action or the next 
player/company takes over.

The current client of Rails currently supports only beginner mode, thus 
everything is offered in sequence and one has to inform Rails that one 
intends to not lay a tile or token. 
In the expert mode at the start of the turn tile lay, token lay and payout 
decisions would all be available. In fact Rails would already suggest the 
current optimal run and after each tile/token lay update the best run 
accordingly. A choice of a later action deactivates the earlier actions. 
(Thus a token lay would make further tile lays impossible.) Lemmis moderator 
is an example of the expert mode. 

This does not mean that I intend to change the client now, but I intend to 
make the backend compatible for future enhancements.
Stefan


On Saturday 26 June 2010 16:01:51 Erik Vos wrote:
> See below.
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Saturday 26 June 2010 00:24
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo
> duringCGRformationhangs game
>
> A) Triggerable Events
> 18xx games have a major class of triggers: Purchases of trains can change
> the
> (game) Phase, which themselves (potentially) impact any dimension of the
> game
> play.
>
> Rails implements that already with the Phase/PhaseManager class.
> But digging deeper, nearly every 18xx has some actions, which have
> side-effect, but are not (full) phase changes. Even in 1830 there is at
> least
> one example: The purchase of the first train by public B&O closes the
> private
> B&O.
>
> A very striking case is the destination run in 1870. Each tile lay a public
> company can trigger this sequence of several actions for any other company.
>
> On the first glance I believe there should be a a trigger / triggerable
> interface combination. But Rails already has a potential trigger
> infrastructure in the state/move objects. Thus triggerable objects should
> define the potential moves/state changes and register themselves to those
> changes.
>
> [EV] Perhaps a better example is the existing Phase.addObjectToClose()
> method, which in fact provides a register-for-callback function. It's
> currently used to close/remove some specific privates, bonuses and bonus
> tokens; in this case, on phase changes only. Indeed I already had in mind
> for some time to extend this function for wider use.
> Closeable could be extended to (or become a subinterface of) Triggerable.
>
> [EV] I doubt if it would be wise to overload State/Move with such new
> functionality. It's low-level, and IMO should stay so.
>
>
> B) Round/Turn Sequence and Queuing
> The sequence of rounds and that of activities inside of rounds is currently
> managed inside the classes implementing the executing logic. There is no
> (additional) framework/classes controlling the sequence alone.
> Any interruption of the standard sequence requires some tweaks to make that
> happen. And one has to be carefull to make it undo-proof.
>
> There are several examples already in Rails for such interruptions
> (especially
> the treasury shares and merger rounds). 1870 would add for example share
> protection here, which changes the sequence inside a stock round.
>
> A general framework (call it SequenceManager) which controls the sequence
> of
>
> rounds and turns (activities inside a round) would make thoses cases
> easier. New rounds/turns would register themselves with the
> SequenceManager, which should also support the queueing of rounds/turns
> (take merger rounds as example, which might occur only after the round/set
> of rounds is finished). It also manages the consequences of undoing those
> sequence changes.
>
> [EV] This reminds me of an idea that Brett and I have discussed several
> years ago (should be in the archive): to make the [OR] actions and their
> sequence configurable (in Game.xml). Some actions can only be done in the
> proper sequence, like tile/token laying. Some steps are optional or
> conditional (e.g. must have the money to lay a token). Some can be executed
> at any time (private buying). An XML structure should be designed to cover
> all such possibilities.
>
> [EV] Currently, sequence management is shared between the rounds and the
> game manager. I don't know how that could be pulled out into a separate
> structure, and whether it should, but it might be an idea worth further
> consideration.
>
>
> C) Splitting of the Round Classes
> The two subclasses of Round are currently the swiss army knives of Rails:
> StockRound and OperatingRound are the main generator and consumer of
> actions
>
> (in addition they are responsible for the correct sequence of activities
> during Rounds, see above).
>
> This has some benefits (espcially synergies with respect to joint variables
> and commonly used methods), but would work not very well with the more
> flexible structure suggested in B. To gain the full benefits breaking up of
> the round classes into smaller sub-units is required, at least from my
> point
>
> of view.
>
> My suggestion here is to use an action type as the atomic unit for such a
> split. Thus for example a LayTile action works in parallel with a
> LayTileController, which generates the action and processes the actions.
>
> The final configuration would look like that (somehow simplified):
>
> A (simplified) OperatingRound controls the sequence by adding the different
> Controllers (LayTile, LayToken, Revenue, BuyTrain) to the SequenceManager.
>
> The SequenceManager would activate the controllers according to the defined
> sequence. The controllers would generate actions and process the responses
> from the UI. After executing their actions the controllers would deregister
> themself from the SequenceManager.
>
> [EV] How about the fact that several different actions types might be
> allowed simultaneously? Such as private buying and loan taking, that in
> many games can be done at all times during an OR turn?
>
> How does a destination run in 1870 work?
> This special (game specific) object is triggerable by TileMoves and checks
> if
> the conditions for a destination run is met: If so, it adds itself (or if
> possible a modified Revenue and LayToken controller) to the SequenceManager
> with the instruction that those actions are queued at the end of the turn
> of
>
> the acting company.
>
> [EV] OK, this kind of answers my question above. However, I would rather
> trigger it by the LayTileController finding that the action is/can be/has
> been executed, rather than the TileMove, which is only the physical
> execution phase. See my comment above.
>
> I have already some ideas, how that structure offers better support for
> optional actions and special properties, but I want to focus on the general
> ideas first.
>
> So what are you comments? All of this will for sure not be done in a single
> step, but only step-by-step.
>
> [EV] I wonder to what extent this can be done 'step by step'. In particular
> C) will be hard to do stepwise.
> I would propose to start with a pretty isolated case, like the 18EU start
> round. Or the 1835 start round, which has old code that needs an overhaul
> anyway.
>
> [EV] It's too early to give a final answer to your ideas, but it all sounds
> rather good, and, as said, partially fits with ideas I already had. But you
> are going a lot further, and I can't yet quite oversee everything. An
> actual working case might make it much clearer.
>
> Erik.
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undoduringCGRformationhangs game

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

* My own first idea was to use a specific trigger interface and require 
triggers to be explicitly defined. But I realized that the moves are 
excellent triggers and the Moveset a very good place to pass the messages.
Moveset could still delegate the task to a TriggerManager, if a better 
separation is required.

And I want low-level triggers, to avoid that every (high-level)
implementation 
has to remember to call the trigger.

[EV] I still don't like at all to use the Move/MoveSets. I'd much prefer to
keep these clean. 
How are you going to tell an object Move that it is a trigger and what it
must call if it is? Or should all object moves always call all triggerables,
or the TriggerManager (and how can it find that one)? I completely don't
understand how you see this working, and what's the benefit of using the
Moves. 

Take the example: A candidate in the long run ist the function that checks
if 
a company is floated. Every (high-level) method that moves shares out of IPO

has to check if the company has floated. If the trigger is used, this is
done 
automatically. This would also cover special cases in games, which are not 
yet implemented.

[EV] What is exactly registering to what in this example? And what is
triggering what? And how can both the registerer and the triggerer find
their callees?

Erik.

Re: [Rails-devel] 1856 bugs in Rails 1.3 --undoduringCGRformationhangs game

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

Thinking about it, I realised that such a trigger mechanism already exists
and is widely used in Rails: the Observer pattern.
All States and several other object types are also ModelObjects, which
extends Observable, so any other object implementing Observer can register
at any State to be informed about any value changes.
This is mainly used to update the UI, but IIRC there are already some
server-internal Observer/Observable pairs.

I think this existing mechanism fulfills your need, and it works at the
proper level (using States/ModelObjects in stead of Moves).

In the example case of destination checks: each MapHex is an Observable that
updates its Observers (which currently only are the corresponding GUIHex
objects) each time a new tile is laid. If MapManager would register itself
with any MapHex it is creating (this isn't done yet), it will get called on
every tile lay, passing the new tile and its rotation (perhaps the hex id
should be added). 
So, whenever called, the MapManager can inititate any destination checks or
anything else that is needed.

Erik.

-----Original Message-----
From: Erik Vos [mailto:eri...@xs...] 
Sent: Sunday 27 June 2010 00:33
To: 'Development list for Rails: an 18xx game'
Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3
--undoduringCGRformationhangs game

* My own first idea was to use a specific trigger interface and require 
triggers to be explicitly defined. But I realized that the moves are 
excellent triggers and the Moveset a very good place to pass the messages.
Moveset could still delegate the task to a TriggerManager, if a better 
separation is required.

And I want low-level triggers, to avoid that every (high-level)
implementation 
has to remember to call the trigger.

[EV] I still don't like at all to use the Move/MoveSets. I'd much prefer to
keep these clean. 
How are you going to tell an object Move that it is a trigger and what it
must call if it is? Or should all object moves always call all triggerables,
or the TriggerManager (and how can it find that one)? I completely don't
understand how you see this working, and what's the benefit of using the
Moves. 

Take the example: A candidate in the long run ist the function that checks
if 
a company is floated. Every (high-level) method that moves shares out of IPO

has to check if the company has floated. If the trigger is used, this is
done 
automatically. This would also cover special cases in games, which are not 
yet implemented.

[EV] What is exactly registering to what in this example? And what is
triggering what? And how can both the registerer and the triggerer find
their callees?

Erik.


----------------------------------------------------------------------------
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Trigger implementation / bug-fix release?

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

[changed Subject]

Erik:
thanks for your suggestion: At the point of my first proposal I had no clear 
preference whether to observe the Model/State objects directly or to link 
with the Move objects which define their changes. In the latter case I use the 
existing link of all Moves to the MoveSet and have the MoveSet updating the 
triggerable objects. Here the triggerable objects are observers to the 
MoveSet. To keep things decoupled the MoveSet can forward the notification of 
the triggerable objects to the TriggerManager.

I started to look into several use cases besides checking for destination run 
routes and it seems that in all cases the Move mechanism offers advantages.

The important difference can be seen in your suggestion below: In a sense you 
recreate the TileMove information again: The TileMove activates the MapHex 
update and this update is then observed by the MapManager, which then 
triggers the route check. Why not have the TileMove directly (via MoveSet 
which every Move calls anyhow) trigger the route check?

Other advantages here is that the TileMove is more specific than the MapHex 
updates (which include changes of tokens as well) and it requires that the 
MapManager registers itself as observer of all MapHexes. The second advantage 
of the Move objects are the fact that they contain additional 
information/attributes about the change and can be used for further 
filtering.

With my current idea (in mind) the MoveSet object would forward each Move to 
the TriggerManager. A trigger can either be fully hardcoded or be 
partially/fully configured in XML: Either only the Move class (and additional 
variables to be checked) are defined or even the method to be called can be 
configured. In the latter case the concrete trigger sequence is coded in XML.

All of this is still only preliminary as I am currently focused on providing a 
prototype implementation of the sequence model.

I do not know, what the current state of your changes are, but from my point 
of view a bug-fix release soon would be nice, before the start of more 
drastic changes.

Stefan


On Sunday 27 June 2010 17:08:58 Erik Vos wrote:
> Thinking about it, I realised that such a trigger mechanism already exists
> and is widely used in Rails: the Observer pattern.
> All States and several other object types are also ModelObjects, which
> extends Observable, so any other object implementing Observer can register
> at any State to be informed about any value changes.
> This is mainly used to update the UI, but IIRC there are already some
> server-internal Observer/Observable pairs.
>
> I think this existing mechanism fulfills your need, and it works at the
> proper level (using States/ModelObjects in stead of Moves).
>
> In the example case of destination checks: each MapHex is an Observable
> that updates its Observers (which currently only are the corresponding
> GUIHex objects) each time a new tile is laid. If MapManager would register
> itself with any MapHex it is creating (this isn't done yet), it will get
> called on every tile lay, passing the new tile and its rotation (perhaps
> the hex id should be added).
> So, whenever called, the MapManager can inititate any destination checks or
> anything else that is needed.
>
> Erik.
>
> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Sunday 27 June 2010 00:33
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3
> --undoduringCGRformationhangs game
>
> * My own first idea was to use a specific trigger interface and require
> triggers to be explicitly defined. But I realized that the moves are
> excellent triggers and the Moveset a very good place to pass the messages.
> Moveset could still delegate the task to a TriggerManager, if a better
> separation is required.
>
> And I want low-level triggers, to avoid that every (high-level)
> implementation
> has to remember to call the trigger.
>
> [EV] I still don't like at all to use the Move/MoveSets. I'd much prefer to
> keep these clean.
> How are you going to tell an object Move that it is a trigger and what it
> must call if it is? Or should all object moves always call all
> triggerables, or the TriggerManager (and how can it find that one)? I
> completely don't understand how you see this working, and what's the
> benefit of using the Moves.
>
> Take the example: A candidate in the long run ist the function that checks
> if
> a company is floated. Every (high-level) method that moves shares out of
> IPO
>
> has to check if the company has floated. If the trigger is used, this is
> done
> automatically. This would also cover special cases in games, which are not
> yet implemented.
>
> [EV] What is exactly registering to what in this example? And what is
> triggering what? And how can both the registerer and the triggerer find
> their callees?
>
> Erik.
>
>
> ---------------------------------------------------------------------------
>- --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Trigger implementation / bug-fix release?

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

Stefan,

You haven't yet answered my questions. Are you going to register the
triggers with every single newly created move of a type? If not, how does a
Move/MoveSet know what to trigger, and how can it find the objects to
trigger without such explicit registration?

Another question: how do you prevent infinite loops? Moves that trigger
actions that create more moves that...

I still don't like this level mixing at all.

Moves already can trigger Observables to update their observers, but that is
for one simple, limited, low-level use only. I would like to keep the actual
game logic at the Manager/Round (i.e. upper) level.

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Monday 05 July 2010 00:25
To: Development list for Rails: an 18xx game
Subject: [Rails-devel] Trigger implementation / bug-fix release?

[changed Subject]

Erik:
thanks for your suggestion: At the point of my first proposal I had no clear

preference whether to observe the Model/State objects directly or to link 
with the Move objects which define their changes. In the latter case I use
the 
existing link of all Moves to the MoveSet and have the MoveSet updating the 
triggerable objects. Here the triggerable objects are observers to the 
MoveSet. To keep things decoupled the MoveSet can forward the notification
of 
the triggerable objects to the TriggerManager.

I started to look into several use cases besides checking for destination
run 
routes and it seems that in all cases the Move mechanism offers advantages.

The important difference can be seen in your suggestion below: In a sense
you 
recreate the TileMove information again: The TileMove activates the MapHex 
update and this update is then observed by the MapManager, which then 
triggers the route check. Why not have the TileMove directly (via MoveSet 
which every Move calls anyhow) trigger the route check?

Other advantages here is that the TileMove is more specific than the MapHex 
updates (which include changes of tokens as well) and it requires that the 
MapManager registers itself as observer of all MapHexes. The second
advantage 
of the Move objects are the fact that they contain additional 
information/attributes about the change and can be used for further 
filtering.

With my current idea (in mind) the MoveSet object would forward each Move to

the TriggerManager. A trigger can either be fully hardcoded or be 
partially/fully configured in XML: Either only the Move class (and
additional 
variables to be checked) are defined or even the method to be called can be 
configured. In the latter case the concrete trigger sequence is coded in
XML.

All of this is still only preliminary as I am currently focused on providing
a 
prototype implementation of the sequence model.

I do not know, what the current state of your changes are, but from my point

of view a bug-fix release soon would be nice, before the start of more 
drastic changes.

Stefan


On Sunday 27 June 2010 17:08:58 Erik Vos wrote:
> Thinking about it, I realised that such a trigger mechanism already exists
> and is widely used in Rails: the Observer pattern.
> All States and several other object types are also ModelObjects, which
> extends Observable, so any other object implementing Observer can register
> at any State to be informed about any value changes.
> This is mainly used to update the UI, but IIRC there are already some
> server-internal Observer/Observable pairs.
>
> I think this existing mechanism fulfills your need, and it works at the
> proper level (using States/ModelObjects in stead of Moves).
>
> In the example case of destination checks: each MapHex is an Observable
> that updates its Observers (which currently only are the corresponding
> GUIHex objects) each time a new tile is laid. If MapManager would register
> itself with any MapHex it is creating (this isn't done yet), it will get
> called on every tile lay, passing the new tile and its rotation (perhaps
> the hex id should be added).
> So, whenever called, the MapManager can inititate any destination checks
or
> anything else that is needed.
>
> Erik.
>
> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Sunday 27 June 2010 00:33
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3
> --undoduringCGRformationhangs game
>
> * My own first idea was to use a specific trigger interface and require
> triggers to be explicitly defined. But I realized that the moves are
> excellent triggers and the Moveset a very good place to pass the messages.
> Moveset could still delegate the task to a TriggerManager, if a better
> separation is required.
>
> And I want low-level triggers, to avoid that every (high-level)
> implementation
> has to remember to call the trigger.
>
> [EV] I still don't like at all to use the Move/MoveSets. I'd much prefer
to
> keep these clean.
> How are you going to tell an object Move that it is a trigger and what it
> must call if it is? Or should all object moves always call all
> triggerables, or the TriggerManager (and how can it find that one)? I
> completely don't understand how you see this working, and what's the
> benefit of using the Moves.
>
> Take the example: A candidate in the long run ist the function that checks
> if
> a company is floated. Every (high-level) method that moves shares out of
> IPO
>
> has to check if the company has floated. If the trigger is used, this is
> done
> automatically. This would also cover special cases in games, which are not
> yet implemented.
>
> [EV] What is exactly registering to what in this example? And what is
> triggering what? And how can both the registerer and the triggerer find
> their callees?
>
> Erik.
>
>
>
---------------------------------------------------------------------------
>- --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel



----------------------------------------------------------------------------
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Trigger implementation / bug-fix release?

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

Erik,
sorry for not providing satisfying answers to your q's.
I will try a little better, but not too much, as I am currently more concerned 
about my sequence proposal.
And even more words might not replace a working example.
More comments see below,
Stefan


On Monday 05 July 2010 21:13:55 Erik Vos wrote:
> Stefan,
>
> You haven't yet answered my questions. Are you going to register the
> triggers with every single newly created move of a type? If not, how does a
> Move/MoveSet know what to trigger, and how can it find the objects to
> trigger without such explicit registration?
>

It works the way around (at least half way): All Moves are already register 
themselves with the current MoveSet. The MoveSet (or the MoveStack) then 
forwards those to the TriggerManager (for separation from the Move classes - 
by your request). The triggers register themselves on creation (preferably 
from XML via the standard Rails mechanisms) to the TriggerManager only. Thus 
there is only a one time/one place register necessary.

> Another question: how do you prevent infinite loops? Moves that trigger
> actions that create more moves that...

The mechanism (as any other with a similar intention) cannot prevent infinite 
loops: Only the logic of the triggers themselves can do this.
But your suggested observer mechanisms can easily create infinite loops as 
well: Think about a maphex change which causes the observer to change the 
maphex again. Only if the observer itself decides to stop the loop at some 
time, the infinite loop is broken. 

>
> I still don't like this level mixing at all.
>
> Moves already can trigger Observables to update their observers, but that
> is for one simple, limited, low-level use only. I would like to keep the
> actual game logic at the Manager/Round (i.e. upper) level.

I disagree here: In my perception moves (at least a substantial subset of 
them) are part of the game logic.  Putting everything into Manager/Rounds 
puts a too strong burden on those (see the other mail). 

And the trigger mechanism explicitly addresses those cases, where low-level 
changes activate other (high)-level actions. Every tile lay (regardless who 
did it) can activate the destination run, any additional share might float a 
company.

>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday 05 July 2010 00:25
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Trigger implementation / bug-fix release?
>
> [changed Subject]
>
> Erik:
> thanks for your suggestion: At the point of my first proposal I had no
> clear
>
> preference whether to observe the Model/State objects directly or to link
> with the Move objects which define their changes. In the latter case I use
> the
> existing link of all Moves to the MoveSet and have the MoveSet updating the
> triggerable objects. Here the triggerable objects are observers to the
> MoveSet. To keep things decoupled the MoveSet can forward the notification
> of
> the triggerable objects to the TriggerManager.
>
> I started to look into several use cases besides checking for destination
> run
> routes and it seems that in all cases the Move mechanism offers advantages.
>
> The important difference can be seen in your suggestion below: In a sense
> you
> recreate the TileMove information again: The TileMove activates the MapHex
> update and this update is then observed by the MapManager, which then
> triggers the route check. Why not have the TileMove directly (via MoveSet
> which every Move calls anyhow) trigger the route check?
>
> Other advantages here is that the TileMove is more specific than the MapHex
> updates (which include changes of tokens as well) and it requires that the
> MapManager registers itself as observer of all MapHexes. The second
> advantage
> of the Move objects are the fact that they contain additional
> information/attributes about the change and can be used for further
> filtering.
>
> With my current idea (in mind) the MoveSet object would forward each Move
> to
>
> the TriggerManager. A trigger can either be fully hardcoded or be
> partially/fully configured in XML: Either only the Move class (and
> additional
> variables to be checked) are defined or even the method to be called can be
> configured. In the latter case the concrete trigger sequence is coded in
> XML.
>
> All of this is still only preliminary as I am currently focused on
> providing a
> prototype implementation of the sequence model.
>
> I do not know, what the current state of your changes are, but from my
> point
>
> of view a bug-fix release soon would be nice, before the start of more
> drastic changes.
>
> Stefan
>
> On Sunday 27 June 2010 17:08:58 Erik Vos wrote:
> > Thinking about it, I realised that such a trigger mechanism already
> > exists and is widely used in Rails: the Observer pattern.
> > All States and several other object types are also ModelObjects, which
> > extends Observable, so any other object implementing Observer can
> > register at any State to be informed about any value changes.
> > This is mainly used to update the UI, but IIRC there are already some
> > server-internal Observer/Observable pairs.
> >
> > I think this existing mechanism fulfills your need, and it works at the
> > proper level (using States/ModelObjects in stead of Moves).
> >
> > In the example case of destination checks: each MapHex is an Observable
> > that updates its Observers (which currently only are the corresponding
> > GUIHex objects) each time a new tile is laid. If MapManager would
> > register itself with any MapHex it is creating (this isn't done yet), it
> > will get called on every tile lay, passing the new tile and its rotation
> > (perhaps the hex id should be added).
> > So, whenever called, the MapManager can inititate any destination checks
>
> or
>
> > anything else that is needed.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Erik Vos [mailto:eri...@xs...]
> > Sent: Sunday 27 June 2010 00:33
> > To: 'Development list for Rails: an 18xx game'
> > Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3
> > --undoduringCGRformationhangs game
> >
> > * My own first idea was to use a specific trigger interface and require
> > triggers to be explicitly defined. But I realized that the moves are
> > excellent triggers and the Moveset a very good place to pass the
> > messages. Moveset could still delegate the task to a TriggerManager, if a
> > better separation is required.
> >
> > And I want low-level triggers, to avoid that every (high-level)
> > implementation
> > has to remember to call the trigger.
> >
> > [EV] I still don't like at all to use the Move/MoveSets. I'd much prefer
>
> to
>
> > keep these clean.
> > How are you going to tell an object Move that it is a trigger and what it
> > must call if it is? Or should all object moves always call all
> > triggerables, or the TriggerManager (and how can it find that one)? I
> > completely don't understand how you see this working, and what's the
> > benefit of using the Moves.
> >
> > Take the example: A candidate in the long run ist the function that
> > checks if
> > a company is floated. Every (high-level) method that moves shares out of
> > IPO
> >
> > has to check if the company has floated. If the trigger is used, this is
> > done
> > automatically. This would also cover special cases in games, which are
> > not yet implemented.
> >
> > [EV] What is exactly registering to what in this example? And what is
> > triggering what? And how can both the registerer and the triggerer find
> > their callees?
> >
> > Erik.
>
> ---------------------------------------------------------------------------
>
> >- --
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>
> >--- This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>- --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> 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...>]

The mail and the save file below contained a plethora of valuable scenarios
to find various bugs. All of them should be fixed in development now, thus we 
only have to wait for Brett for an upcoming release.
I thank Aliza for reporting all those issues, this was an invaluable help to 
track them down.

I have attached two save files:
A) 1856-CGR-formation-undo-bug_trim_329.rails
This is the save file which goes back to the root undo problem.
From here the game could be replayed correctly.

B) 1856_replayed_591_before_cgr.rails
This is the save file which I saved before the CGR formation after replaying 
from the save file in A) using the development version. I am quite confident 
that I made no mistake during the replay, but there is no guarantee.
This save file will only work with the upcoming release.

Stefan

Some comments and details of the changes below.

On Sunday 20 June 2010 05:26:12 Aliza Panitz wrote:
> 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.

I could not recreate this behavior exactly, but I found something similar:
If a company has two base tokens, one with a valid route and another without a 
valid route, the revenue calculation did return a result. This is the case for 
the CPR with a lone token in Kitchener. 

This potentially also explains the complains of John David Galt on the revenue 
calculation not working in his test of 1835 for BY: I do not have his save 
file, but I guess that he tokened in Nuernberg and created a similar scenario 
there. 

Quote from his mail from 06/13/10:
"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."

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

Undo of the CGR formation round is a difficult issue, as the implementation of 
the sequence of companies to merge is not adapted for an easy change to state 
variable. I used an easier approach for some progress here: By linking all CGR 
decisions it is possible to undo the whole formation round in one Undo, which 
actual works now ( at least for my test cases).
I added a few fixed to improve the UI behavior after the undo and there was a 
more serious bug, that the train limit of the CGR could be wrong in some 
cases.

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

That was indeed related to a sequence of undo actions and was already fixed by 
Erik a few days ago.

>
>  - Aliza

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

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

Stefan Frey wrote:
> Some comments and details of the changes below.

> Aliza Panitz wrote:
>> 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.

> I could not recreate this behavior exactly, but I found something similar:
> If a company has two base tokens, one with a valid route and another without a 
> valid route, the revenue calculation did

I assume you intended to write "not"...

> return a result. This is the case for 
> the CPR with a lone token in Kitchener. 
> 
> This potentially also explains the complains of John David Galt on the revenue 
> calculation not working in his test of 1835 for BY: I do not have his save 
> file, but I guess that he tokened in Nuernberg and created a similar scenario 
> there. 

BY tokened in Furth and did all subsequent building from there.  Munich had
a token and a tile (since I wasn't allowed to build out of Furth until the
second OR) but not a run.

> Quote from his mail from 06/13/10:
>> "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."