Menu
▾
▴
rails-devel
|
From: Jim B. <ji...@ko...> - 2010-07-05 23:44:07
|
Stefan wrote: > I added a simple autosave and game recovery mechanism. ... > The current defaults activate autosave and > stores a 18xx_autosave.rails file in the current working directory. Auto-saving files to the current-working directory is problematic for pbem games, where players inevitably open the pbem game from a shared dropbox folder. When autosave files appear by magic, it reveals all temporary/session-level analysis to other players, in real time (by constantly saving temp-files in the dropbox). For this reason, I think it's a pretty undesirable feature (unless Rails can become more clever about distinguishing shared/game folders, from personal/config folders, which it doesn't do well imho) .... regards, - jim |
|
From: Stefan F. <ste...@we...> - 2010-07-06 21:26:38
|
Jim & Chris, thanks for your comments. Seems that the preferences for pbem and ftf players differ substantially here. I am an example of the latter species and I currently save frequently during ftf play (even if I had no problem so far), which is a little annoying and would still require some replaying. Options in the my.properties will be available: save.recovery.active to activate/deactivate save.recovery.filepath=18xx_autosave.rails to change filename/path information A possible solution for the conflicting "defaults" are predefined configuration files for ftf and pbem plays. Maybe even asking for the preferred configuration on the first startup? Stefan PS: I assume that you currently have the working directory of Rails set to the dropbox folder? Is the 18xx.log file also generated there? In principle this would leak information to other players as well. On the other hand the autosave file would allow an easy synch as you only have to restore the game from that file. Maybe one should consider dropbox as a possible "poor man" solution for online play? On Tuesday 06 July 2010 01:25:28 Jim Black wrote: > Stefan wrote: > > I added a simple autosave and game recovery mechanism. ... > > The current defaults activate autosave and > > stores a 18xx_autosave.rails file in the current working directory. > > Auto-saving files to the current-working directory is problematic for pbem > games, where players inevitably open the pbem game from a shared dropbox > folder. > > When autosave files appear by magic, it reveals all temporary/session-level > analysis to other players, in real time (by constantly saving temp-files in > the dropbox). > > For this reason, I think it's a pretty undesirable feature (unless Rails > can become more clever about distinguishing shared/game folders, from > personal/config folders, which it doesn't do well imho) .... > > regards, > - jim > > > > --------------------------------------------------------------------------- >--- 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 |
|
From: Chris S. <chr...@gm...> - 2010-07-06 21:38:20
|
A couple of things. 1) Yes, the 18xx.log file is on Dropbox. 2) Some players, like me, use Rails from multiple computers with multiple operating systems. Any file system that isn't relative to the current directory is problematic - the paths on my home Ubuntu machine, my work Mac laptop, my work Mac desktop and random borrowed or library computers are all different. 3) Many people share all the files on Dropbox - even the executable jar and properties files. I know this is a security risk and not recommended, but it's a fact of life that it happens. 4) PBEM requires frequent saves anyway - between each player's actions. The farthest you ever have to back up is one player action. Thus, autosave doesn't add any functionality that I can see. 5) Yes, some people use Dropbox as a poor man's online play already. If everyone is online, you can just watch as the files update and when your name shows up in the new filename, you know it is your turn. Not sure what you mean about asking for the preferred configuration on first startup, but if that means every time I launch Rails, it would be annoying. I launch an instance of Rails for each action I take in pbem games. -- Chris Please consider the environment before printing this e-mail. On Tue, Jul 6, 2010 at 2:26 PM, Stefan Frey <ste...@we...> wrote: > Jim & Chris, > thanks for your comments. Seems that the preferences for pbem and ftf players > differ substantially here. I am an example of the latter species and I > currently save frequently during ftf play (even if I had no problem so far), > which is a little annoying and would still require some replaying. > > Options in the my.properties will be available: > > save.recovery.active > to activate/deactivate > > save.recovery.filepath=18xx_autosave.rails > to change filename/path information > > A possible solution for the conflicting "defaults" are predefined > configuration files for ftf and pbem plays. > > Maybe even asking for the preferred configuration on the first startup? > > Stefan > > PS: I assume that you currently have the working directory of Rails set to the > dropbox folder? Is the 18xx.log file also generated there? In principle this > would leak information to other players as well. > On the other hand the autosave file would allow an easy synch as you only have > to restore the game from that file. Maybe one should consider dropbox as a > possible "poor man" solution for online play? > > On Tuesday 06 July 2010 01:25:28 Jim Black wrote: >> Stefan wrote: >> > I added a simple autosave and game recovery mechanism. ... >> > The current defaults activate autosave and >> > stores a 18xx_autosave.rails file in the current working directory. >> >> Auto-saving files to the current-working directory is problematic for pbem >> games, where players inevitably open the pbem game from a shared dropbox >> folder. >> >> When autosave files appear by magic, it reveals all temporary/session-level >> analysis to other players, in real time (by constantly saving temp-files in >> the dropbox). >> >> For this reason, I think it's a pretty undesirable feature (unless Rails >> can become more clever about distinguishing shared/game folders, from >> personal/config folders, which it doesn't do well imho) .... >> >> regards, >> - jim >> >> >> >> --------------------------------------------------------------------------- >>--- 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 > |
|
From: Chris S. <chr...@gm...> - 2010-07-06 21:40:54
|
p.s. I think what Jim was getting at is that in pbem, it is common practice to play a game forward, taking other player's turns, just to see the outcome of a certain action or set of actions. Then, once a course of action has been decided, you exit without saving, launch again, and take your one action. As you play through perhaps entire operating rounds and stock rounds to see how the trains will fall out, to see how the CGR formation will occur, or whatever, a series of autosaves exposes a lot of potential "thinking ahead" information. It also potentially confuses people because they see all the saves and think it is their turn to act. -- Chris Please consider the environment before printing this e-mail. On Tue, Jul 6, 2010 at 2:38 PM, Chris Shaffer <chr...@gm...> wrote: > A couple of things. > > 1) Yes, the 18xx.log file is on Dropbox. > 2) Some players, like me, use Rails from multiple computers with > multiple operating systems. Any file system that isn't relative to > the current directory is problematic - the paths on my home Ubuntu > machine, my work Mac laptop, my work Mac desktop and random borrowed > or library computers are all different. > 3) Many people share all the files on Dropbox - even the executable > jar and properties files. I know this is a security risk and not > recommended, but it's a fact of life that it happens. > 4) PBEM requires frequent saves anyway - between each player's > actions. The farthest you ever have to back up is one player action. > Thus, autosave doesn't add any functionality that I can see. > 5) Yes, some people use Dropbox as a poor man's online play already. > If everyone is online, you can just watch as the files update and when > your name shows up in the new filename, you know it is your turn. > > Not sure what you mean about asking for the preferred configuration on > first startup, but if that means every time I launch Rails, it would > be annoying. I launch an instance of Rails for each action I take in > pbem games. > > -- > Chris > > Please consider the environment before printing this e-mail. > > > > On Tue, Jul 6, 2010 at 2:26 PM, Stefan Frey <ste...@we...> wrote: >> Jim & Chris, >> thanks for your comments. Seems that the preferences for pbem and ftf players >> differ substantially here. I am an example of the latter species and I >> currently save frequently during ftf play (even if I had no problem so far), >> which is a little annoying and would still require some replaying. >> >> Options in the my.properties will be available: >> >> save.recovery.active >> to activate/deactivate >> >> save.recovery.filepath=18xx_autosave.rails >> to change filename/path information >> >> A possible solution for the conflicting "defaults" are predefined >> configuration files for ftf and pbem plays. >> >> Maybe even asking for the preferred configuration on the first startup? >> >> Stefan >> >> PS: I assume that you currently have the working directory of Rails set to the >> dropbox folder? Is the 18xx.log file also generated there? In principle this >> would leak information to other players as well. >> On the other hand the autosave file would allow an easy synch as you only have >> to restore the game from that file. Maybe one should consider dropbox as a >> possible "poor man" solution for online play? >> >> On Tuesday 06 July 2010 01:25:28 Jim Black wrote: >>> Stefan wrote: >>> > I added a simple autosave and game recovery mechanism. ... >>> > The current defaults activate autosave and >>> > stores a 18xx_autosave.rails file in the current working directory. >>> >>> Auto-saving files to the current-working directory is problematic for pbem >>> games, where players inevitably open the pbem game from a shared dropbox >>> folder. >>> >>> When autosave files appear by magic, it reveals all temporary/session-level >>> analysis to other players, in real time (by constantly saving temp-files in >>> the dropbox). >>> >>> For this reason, I think it's a pretty undesirable feature (unless Rails >>> can become more clever about distinguishing shared/game folders, from >>> personal/config folders, which it doesn't do well imho) .... >>> >>> regards, >>> - jim >>> >>> >>> >>> --------------------------------------------------------------------------- >>>--- 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 >> > |
|
From: Stefan F. <ste...@we...> - 2010-07-07 12:41:32
|
Chris: thanks for the further details. My quick answers: 1) save.recovery.filepath should work relative as well, as all other folder instructions in my.properties 2) the current autosave is a recovery function intended for ftf play and avoids manual saves, thus adds functionality there 3) the idea for poor man's play is a little more than what is possible now: that each player has a running rails instance which synchronize automatically by exchanging (single) action update files via dropbox, thus avoiding a complete reload. Stefan On Tuesday 06 July 2010 23:38:12 Chris Shaffer wrote: > A couple of things. > > 1) Yes, the 18xx.log file is on Dropbox. > 2) Some players, like me, use Rails from multiple computers with > multiple operating systems. Any file system that isn't relative to > the current directory is problematic - the paths on my home Ubuntu > machine, my work Mac laptop, my work Mac desktop and random borrowed > or library computers are all different. > 3) Many people share all the files on Dropbox - even the executable > jar and properties files. I know this is a security risk and not > recommended, but it's a fact of life that it happens. > 4) PBEM requires frequent saves anyway - between each player's > actions. The farthest you ever have to back up is one player action. > Thus, autosave doesn't add any functionality that I can see. > 5) Yes, some people use Dropbox as a poor man's online play already. > If everyone is online, you can just watch as the files update and when > your name shows up in the new filename, you know it is your turn. > > Not sure what you mean about asking for the preferred configuration on > first startup, but if that means every time I launch Rails, it would > be annoying. I launch an instance of Rails for each action I take in > pbem games. > > -- > Chris > > Please consider the environment before printing this e-mail. > > On Tue, Jul 6, 2010 at 2:26 PM, Stefan Frey <ste...@we...> wrote: > > Jim & Chris, > > thanks for your comments. Seems that the preferences for pbem and ftf > > players differ substantially here. I am an example of the latter species > > and I currently save frequently during ftf play (even if I had no problem > > so far), which is a little annoying and would still require some > > replaying. > > > > Options in the my.properties will be available: > > > > save.recovery.active > > to activate/deactivate > > > > save.recovery.filepath=18xx_autosave.rails > > to change filename/path information > > > > A possible solution for the conflicting "defaults" are predefined > > configuration files for ftf and pbem plays. > > > > Maybe even asking for the preferred configuration on the first startup? > > > > Stefan > > > > PS: I assume that you currently have the working directory of Rails set > > to the dropbox folder? Is the 18xx.log file also generated there? In > > principle this would leak information to other players as well. > > On the other hand the autosave file would allow an easy synch as you only > > have to restore the game from that file. Maybe one should consider > > dropbox as a possible "poor man" solution for online play? > > > > On Tuesday 06 July 2010 01:25:28 Jim Black wrote: > >> Stefan wrote: > >> > I added a simple autosave and game recovery mechanism. ... > >> > The current defaults activate autosave and > >> > stores a 18xx_autosave.rails file in the current working directory. > >> > >> Auto-saving files to the current-working directory is problematic for > >> pbem games, where players inevitably open the pbem game from a shared > >> dropbox folder. > >> > >> When autosave files appear by magic, it reveals all > >> temporary/session-level analysis to other players, in real time (by > >> constantly saving temp-files in the dropbox). > >> > >> For this reason, I think it's a pretty undesirable feature (unless Rails > >> can become more clever about distinguishing shared/game folders, from > >> personal/config folders, which it doesn't do well imho) .... > >> > >> regards, > >> - jim > >> > >> > >> > >> ------------------------------------------------------------------------ > >>--- --- 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 |
|
From: brett l. <bre...@gm...> - 2010-07-06 22:05:47
|
On Tue, Jul 6, 2010 at 9:26 PM, Stefan Frey <ste...@we...> wrote: > Options in the my.properties will be available: > > save.recovery.active > to activate/deactivate > > save.recovery.filepath=18xx_autosave.rails > to change filename/path information > As a general rule, we should try to most options that affect loading, saving, and gameplay into the GUI. Properties file options are great for development and "sensible" defaults that few people will want to change. We can then have the GUI update the properties file with the updated settings (if it doesn't already). > A possible solution for the conflicting "defaults" are predefined > configuration files for ftf and pbem plays. > > Maybe even asking for the preferred configuration on the first startup? > > Stefan > ---Brett. |
|
From: Stefan F. <ste...@we...> - 2010-07-08 20:36:16
|
I agree, but currently none of the config/properties options can be adjusted by the GUI (as far as I know at least), thus I follow good practice here ;-) Serveral ways to improve the mechanism: 1) Create a UI to edit the configuration options 2) Store user adjustments 3) Provide ftf/pbem defaults properties 2) and 3) are easy to code as they are directly supported by the properties class. For 1) the tedious part is to enforce restrictions and provide help text. Stefan > > As a general rule, we should try to most options that affect loading, > saving, and gameplay into the GUI. > > Properties file options are great for development and "sensible" > defaults that few people will want to change. > > We can then have the GUI update the properties file with the updated > settings (if it doesn't already). > > > A possible solution for the conflicting "defaults" are predefined > > configuration files for ftf and pbem plays. > > > > Maybe even asking for the preferred configuration on the first startup? > > > > Stefan > > ---Brett. > > --------------------------------------------------------------------------- >--- 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 |
|
From: Steve U. <ste...@gm...> - 2010-07-08 20:46:19
|
1) is key for the less computer-literate among the Rails users. Steve Undy st...@ro... On Thu, Jul 8, 2010 at 2:36 PM, Stefan Frey <ste...@we...> wrote: > I agree, but currently none of the config/properties options can be > adjusted > by the GUI (as far as I know at least), thus I follow good practice here > ;-) > > Serveral ways to improve the mechanism: > > 1) Create a UI to edit the configuration options > 2) Store user adjustments > 3) Provide ftf/pbem defaults properties > > 2) and 3) are easy to code as they are directly supported by the properties > class. For 1) the tedious part is to enforce restrictions and provide help > text. > > Stefan > > > > > > As a general rule, we should try to most options that affect loading, > > saving, and gameplay into the GUI. > > > > Properties file options are great for development and "sensible" > > defaults that few people will want to change. > > > > We can then have the GUI update the properties file with the updated > > settings (if it doesn't already). > > > > > A possible solution for the conflicting "defaults" are predefined > > > configuration files for ftf and pbem plays. > > > > > > Maybe even asking for the preferred configuration on the first startup? > > > > > > Stefan > > > > ---Brett. > > > > > --------------------------------------------------------------------------- > >--- 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 > |
|
From: Chris S. <chr...@gm...> - 2010-07-06 00:42:18
|
I'd like to be able to disable autosave, and to have it off by default. -- Chris Please consider the environment before printing this e-mail. On Mon, Jul 5, 2010 at 4:25 PM, Jim Black <ji...@ko...> wrote: > > Stefan wrote: >> I added a simple autosave and game recovery mechanism. ... >> The current defaults activate autosave and >> stores a 18xx_autosave.rails file in the current working directory. > > Auto-saving files to the current-working directory is problematic for pbem games, where players inevitably open the pbem game from a shared dropbox folder. > > When autosave files appear by magic, it reveals all temporary/session-level analysis to other players, in real time (by constantly saving temp-files in the dropbox). > > For this reason, I think it's a pretty undesirable feature (unless Rails can become more clever about distinguishing shared/game folders, from personal/config folders, which it doesn't do well imho) .... > > regards, > - jim > > > > ------------------------------------------------------------------------------ > 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 > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X