rails-devel

[Rails-devel] Push request: 2 minor bug fixes (autosave handling and defaulting of game options)

[Frederick W. <fre...@go...>]

Would you please push these patches into origin/master?

--- Frederick

commit 6144b4c35787a884be65a11d08f662f9f5b3ca7a

    Fixed retrieval of default game options (if options pane was not opened)

    Game options have to be read from GamesList.xml and not from the
    respective game's Games.xml GameOption tags.
    Before the fix, this was not the case if the options pane had not been
    opened (which is the moment at which the GamesList's default options
    were loaded).

    This fix also solves Bug 3448429, as the reported missing 18EU route
    calculation was due to inconsistent defaulting between GamesList
    (default=suggest) and Games (default=deactivate). Now, the defaults
    are always taken from GamesList.

commit f8a0b7eaf7334fd36973df9e82e6dd1d1e76dea0

    Fixed autosave functionality (handling of 18xx_autosave.xxx files)

    Target design is that
    (1) new temp file (.tmp) is created
    (2) former autosave (.rails) becomes the backup autosave (.rails.bak)
    (3) temp file (.tmp) becomes the new autosave (.rails)

    Prior to the fix, the implementation did not process step (2) correctly,
    as backup autosaves were never dropped. This meant that autosave resulted
    in an error message and three files in the autosave folder (.tmp , .rails ,
    .rails.bak). That's why autosave had never worked for me (and I doubt that
    it could have worked for others).

Re: [Rails-devel] Push request: 2 minor bug fixes (autosave handling and defaulting of game options)

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

Looks good.  Applied.

Thanks!

---Brett.



On Tue, Dec 27, 2011 at 1:59 PM, Frederick Weld
<fre...@go...> wrote:
> Would you please push these patches into origin/master?
>
> --- Frederick
>
> commit 6144b4c35787a884be65a11d08f662f9f5b3ca7a
>
>    Fixed retrieval of default game options (if options pane was not opened)
>
>    Game options have to be read from GamesList.xml and not from the
>    respective game's Games.xml GameOption tags.
>    Before the fix, this was not the case if the options pane had not been
>    opened (which is the moment at which the GamesList's default options
>    were loaded).
>
>    This fix also solves Bug 3448429, as the reported missing 18EU route
>    calculation was due to inconsistent defaulting between GamesList
>    (default=suggest) and Games (default=deactivate). Now, the defaults
>    are always taken from GamesList.
>
> commit f8a0b7eaf7334fd36973df9e82e6dd1d1e76dea0
>
>    Fixed autosave functionality (handling of 18xx_autosave.xxx files)
>
>    Target design is that
>    (1) new temp file (.tmp) is created
>    (2) former autosave (.rails) becomes the backup autosave (.rails.bak)
>    (3) temp file (.tmp) becomes the new autosave (.rails)
>
>    Prior to the fix, the implementation did not process step (2) correctly,
>    as backup autosaves were never dropped. This meant that autosave resulted
>    in an error message and three files in the autosave folder (.tmp , .rails ,
>    .rails.bak). That's why autosave had never worked for me (and I doubt that
>    it could have worked for others).
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Push request: 2 minor bug fixes (autosave handling and defaulting of game options)

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

> From: Frederick Weld [mailto:fre...@go...]
> 
>     Fixed retrieval of default game options (if options pane was not
opened)
> 
>     Game options have to be read from GamesList.xml and not from the
>     respective game's Games.xml GameOption tags.
>     Before the fix, this was not the case if the options pane had not been
>     opened (which is the moment at which the GamesList's default options
>     were loaded).
> 
>     This fix also solves Bug 3448429, as the reported missing 18EU route
>     calculation was due to inconsistent defaulting between GamesList
>     (default=suggest) and Games (default=deactivate). Now, the defaults
>     are always taken from GamesList.

I vaguely remember that Stefan had a good reason why it was implemented with
different defaults.  
Or was that only for backward compatibility at some point?

Erik.

Re: [Rails-devel] Game Options defaults (was: Push request: 2 minor bug fixes (autosave handling and defaulting of game options))

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

Answering an older mail: see answer at the bottom.

On Tuesday, December 27, 2011 09:50:31 pm Erik Vos wrote:
> > From: Frederick Weld [mailto:fre...@go...]
> > 
> >     Fixed retrieval of default game options (if options pane was not
> 
> opened)
> 
> >     Game options have to be read from GamesList.xml and not from the
> >     respective game's Games.xml GameOption tags.
> >     Before the fix, this was not the case if the options pane had not
> >     been opened (which is the moment at which the GamesList's default
> >     options were loaded).
> >     
> >     This fix also solves Bug 3448429, as the reported missing 18EU route
> >     calculation was due to inconsistent defaulting between GamesList
> >     (default=suggest) and Games (default=deactivate). Now, the defaults
> >     are always taken from GamesList.
> 
> I vaguely remember that Stefan had a good reason why it was implemented
> with different defaults.
> Or was that only for backward compatibility at some point?
> 
> Erik.

Yes there is a valid distinction between those too and there is a use case for 
the difference:

The GameList.xml "default" defines the attributes at the GameStart (thus it is 
the default option shown in the start UI).

The Game.xml "default"  is/was ONLY used if the option is not defined in a 
Rails save file: Thus for those cases where a save file was saved with a 
previous Rails version which do not feature that option.

The use case is now for those options which have a default defined which is 
incompatible to the behavior defined (implicitly) in the previous Rails 
version: There have been several examples, one is the revenue calculation 
(which is a default for new games, but not automatically turned on for 
existing games) and all those options which made Rails enforcing stricter 
rules (or add automatic passes) which might have broke previous save files.

I did not implement that part of Rails and my guess was that this was not 
really intended: It seems that this behavior got forgotten during the 
refactoring of the xml parsing.

I always intended to merge the two lists and instead use attribute 
default="...." always and undefined="..." only for those cases where there is 
a reason to deviate. But that could/should wait until Rails 2.0

Stefan

Re: [Rails-devel] Autosave handling (was: Push request: 2 minor bug fixes (autosave handling and defaulting of game options))

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

And another answer to an older mail, refer to the bottom of the mail.

On Tuesday, December 27, 2011 07:59:30 pm Frederick Weld wrote:
> 
>     Fixed autosave functionality (handling of 18xx_autosave.xxx files)
> 
>     Target design is that
>     (1) new temp file (.tmp) is created
>     (2) former autosave (.rails) becomes the backup autosave (.rails.bak)
>     (3) temp file (.tmp) becomes the new autosave (.rails)
> 
>     Prior to the fix, the implementation did not process step (2)
> correctly, as backup autosaves were never dropped. This meant that
> autosave resulted in an error message and three files in the autosave
> folder (.tmp , .rails , .rails.bak). That's why autosave had never worked
> for me (and I doubt that it could have worked for others).

Thanks for fixing this. Autosave did work until (my own) refactoring of the 
save file processing, where I missed that bit. As it got not much love from 
the others (mostly because ftf-plays with Rails are the exception) I did not 
test that as I should have.

Stefan