rails-devel

[Rails-devel] Bug: 18EU issue with starting a new minor after phase 5

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

Save file 18EU_20100720_1336_Chris.rails

Load up and start KBS at 100, base city Berlin.  Processes this action
totally fine.

Now save the game, and reload it (or just load
18EU_20100720_1602_Bug.rails).  Load error.

I traced the execution of the startCompany action and it gets
processed and logged with the correct selectedHomeCity. The
selectedHomeCity gets written to the executedActions log happily as
well.  Yet for some reason when you reload the game, the
selectedHomeCity object for that action is a null value.  It looks
like the ObjectOutputStream is, for some reason, failing to write the
selectedHomeCity object to the save file, causing the reload to fail.

Any thoughts??

You will have to load this on 1.3 by the way, I can't load this file
at all against the current head revision of the code.

Phil

Re: [Rails-devel] Bug: 18EU issue with starting a new minor after phase 5

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

Phil:
the problem is fixed now in SVN.
Your file did not work on the current development version, as there is a 
change already, which excludes non-active players from the auction.
I removed the additional pass of your save file (see attachment).
It should now work under development at least.
For 1.3 there is no fix possible.
Stefan

Details of the problem:

The bug is similar to the reload bug of the infinite last train:
The token was laid in a station in Berlin, which did not exist at the start of 
the game and thus the action was not intialized correctly.

This brings up another general rule for the reload mechanism:
Items, which do not exist at the beginning of the game, should not be 
intialized at the deserialization (readObject), but at the time of the first 
access. (This mechanism was introduced by Erik in buyTrain). 

I know wonder, which elements of Rails might not be created from the beginning 
and which actions might be effected. I looked into some potential candidates, 
but there might be still some other.

Known objects with potential problems:
* City (stations which are not available at the start of the game)
* Train (available at infinite quantities)

Known objects without problems:
* Tile (only one tile created, regardless of quantity)
* BonusTokens (only one token created per token class, regardless of quantity)

Effected classes:
City:
* LayBaseTokens: No problem, stations are reference by integer ids only
* StartCompany: Fixed now
* LayTile: No problem, relaidbasetokens is coded by a String, which is parsed 
after access only

Train:
* Buy Train (the train bought is fixed, but the exchange train could be 
effected)
* Discard Train (the discarded train could be effected)
-> Both cases are currently unlikely, as the train category with infinite 
supply is usually the best, but this might change in the future, especially 
trains not triggering phase changes might be in infinite supply


On Tuesday 20 July 2010 18:39:11 Phil Davies wrote:
> Save file 18EU_20100720_1336_Chris.rails
>
> Load up and start KBS at 100, base city Berlin.  Processes this action
> totally fine.
>
> Now save the game, and reload it (or just load
> 18EU_20100720_1602_Bug.rails).  Load error.
>
> I traced the execution of the startCompany action and it gets
> processed and logged with the correct selectedHomeCity. The
> selectedHomeCity gets written to the executedActions log happily as
> well.  Yet for some reason when you reload the game, the
> selectedHomeCity object for that action is a null value.  It looks
> like the ObjectOutputStream is, for some reason, failing to write the
> selectedHomeCity object to the save file, causing the reload to fail.
>
> Any thoughts??
>
> You will have to load this on 1.3 by the way, I can't load this file
> at all against the current head revision of the code.
>
> Phil

Re: [Rails-devel] Bug: 18EU issue with starting a new minor after phase 5

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

Stefan,

Excellent, thanks for looking into that.  Could LayBaseTokens have an
issue in 1856 where you could lay a token on a station that was a dot
town rather than a city at the beginning of the game?  I'd guess not
from what you say above.  Further to that...is it sensible to
initialize everything on first access rather than at deserialization?
Then in theory the save file is always replaying things at the state
they were during original gameplay?

Phil

On 21 July 2010 20:24, Stefan Frey <ste...@we...> wrote:
> Phil:
> the problem is fixed now in SVN.
> Your file did not work on the current development version, as there is a
> change already, which excludes non-active players from the auction.
> I removed the additional pass of your save file (see attachment).
> It should now work under development at least.
> For 1.3 there is no fix possible.
> Stefan
>
> Details of the problem:
>
> The bug is similar to the reload bug of the infinite last train:
> The token was laid in a station in Berlin, which did not exist at the start of
> the game and thus the action was not intialized correctly.
>
> This brings up another general rule for the reload mechanism:
> Items, which do not exist at the beginning of the game, should not be
> intialized at the deserialization (readObject), but at the time of the first
> access. (This mechanism was introduced by Erik in buyTrain).
>
> I know wonder, which elements of Rails might not be created from the beginning
> and which actions might be effected. I looked into some potential candidates,
> but there might be still some other.
>
> Known objects with potential problems:
> * City (stations which are not available at the start of the game)
> * Train (available at infinite quantities)
>
> Known objects without problems:
> * Tile (only one tile created, regardless of quantity)
> * BonusTokens (only one token created per token class, regardless of quantity)
>
> Effected classes:
> City:
> * LayBaseTokens: No problem, stations are reference by integer ids only
> * StartCompany: Fixed now
> * LayTile: No problem, relaidbasetokens is coded by a String, which is parsed
> after access only
>
> Train:
> * Buy Train (the train bought is fixed, but the exchange train could be
> effected)
> * Discard Train (the discarded train could be effected)
> -> Both cases are currently unlikely, as the train category with infinite
> supply is usually the best, but this might change in the future, especially
> trains not triggering phase changes might be in infinite supply
>
>
> On Tuesday 20 July 2010 18:39:11 Phil Davies wrote:
>> Save file 18EU_20100720_1336_Chris.rails
>>
>> Load up and start KBS at 100, base city Berlin.  Processes this action
>> totally fine.
>>
>> Now save the game, and reload it (or just load
>> 18EU_20100720_1602_Bug.rails).  Load error.
>>
>> I traced the execution of the startCompany action and it gets
>> processed and logged with the correct selectedHomeCity. The
>> selectedHomeCity gets written to the executedActions log happily as
>> well.  Yet for some reason when you reload the game, the
>> selectedHomeCity object for that action is a null value.  It looks
>> like the ObjectOutputStream is, for some reason, failing to write the
>> selectedHomeCity object to the save file, causing the reload to fail.
>>
>> Any thoughts??
>>
>> You will have to load this on 1.3 by the way, I can't load this file
>> at all against the current head revision of the code.
>>
>> Phil
>
>
>
> ------------------------------------------------------------------------------
> 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] Bug: 18EU issue with starting a new minor afterphase 5

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

If I understand all of this correctly, the issue is that all saved actions
are all deserialized before even one is processed. 

Once I realized (a bit late) that this is the heart of the problem, I
remembered a past discussion where we concluded that it is unfortunate that
the actions are saved as members of a List, rather than individually.
(Perhaps for a different reason, but I don't remember what started that
discussion.) 

Well, perhaps it is now time to do something about it. On saving, it's
trivial to remove the List container, and on reloading, a little refactoring
would be needed, but it's not complicated at all (including keeping
backwards compatibility). Once done, each action should be deserialized
against the current state of the game as it was at original execution time.

This approach looks simpler and less intrusive to me that the split proposed
below.

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Friday 23 July 2010 12:06
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Bug: 18EU issue with starting a new minor
afterphase 5

Stefan,

Excellent, thanks for looking into that.  Could LayBaseTokens have an
issue in 1856 where you could lay a token on a station that was a dot
town rather than a city at the beginning of the game?  I'd guess not
from what you say above.  Further to that...is it sensible to
initialize everything on first access rather than at deserialization?
Then in theory the save file is always replaying things at the state
they were during original gameplay?

Phil

On 21 July 2010 20:24, Stefan Frey <ste...@we...> wrote:
> Phil:
> the problem is fixed now in SVN.
> Your file did not work on the current development version, as there is a
> change already, which excludes non-active players from the auction.
> I removed the additional pass of your save file (see attachment).
> It should now work under development at least.
> For 1.3 there is no fix possible.
> Stefan
>
> Details of the problem:
>
> The bug is similar to the reload bug of the infinite last train:
> The token was laid in a station in Berlin, which did not exist at the
start of
> the game and thus the action was not intialized correctly.
>
> This brings up another general rule for the reload mechanism:
> Items, which do not exist at the beginning of the game, should not be
> intialized at the deserialization (readObject), but at the time of the
first
> access. (This mechanism was introduced by Erik in buyTrain).
>
> I know wonder, which elements of Rails might not be created from the
beginning
> and which actions might be effected. I looked into some potential
candidates,
> but there might be still some other.
>
> Known objects with potential problems:
> * City (stations which are not available at the start of the game)
> * Train (available at infinite quantities)
>
> Known objects without problems:
> * Tile (only one tile created, regardless of quantity)
> * BonusTokens (only one token created per token class, regardless of
quantity)
>
> Effected classes:
> City:
> * LayBaseTokens: No problem, stations are reference by integer ids only
> * StartCompany: Fixed now
> * LayTile: No problem, relaidbasetokens is coded by a String, which is
parsed
> after access only
>
> Train:
> * Buy Train (the train bought is fixed, but the exchange train could be
> effected)
> * Discard Train (the discarded train could be effected)
> -> Both cases are currently unlikely, as the train category with infinite
> supply is usually the best, but this might change in the future,
especially
> trains not triggering phase changes might be in infinite supply
>
>
> On Tuesday 20 July 2010 18:39:11 Phil Davies wrote:
>> Save file 18EU_20100720_1336_Chris.rails
>>
>> Load up and start KBS at 100, base city Berlin.  Processes this action
>> totally fine.
>>
>> Now save the game, and reload it (or just load
>> 18EU_20100720_1602_Bug.rails).  Load error.
>>
>> I traced the execution of the startCompany action and it gets
>> processed and logged with the correct selectedHomeCity. The
>> selectedHomeCity gets written to the executedActions log happily as
>> well.  Yet for some reason when you reload the game, the
>> selectedHomeCity object for that action is a null value.  It looks
>> like the ObjectOutputStream is, for some reason, failing to write the
>> selectedHomeCity object to the save file, causing the reload to fail.
>>
>> Any thoughts??
>>
>> You will have to load this on 1.3 by the way, I can't load this file
>> at all against the current head revision of the code.
>>
>> Phil
>
>
>
>
----------------------------------------------------------------------------
--
> 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] Bug: 18EU issue with starting a new minor afterphase 5

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

Erik:
you are right: the non-synchronous behavior of the deserialization and the 
game progress is the deeper cause for those issues.

I agree that not-storing the actions as a list, but separately inside the save 
file, makes sense. There are two other reasons for that:

* It would simplify the creation as the autosave file, as currently I create a 
new complete save file and overwrite the old one. Simply appending the 
additional action is easier.

* I experimented a little bit to synchronize two Rails instances to find out 
how difficult it is to add network play. For this I think the easiest way is 
to share the actions between the instances. Storing the actions separately, 
would make reloading a game or receiving actions over the network nearly 
identical.
I have to admit, that the experience from the experiment was mixed: The good 
thing is that it in principle it does work, but there is still a lot of work 
required (some parts of the actions code does not work, and there are several 
glitches on the UI, especially for tile laying).

All in all I think this is a good idea.

Stefan

On Saturday 24 July 2010 11:36:31 Erik Vos wrote:
> If I understand all of this correctly, the issue is that all saved actions
> are all deserialized before even one is processed.
>
> Once I realized (a bit late) that this is the heart of the problem, I
> remembered a past discussion where we concluded that it is unfortunate that
> the actions are saved as members of a List, rather than individually.
> (Perhaps for a different reason, but I don't remember what started that
> discussion.)
>
> Well, perhaps it is now time to do something about it. On saving, it's
> trivial to remove the List container, and on reloading, a little
> refactoring would be needed, but it's not complicated at all (including
> keeping backwards compatibility). Once done, each action should be
> deserialized against the current state of the game as it was at original
> execution time.
>
> This approach looks simpler and less intrusive to me that the split
> proposed below.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Friday 23 July 2010 12:06
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Bug: 18EU issue with starting a new minor
> afterphase 5
>
> Stefan,
>
> Excellent, thanks for looking into that.  Could LayBaseTokens have an
> issue in 1856 where you could lay a token on a station that was a dot
> town rather than a city at the beginning of the game?  I'd guess not
> from what you say above.  Further to that...is it sensible to
> initialize everything on first access rather than at deserialization?
> Then in theory the save file is always replaying things at the state
> they were during original gameplay?
>
> Phil
>
> On 21 July 2010 20:24, Stefan Frey <ste...@we...> wrote:
> > Phil:
> > the problem is fixed now in SVN.
> > Your file did not work on the current development version, as there is a
> > change already, which excludes non-active players from the auction.
> > I removed the additional pass of your save file (see attachment).
> > It should now work under development at least.
> > For 1.3 there is no fix possible.
> > Stefan
> >
> > Details of the problem:
> >
> > The bug is similar to the reload bug of the infinite last train:
> > The token was laid in a station in Berlin, which did not exist at the
>
> start of
>
> > the game and thus the action was not intialized correctly.
> >
> > This brings up another general rule for the reload mechanism:
> > Items, which do not exist at the beginning of the game, should not be
> > intialized at the deserialization (readObject), but at the time of the
>
> first
>
> > access. (This mechanism was introduced by Erik in buyTrain).
> >
> > I know wonder, which elements of Rails might not be created from the
>
> beginning
>
> > and which actions might be effected. I looked into some potential
>
> candidates,
>
> > but there might be still some other.
> >
> > Known objects with potential problems:
> > * City (stations which are not available at the start of the game)
> > * Train (available at infinite quantities)
> >
> > Known objects without problems:
> > * Tile (only one tile created, regardless of quantity)
> > * BonusTokens (only one token created per token class, regardless of
>
> quantity)
>
> > Effected classes:
> > City:
> > * LayBaseTokens: No problem, stations are reference by integer ids only
> > * StartCompany: Fixed now
> > * LayTile: No problem, relaidbasetokens is coded by a String, which is
>
> parsed
>
> > after access only
> >
> > Train:
> > * Buy Train (the train bought is fixed, but the exchange train could be
> > effected)
> > * Discard Train (the discarded train could be effected)
> > -> Both cases are currently unlikely, as the train category with infinite
> > supply is usually the best, but this might change in the future,
>
> especially
>
> > trains not triggering phase changes might be in infinite supply
> >
> > On Tuesday 20 July 2010 18:39:11 Phil Davies wrote:
> >> Save file 18EU_20100720_1336_Chris.rails
> >>
> >> Load up and start KBS at 100, base city Berlin.  Processes this action
> >> totally fine.
> >>
> >> Now save the game, and reload it (or just load
> >> 18EU_20100720_1602_Bug.rails).  Load error.
> >>
> >> I traced the execution of the startCompany action and it gets
> >> processed and logged with the correct selectedHomeCity. The
> >> selectedHomeCity gets written to the executedActions log happily as
> >> well.  Yet for some reason when you reload the game, the
> >> selectedHomeCity object for that action is a null value.  It looks
> >> like the ObjectOutputStream is, for some reason, failing to write the
> >> selectedHomeCity object to the save file, causing the reload to fail.
> >>
> >> Any thoughts??
> >>
> >> You will have to load this on 1.3 by the way, I can't load this file
> >> at all against the current head revision of the code.
> >>
> >> Phil
>
> ---------------------------------------------------------------------------
>- --
>
> > 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