Menu
▾
▴
Re: [Rails-devel] Bug: 18EU issue with starting a new minor afterphase 5
|
From: Stefan F. <ste...@we...> - 2010-07-25 11:39:02
|
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 |
