Menu
▾
▴
rails-devel — List for discussion of Rails development
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(25) |
Mar
(84) |
Apr
(76) |
May
(25) |
Jun
(1) |
Jul
(28) |
Aug
(23) |
Sep
(50) |
Oct
(46) |
Nov
(65) |
Dec
(76) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(60) |
Feb
(33) |
Mar
(4) |
Apr
(17) |
May
(16) |
Jun
(18) |
Jul
(131) |
Aug
(11) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(5) |
| 2007 |
Jan
(71) |
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(19) |
Jul
(40) |
Aug
(38) |
Sep
(7) |
Oct
(58) |
Nov
|
Dec
(10) |
| 2008 |
Jan
(17) |
Feb
(27) |
Mar
(12) |
Apr
(1) |
May
(50) |
Jun
(10) |
Jul
|
Aug
(15) |
Sep
(24) |
Oct
(64) |
Nov
(115) |
Dec
(47) |
| 2009 |
Jan
(30) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(4) |
Nov
(132) |
Dec
(93) |
| 2010 |
Jan
(266) |
Feb
(120) |
Mar
(168) |
Apr
(127) |
May
(83) |
Jun
(93) |
Jul
(77) |
Aug
(77) |
Sep
(86) |
Oct
(30) |
Nov
(4) |
Dec
(22) |
| 2011 |
Jan
(48) |
Feb
(81) |
Mar
(198) |
Apr
(174) |
May
(72) |
Jun
(101) |
Jul
(236) |
Aug
(144) |
Sep
(54) |
Oct
(132) |
Nov
(94) |
Dec
(111) |
| 2012 |
Jan
(135) |
Feb
(166) |
Mar
(86) |
Apr
(85) |
May
(137) |
Jun
(83) |
Jul
(54) |
Aug
(29) |
Sep
(49) |
Oct
(37) |
Nov
(8) |
Dec
(6) |
| 2013 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(14) |
May
(5) |
Jun
(15) |
Jul
|
Aug
(38) |
Sep
(44) |
Oct
(45) |
Nov
(40) |
Dec
(23) |
| 2014 |
Jan
(22) |
Feb
(63) |
Mar
(43) |
Apr
(60) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(57) |
Sep
(36) |
Oct
(2) |
Nov
(30) |
Dec
(27) |
| 2015 |
Jan
(5) |
Feb
(2) |
Mar
(14) |
Apr
(3) |
May
|
Jun
(3) |
Jul
(10) |
Aug
(63) |
Sep
(31) |
Oct
(26) |
Nov
(11) |
Dec
(6) |
| 2016 |
Jan
|
Feb
(11) |
Mar
|
Apr
|
May
(1) |
Jun
(16) |
Jul
|
Aug
(4) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(1) |
| 2017 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(20) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(10) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(3) |
Apr
(9) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(4) |
| 2021 |
Jan
(5) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Steve U. <ste...@gm...> - 2010-08-31 16:45:29
|
I agree with Chris: It looks like cut-and-paste doesn't work from the new report window on Windows (at least not on XP). Steve Undy st...@ro... On Tue, Aug 31, 2010 at 10:37 AM, Chris Shaffer <chr...@gm...>wrote: > Interestingly, it works on my Mac at work. I'll do more testing when I get > home tonight. > > > -- > Chris > > Please consider the environment before printing this e-mail. > > > On Tue, Aug 31, 2010 at 7:30 AM, Steve Undy <ste...@gm...>wrote: > >> Hmmm. Copying from the report window works OK on my linux system. >> >> >> Steve Undy >> st...@ro... >> >> >> On Tue, Aug 31, 2010 at 8:15 AM, Chris Shaffer <chr...@gm...>wrote: >> >>> I'm using 1.4 now, and I can't seem to copy text from the new report >>> window to paste it into an email. I've tried on both Windows and Ubuntu >>> Linux, with the configuration "report window editable" checked and unchecked >>> on both systems. Any suggestions? >>> >>> >>> -- >>> Chris >>> >>> Please consider the environment before printing this e-mail. >>> >>> >>> On Wed, Aug 11, 2010 at 4:21 PM, Stefan Frey <ste...@we...> wrote: >>> >>>> Chris & Erik: >>>> * Fixed the missing newline in copy&paste from the new report window >>>> (google is your friend). >>>> >>>> * There is a new configuration window now, which allows to set options >>>> via an >>>> UI. I will add some code (similar to the one font changes) that makes >>>> the >>>> change immediate and does not require a reload. Supplying both >>>> simultaneously >>>> would be possible, but might bring more confusion to newbies than >>>> benefits to >>>> the experts? >>>> >>>> * I could change the (static/legacy) report window to the new behavior >>>> of >>>> clearing undone actions instead of appending undoing, but then the >>>> difference >>>> between the two is merely formatting and the availability of hyperlinks. >>>> Then >>>> it is easier to deactivate the formatting and hyperlinks than to support >>>> two >>>> different subclasses of the ReportWindow. >>>> >>>> There are two reasons to keep the static version: >>>> A) For me the static window acts as an accounting trail, thus keeps >>>> track of >>>> undos explicitly. >>>> B) For (quite old) computers (or handhelds if Rails gets portable in the >>>> future) the JEditorPane is a drag on performance and the whole content >>>> is >>>> updated after each action instead of appending as in the static case. >>>> >>>> Stefan >>>> >>>> >>>> On Thursday, August 12, 2010 12:31:15 am Chris Shaffer wrote: >>>> > In that case, could there be an option to enable both report windows, >>>> so >>>> > users can switch back and forth between them within a single game? >>>> And >>>> > without requiring them to edit configuration files and reload? I'd >>>> hate to >>>> > have to choose between one or the other, since they both have lots of >>>> > utility. >>>> > >>>> > -- >>>> > Chris >>>> > >>>> > Please consider the environment before printing this e-mail. >>>> > >>>> > On Wed, Aug 11, 2010 at 2:17 PM, Erik Vos <eri...@xs...> wrote: >>>> > > I found that you can do that, but at the rather severe penalty of >>>> losing >>>> > > >>>> > > all end-of lines. The report becomes one long line. >>>> > > Better keep to the (what Stefan in his wisdom disposes as) "legacy" >>>> > > report if you want to save or copy it. >>>> > > >>>> > > Erik. >>>> > > >>>> > > ------------------------------ >>>> > > >>>> > > *From:* Chris Shaffer [mailto:chr...@gm...] >>>> > > *Sent:* Wednesday 11 August 2010 21:17 >>>> > > >>>> > > *To:* Development list for Rails: an 18xx game >>>> > > *Subject:* Re: [Rails-devel] Report window as game history >>>> > > >>>> > > Is it still possible to copy text from the Report window for pasting >>>> into >>>> > > an email? >>>> > > >>>> > > -- >>>> > > Chris >>>> > > >>>> > > Please consider the environment before printing this e-mail. >>>> > > >>>> > > On Tue, Aug 10, 2010 at 4:20 PM, Stefan Frey <ste...@we...> >>>> wrote: >>>> > >> The linked movesets in the CGR 1856 merger inspired a feature that >>>> > >> proved to >>>> > >> be surprisingly easy (as it leverages on the excellent move/state >>>> > >> mechanisms >>>> > >> in Rails). The downside is that it can be effected by the all undo >>>> > >> related bugs, but the number of those was on the decrease lately. >>>> > >> >>>> > >> The report window now acts as game history: There are hyperlinks >>>> for >>>> > >> each action. Clicking on any of those lets Rails jump to that game >>>> > >> situation (by >>>> > >> calling undo repeatedly). Return to a later position is possible >>>> unless >>>> > >> an action is taken (as it is the case for standard redo). I also >>>> added >>>> > >> two buttons (<< and >>) to allow single-step moves. >>>> > >> >>>> > >> The old report window (which is editable) can be activated via the >>>> > >> Configuration menu (or setting report.window.type to static in the >>>> > >> legacy configfiles). >>>> > >> >>>> > >> Stefan >>>> > >> >>>> > >> >>>> > >> >>>> ------------------------------------------------------------------------ >>>> > >> ------ This SF.net email is sponsored by >>>> > >> >>>> > >> Make an app they can't live without >>>> > >> Enter the BlackBerry Developer Challenge >>>> > >> http://p.sf.net/sfu/RIM-dev2dev >>>> > >> _______________________________________________ >>>> > >> Rails-devel mailing list >>>> > >> Rai...@li... >>>> > >> https://lists.sourceforge.net/lists/listinfo/rails-devel >>>> > > >>>> > > >>>> ------------------------------------------------------------------------- >>>> > > ----- This SF.net email is sponsored by >>>> > > >>>> > > Make an app they can't live without >>>> > > Enter the BlackBerry Developer Challenge >>>> > > http://p.sf.net/sfu/RIM-dev2dev >>>> > > _______________________________________________ >>>> > > Rails-devel mailing list >>>> > > Rai...@li... >>>> > > https://lists.sourceforge.net/lists/listinfo/rails-devel >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by >>>> >>>> Make an app they can't live without >>>> Enter the BlackBerry Developer Challenge >>>> http://p.sf.net/sfu/RIM-dev2dev >>>> _______________________________________________ >>>> Rails-devel mailing list >>>> Rai...@li... >>>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net Dev2Dev email is sponsored by: >>> >>> Show off your parallel programming skills. >>> Enter the Intel(R) Threading Challenge 2010. >>> http://p.sf.net/sfu/intel-thread-sfd >>> >>> _______________________________________________ >>> Rails-devel mailing list >>> Rai...@li... >>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>> >>> >> >> >> ------------------------------------------------------------------------------ >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> > |
|
From: Chris S. <chr...@gm...> - 2010-08-31 16:37:21
|
Interestingly, it works on my Mac at work. I'll do more testing when I get home tonight. -- Chris Please consider the environment before printing this e-mail. On Tue, Aug 31, 2010 at 7:30 AM, Steve Undy <ste...@gm...>wrote: > Hmmm. Copying from the report window works OK on my linux system. > > > Steve Undy > st...@ro... > > > On Tue, Aug 31, 2010 at 8:15 AM, Chris Shaffer <chr...@gm...>wrote: > >> I'm using 1.4 now, and I can't seem to copy text from the new report >> window to paste it into an email. I've tried on both Windows and Ubuntu >> Linux, with the configuration "report window editable" checked and unchecked >> on both systems. Any suggestions? >> >> >> -- >> Chris >> >> Please consider the environment before printing this e-mail. >> >> >> On Wed, Aug 11, 2010 at 4:21 PM, Stefan Frey <ste...@we...> wrote: >> >>> Chris & Erik: >>> * Fixed the missing newline in copy&paste from the new report window >>> (google is your friend). >>> >>> * There is a new configuration window now, which allows to set options >>> via an >>> UI. I will add some code (similar to the one font changes) that makes >>> the >>> change immediate and does not require a reload. Supplying both >>> simultaneously >>> would be possible, but might bring more confusion to newbies than >>> benefits to >>> the experts? >>> >>> * I could change the (static/legacy) report window to the new behavior of >>> clearing undone actions instead of appending undoing, but then the >>> difference >>> between the two is merely formatting and the availability of hyperlinks. >>> Then >>> it is easier to deactivate the formatting and hyperlinks than to support >>> two >>> different subclasses of the ReportWindow. >>> >>> There are two reasons to keep the static version: >>> A) For me the static window acts as an accounting trail, thus keeps track >>> of >>> undos explicitly. >>> B) For (quite old) computers (or handhelds if Rails gets portable in the >>> future) the JEditorPane is a drag on performance and the whole content is >>> updated after each action instead of appending as in the static case. >>> >>> Stefan >>> >>> >>> On Thursday, August 12, 2010 12:31:15 am Chris Shaffer wrote: >>> > In that case, could there be an option to enable both report windows, >>> so >>> > users can switch back and forth between them within a single game? And >>> > without requiring them to edit configuration files and reload? I'd >>> hate to >>> > have to choose between one or the other, since they both have lots of >>> > utility. >>> > >>> > -- >>> > Chris >>> > >>> > Please consider the environment before printing this e-mail. >>> > >>> > On Wed, Aug 11, 2010 at 2:17 PM, Erik Vos <eri...@xs...> wrote: >>> > > I found that you can do that, but at the rather severe penalty of >>> losing >>> > > >>> > > all end-of lines. The report becomes one long line. >>> > > Better keep to the (what Stefan in his wisdom disposes as) "legacy" >>> > > report if you want to save or copy it. >>> > > >>> > > Erik. >>> > > >>> > > ------------------------------ >>> > > >>> > > *From:* Chris Shaffer [mailto:chr...@gm...] >>> > > *Sent:* Wednesday 11 August 2010 21:17 >>> > > >>> > > *To:* Development list for Rails: an 18xx game >>> > > *Subject:* Re: [Rails-devel] Report window as game history >>> > > >>> > > Is it still possible to copy text from the Report window for pasting >>> into >>> > > an email? >>> > > >>> > > -- >>> > > Chris >>> > > >>> > > Please consider the environment before printing this e-mail. >>> > > >>> > > On Tue, Aug 10, 2010 at 4:20 PM, Stefan Frey <ste...@we...> >>> wrote: >>> > >> The linked movesets in the CGR 1856 merger inspired a feature that >>> > >> proved to >>> > >> be surprisingly easy (as it leverages on the excellent move/state >>> > >> mechanisms >>> > >> in Rails). The downside is that it can be effected by the all undo >>> > >> related bugs, but the number of those was on the decrease lately. >>> > >> >>> > >> The report window now acts as game history: There are hyperlinks for >>> > >> each action. Clicking on any of those lets Rails jump to that game >>> > >> situation (by >>> > >> calling undo repeatedly). Return to a later position is possible >>> unless >>> > >> an action is taken (as it is the case for standard redo). I also >>> added >>> > >> two buttons (<< and >>) to allow single-step moves. >>> > >> >>> > >> The old report window (which is editable) can be activated via the >>> > >> Configuration menu (or setting report.window.type to static in the >>> > >> legacy configfiles). >>> > >> >>> > >> Stefan >>> > >> >>> > >> >>> > >> >>> ------------------------------------------------------------------------ >>> > >> ------ This SF.net email is sponsored by >>> > >> >>> > >> Make an app they can't live without >>> > >> Enter the BlackBerry Developer Challenge >>> > >> http://p.sf.net/sfu/RIM-dev2dev >>> > >> _______________________________________________ >>> > >> Rails-devel mailing list >>> > >> Rai...@li... >>> > >> https://lists.sourceforge.net/lists/listinfo/rails-devel >>> > > >>> > > >>> ------------------------------------------------------------------------- >>> > > ----- This SF.net email is sponsored by >>> > > >>> > > Make an app they can't live without >>> > > Enter the BlackBerry Developer Challenge >>> > > http://p.sf.net/sfu/RIM-dev2dev >>> > > _______________________________________________ >>> > > Rails-devel mailing list >>> > > Rai...@li... >>> > > https://lists.sourceforge.net/lists/listinfo/rails-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by >>> >>> Make an app they can't live without >>> Enter the BlackBerry Developer Challenge >>> http://p.sf.net/sfu/RIM-dev2dev >>> _______________________________________________ >>> Rails-devel mailing list >>> Rai...@li... >>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>> >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Chris S. <chr...@gm...> - 2010-08-31 15:33:30
|
Also, switching from static to dynamic and vice versa apparently requires closing the program, opening the program, and reloading the game. -- Chris Please consider the environment before printing this e-mail. On Tue, Aug 31, 2010 at 8:09 AM, Chris Shaffer <chr...@gm...>wrote: > Yes, that works of course, but the point was that Stefan said we would be > able to copy from both reports. The dynamic report is much more useful. If > I have to change to/from static/dynamic every time I play a turn, that will > get a bit silly. > > > -- > Chris > > Please consider the environment before printing this e-mail. > > > On Tue, Aug 31, 2010 at 7:39 AM, Steve Undy <ste...@gm...>wrote: > >> Have you tried changing the report type to "static"? >> >> Steve Undy >> st...@ro... >> >> >> On Tue, Aug 31, 2010 at 8:15 AM, Chris Shaffer <chr...@gm...>wrote: >> >>> I'm using 1.4 now, and I can't seem to copy text from the new report >>> window to paste it into an email. I've tried on both Windows and Ubuntu >>> Linux, with the configuration "report window editable" checked and unchecked >>> on both systems. Any suggestions? >>> >>> >>> -- >>> Chris >>> >>> Please consider the environment before printing this e-mail. >>> >>> >>> On Wed, Aug 11, 2010 at 4:21 PM, Stefan Frey <ste...@we...> wrote: >>> >>>> Chris & Erik: >>>> * Fixed the missing newline in copy&paste from the new report window >>>> (google is your friend). >>>> >>>> * There is a new configuration window now, which allows to set options >>>> via an >>>> UI. I will add some code (similar to the one font changes) that makes >>>> the >>>> change immediate and does not require a reload. Supplying both >>>> simultaneously >>>> would be possible, but might bring more confusion to newbies than >>>> benefits to >>>> the experts? >>>> >>>> * I could change the (static/legacy) report window to the new behavior >>>> of >>>> clearing undone actions instead of appending undoing, but then the >>>> difference >>>> between the two is merely formatting and the availability of hyperlinks. >>>> Then >>>> it is easier to deactivate the formatting and hyperlinks than to support >>>> two >>>> different subclasses of the ReportWindow. >>>> >>>> There are two reasons to keep the static version: >>>> A) For me the static window acts as an accounting trail, thus keeps >>>> track of >>>> undos explicitly. >>>> B) For (quite old) computers (or handhelds if Rails gets portable in the >>>> future) the JEditorPane is a drag on performance and the whole content >>>> is >>>> updated after each action instead of appending as in the static case. >>>> >>>> Stefan >>>> >>>> >>>> On Thursday, August 12, 2010 12:31:15 am Chris Shaffer wrote: >>>> > In that case, could there be an option to enable both report windows, >>>> so >>>> > users can switch back and forth between them within a single game? >>>> And >>>> > without requiring them to edit configuration files and reload? I'd >>>> hate to >>>> > have to choose between one or the other, since they both have lots of >>>> > utility. >>>> > >>>> > -- >>>> > Chris >>>> > >>>> > Please consider the environment before printing this e-mail. >>>> > >>>> > On Wed, Aug 11, 2010 at 2:17 PM, Erik Vos <eri...@xs...> wrote: >>>> > > I found that you can do that, but at the rather severe penalty of >>>> losing >>>> > > >>>> > > all end-of lines. The report becomes one long line. >>>> > > Better keep to the (what Stefan in his wisdom disposes as) "legacy" >>>> > > report if you want to save or copy it. >>>> > > >>>> > > Erik. >>>> > > >>>> > > ------------------------------ >>>> > > >>>> > > *From:* Chris Shaffer [mailto:chr...@gm...] >>>> > > *Sent:* Wednesday 11 August 2010 21:17 >>>> > > >>>> > > *To:* Development list for Rails: an 18xx game >>>> > > *Subject:* Re: [Rails-devel] Report window as game history >>>> > > >>>> > > Is it still possible to copy text from the Report window for pasting >>>> into >>>> > > an email? >>>> > > >>>> > > -- >>>> > > Chris >>>> > > >>>> > > Please consider the environment before printing this e-mail. >>>> > > >>>> > > On Tue, Aug 10, 2010 at 4:20 PM, Stefan Frey <ste...@we...> >>>> wrote: >>>> > >> The linked movesets in the CGR 1856 merger inspired a feature that >>>> > >> proved to >>>> > >> be surprisingly easy (as it leverages on the excellent move/state >>>> > >> mechanisms >>>> > >> in Rails). The downside is that it can be effected by the all undo >>>> > >> related bugs, but the number of those was on the decrease lately. >>>> > >> >>>> > >> The report window now acts as game history: There are hyperlinks >>>> for >>>> > >> each action. Clicking on any of those lets Rails jump to that game >>>> > >> situation (by >>>> > >> calling undo repeatedly). Return to a later position is possible >>>> unless >>>> > >> an action is taken (as it is the case for standard redo). I also >>>> added >>>> > >> two buttons (<< and >>) to allow single-step moves. >>>> > >> >>>> > >> The old report window (which is editable) can be activated via the >>>> > >> Configuration menu (or setting report.window.type to static in the >>>> > >> legacy configfiles). >>>> > >> >>>> > >> Stefan >>>> > >> >>>> > >> >>>> > >> >>>> ------------------------------------------------------------------------ >>>> > >> ------ This SF.net email is sponsored by >>>> > >> >>>> > >> Make an app they can't live without >>>> > >> Enter the BlackBerry Developer Challenge >>>> > >> http://p.sf.net/sfu/RIM-dev2dev >>>> > >> _______________________________________________ >>>> > >> Rails-devel mailing list >>>> > >> Rai...@li... >>>> > >> https://lists.sourceforge.net/lists/listinfo/rails-devel >>>> > > >>>> > > >>>> ------------------------------------------------------------------------- >>>> > > ----- This SF.net email is sponsored by >>>> > > >>>> > > Make an app they can't live without >>>> > > Enter the BlackBerry Developer Challenge >>>> > > http://p.sf.net/sfu/RIM-dev2dev >>>> > > _______________________________________________ >>>> > > Rails-devel mailing list >>>> > > Rai...@li... >>>> > > https://lists.sourceforge.net/lists/listinfo/rails-devel >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by >>>> >>>> Make an app they can't live without >>>> Enter the BlackBerry Developer Challenge >>>> http://p.sf.net/sfu/RIM-dev2dev >>>> _______________________________________________ >>>> Rails-devel mailing list >>>> Rai...@li... >>>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net Dev2Dev email is sponsored by: >>> >>> Show off your parallel programming skills. >>> Enter the Intel(R) Threading Challenge 2010. >>> http://p.sf.net/sfu/intel-thread-sfd >>> >>> _______________________________________________ >>> Rails-devel mailing list >>> Rai...@li... >>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>> >>> >> >> >> ------------------------------------------------------------------------------ >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> > |
|
From: Steve U. <ste...@gm...> - 2010-08-31 15:33:03
|
Hmmm. Copying from the report window works OK on my linux system. Steve Undy st...@ro... On Tue, Aug 31, 2010 at 8:15 AM, Chris Shaffer <chr...@gm...>wrote: > I'm using 1.4 now, and I can't seem to copy text from the new report window > to paste it into an email. I've tried on both Windows and Ubuntu Linux, > with the configuration "report window editable" checked and unchecked on > both systems. Any suggestions? > > > -- > Chris > > Please consider the environment before printing this e-mail. > > > On Wed, Aug 11, 2010 at 4:21 PM, Stefan Frey <ste...@we...> wrote: > >> Chris & Erik: >> * Fixed the missing newline in copy&paste from the new report window >> (google is your friend). >> >> * There is a new configuration window now, which allows to set options via >> an >> UI. I will add some code (similar to the one font changes) that makes the >> change immediate and does not require a reload. Supplying both >> simultaneously >> would be possible, but might bring more confusion to newbies than benefits >> to >> the experts? >> >> * I could change the (static/legacy) report window to the new behavior of >> clearing undone actions instead of appending undoing, but then the >> difference >> between the two is merely formatting and the availability of hyperlinks. >> Then >> it is easier to deactivate the formatting and hyperlinks than to support >> two >> different subclasses of the ReportWindow. >> >> There are two reasons to keep the static version: >> A) For me the static window acts as an accounting trail, thus keeps track >> of >> undos explicitly. >> B) For (quite old) computers (or handhelds if Rails gets portable in the >> future) the JEditorPane is a drag on performance and the whole content is >> updated after each action instead of appending as in the static case. >> >> Stefan >> >> >> On Thursday, August 12, 2010 12:31:15 am Chris Shaffer wrote: >> > In that case, could there be an option to enable both report windows, so >> > users can switch back and forth between them within a single game? And >> > without requiring them to edit configuration files and reload? I'd hate >> to >> > have to choose between one or the other, since they both have lots of >> > utility. >> > >> > -- >> > Chris >> > >> > Please consider the environment before printing this e-mail. >> > >> > On Wed, Aug 11, 2010 at 2:17 PM, Erik Vos <eri...@xs...> wrote: >> > > I found that you can do that, but at the rather severe penalty of >> losing >> > > >> > > all end-of lines. The report becomes one long line. >> > > Better keep to the (what Stefan in his wisdom disposes as) "legacy" >> > > report if you want to save or copy it. >> > > >> > > Erik. >> > > >> > > ------------------------------ >> > > >> > > *From:* Chris Shaffer [mailto:chr...@gm...] >> > > *Sent:* Wednesday 11 August 2010 21:17 >> > > >> > > *To:* Development list for Rails: an 18xx game >> > > *Subject:* Re: [Rails-devel] Report window as game history >> > > >> > > Is it still possible to copy text from the Report window for pasting >> into >> > > an email? >> > > >> > > -- >> > > Chris >> > > >> > > Please consider the environment before printing this e-mail. >> > > >> > > On Tue, Aug 10, 2010 at 4:20 PM, Stefan Frey <ste...@we...> >> wrote: >> > >> The linked movesets in the CGR 1856 merger inspired a feature that >> > >> proved to >> > >> be surprisingly easy (as it leverages on the excellent move/state >> > >> mechanisms >> > >> in Rails). The downside is that it can be effected by the all undo >> > >> related bugs, but the number of those was on the decrease lately. >> > >> >> > >> The report window now acts as game history: There are hyperlinks for >> > >> each action. Clicking on any of those lets Rails jump to that game >> > >> situation (by >> > >> calling undo repeatedly). Return to a later position is possible >> unless >> > >> an action is taken (as it is the case for standard redo). I also >> added >> > >> two buttons (<< and >>) to allow single-step moves. >> > >> >> > >> The old report window (which is editable) can be activated via the >> > >> Configuration menu (or setting report.window.type to static in the >> > >> legacy configfiles). >> > >> >> > >> Stefan >> > >> >> > >> >> > >> >> ------------------------------------------------------------------------ >> > >> ------ This SF.net email is sponsored by >> > >> >> > >> Make an app they can't live without >> > >> Enter the BlackBerry Developer Challenge >> > >> http://p.sf.net/sfu/RIM-dev2dev >> > >> _______________________________________________ >> > >> Rails-devel mailing list >> > >> Rai...@li... >> > >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > > >> > > >> ------------------------------------------------------------------------- >> > > ----- This SF.net email is sponsored by >> > > >> > > Make an app they can't live without >> > > Enter the BlackBerry Developer Challenge >> > > http://p.sf.net/sfu/RIM-dev2dev >> > > _______________________________________________ >> > > Rails-devel mailing list >> > > Rai...@li... >> > > https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Chris S. <chr...@gm...> - 2010-08-31 15:09:36
|
Yes, that works of course, but the point was that Stefan said we would be able to copy from both reports. The dynamic report is much more useful. If I have to change to/from static/dynamic every time I play a turn, that will get a bit silly. -- Chris Please consider the environment before printing this e-mail. On Tue, Aug 31, 2010 at 7:39 AM, Steve Undy <ste...@gm...>wrote: > Have you tried changing the report type to "static"? > > Steve Undy > st...@ro... > > > On Tue, Aug 31, 2010 at 8:15 AM, Chris Shaffer <chr...@gm...>wrote: > >> I'm using 1.4 now, and I can't seem to copy text from the new report >> window to paste it into an email. I've tried on both Windows and Ubuntu >> Linux, with the configuration "report window editable" checked and unchecked >> on both systems. Any suggestions? >> >> >> -- >> Chris >> >> Please consider the environment before printing this e-mail. >> >> >> On Wed, Aug 11, 2010 at 4:21 PM, Stefan Frey <ste...@we...> wrote: >> >>> Chris & Erik: >>> * Fixed the missing newline in copy&paste from the new report window >>> (google is your friend). >>> >>> * There is a new configuration window now, which allows to set options >>> via an >>> UI. I will add some code (similar to the one font changes) that makes >>> the >>> change immediate and does not require a reload. Supplying both >>> simultaneously >>> would be possible, but might bring more confusion to newbies than >>> benefits to >>> the experts? >>> >>> * I could change the (static/legacy) report window to the new behavior of >>> clearing undone actions instead of appending undoing, but then the >>> difference >>> between the two is merely formatting and the availability of hyperlinks. >>> Then >>> it is easier to deactivate the formatting and hyperlinks than to support >>> two >>> different subclasses of the ReportWindow. >>> >>> There are two reasons to keep the static version: >>> A) For me the static window acts as an accounting trail, thus keeps track >>> of >>> undos explicitly. >>> B) For (quite old) computers (or handhelds if Rails gets portable in the >>> future) the JEditorPane is a drag on performance and the whole content is >>> updated after each action instead of appending as in the static case. >>> >>> Stefan >>> >>> >>> On Thursday, August 12, 2010 12:31:15 am Chris Shaffer wrote: >>> > In that case, could there be an option to enable both report windows, >>> so >>> > users can switch back and forth between them within a single game? And >>> > without requiring them to edit configuration files and reload? I'd >>> hate to >>> > have to choose between one or the other, since they both have lots of >>> > utility. >>> > >>> > -- >>> > Chris >>> > >>> > Please consider the environment before printing this e-mail. >>> > >>> > On Wed, Aug 11, 2010 at 2:17 PM, Erik Vos <eri...@xs...> wrote: >>> > > I found that you can do that, but at the rather severe penalty of >>> losing >>> > > >>> > > all end-of lines. The report becomes one long line. >>> > > Better keep to the (what Stefan in his wisdom disposes as) "legacy" >>> > > report if you want to save or copy it. >>> > > >>> > > Erik. >>> > > >>> > > ------------------------------ >>> > > >>> > > *From:* Chris Shaffer [mailto:chr...@gm...] >>> > > *Sent:* Wednesday 11 August 2010 21:17 >>> > > >>> > > *To:* Development list for Rails: an 18xx game >>> > > *Subject:* Re: [Rails-devel] Report window as game history >>> > > >>> > > Is it still possible to copy text from the Report window for pasting >>> into >>> > > an email? >>> > > >>> > > -- >>> > > Chris >>> > > >>> > > Please consider the environment before printing this e-mail. >>> > > >>> > > On Tue, Aug 10, 2010 at 4:20 PM, Stefan Frey <ste...@we...> >>> wrote: >>> > >> The linked movesets in the CGR 1856 merger inspired a feature that >>> > >> proved to >>> > >> be surprisingly easy (as it leverages on the excellent move/state >>> > >> mechanisms >>> > >> in Rails). The downside is that it can be effected by the all undo >>> > >> related bugs, but the number of those was on the decrease lately. >>> > >> >>> > >> The report window now acts as game history: There are hyperlinks for >>> > >> each action. Clicking on any of those lets Rails jump to that game >>> > >> situation (by >>> > >> calling undo repeatedly). Return to a later position is possible >>> unless >>> > >> an action is taken (as it is the case for standard redo). I also >>> added >>> > >> two buttons (<< and >>) to allow single-step moves. >>> > >> >>> > >> The old report window (which is editable) can be activated via the >>> > >> Configuration menu (or setting report.window.type to static in the >>> > >> legacy configfiles). >>> > >> >>> > >> Stefan >>> > >> >>> > >> >>> > >> >>> ------------------------------------------------------------------------ >>> > >> ------ This SF.net email is sponsored by >>> > >> >>> > >> Make an app they can't live without >>> > >> Enter the BlackBerry Developer Challenge >>> > >> http://p.sf.net/sfu/RIM-dev2dev >>> > >> _______________________________________________ >>> > >> Rails-devel mailing list >>> > >> Rai...@li... >>> > >> https://lists.sourceforge.net/lists/listinfo/rails-devel >>> > > >>> > > >>> ------------------------------------------------------------------------- >>> > > ----- This SF.net email is sponsored by >>> > > >>> > > Make an app they can't live without >>> > > Enter the BlackBerry Developer Challenge >>> > > http://p.sf.net/sfu/RIM-dev2dev >>> > > _______________________________________________ >>> > > Rails-devel mailing list >>> > > Rai...@li... >>> > > https://lists.sourceforge.net/lists/listinfo/rails-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by >>> >>> Make an app they can't live without >>> Enter the BlackBerry Developer Challenge >>> http://p.sf.net/sfu/RIM-dev2dev >>> _______________________________________________ >>> Rails-devel mailing list >>> Rai...@li... >>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>> >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Steve U. <ste...@gm...> - 2010-08-31 15:04:39
|
Have you tried changing the report type to "static"? Steve Undy st...@ro... On Tue, Aug 31, 2010 at 8:15 AM, Chris Shaffer <chr...@gm...>wrote: > I'm using 1.4 now, and I can't seem to copy text from the new report window > to paste it into an email. I've tried on both Windows and Ubuntu Linux, > with the configuration "report window editable" checked and unchecked on > both systems. Any suggestions? > > > -- > Chris > > Please consider the environment before printing this e-mail. > > > On Wed, Aug 11, 2010 at 4:21 PM, Stefan Frey <ste...@we...> wrote: > >> Chris & Erik: >> * Fixed the missing newline in copy&paste from the new report window >> (google is your friend). >> >> * There is a new configuration window now, which allows to set options via >> an >> UI. I will add some code (similar to the one font changes) that makes the >> change immediate and does not require a reload. Supplying both >> simultaneously >> would be possible, but might bring more confusion to newbies than benefits >> to >> the experts? >> >> * I could change the (static/legacy) report window to the new behavior of >> clearing undone actions instead of appending undoing, but then the >> difference >> between the two is merely formatting and the availability of hyperlinks. >> Then >> it is easier to deactivate the formatting and hyperlinks than to support >> two >> different subclasses of the ReportWindow. >> >> There are two reasons to keep the static version: >> A) For me the static window acts as an accounting trail, thus keeps track >> of >> undos explicitly. >> B) For (quite old) computers (or handhelds if Rails gets portable in the >> future) the JEditorPane is a drag on performance and the whole content is >> updated after each action instead of appending as in the static case. >> >> Stefan >> >> >> On Thursday, August 12, 2010 12:31:15 am Chris Shaffer wrote: >> > In that case, could there be an option to enable both report windows, so >> > users can switch back and forth between them within a single game? And >> > without requiring them to edit configuration files and reload? I'd hate >> to >> > have to choose between one or the other, since they both have lots of >> > utility. >> > >> > -- >> > Chris >> > >> > Please consider the environment before printing this e-mail. >> > >> > On Wed, Aug 11, 2010 at 2:17 PM, Erik Vos <eri...@xs...> wrote: >> > > I found that you can do that, but at the rather severe penalty of >> losing >> > > >> > > all end-of lines. The report becomes one long line. >> > > Better keep to the (what Stefan in his wisdom disposes as) "legacy" >> > > report if you want to save or copy it. >> > > >> > > Erik. >> > > >> > > ------------------------------ >> > > >> > > *From:* Chris Shaffer [mailto:chr...@gm...] >> > > *Sent:* Wednesday 11 August 2010 21:17 >> > > >> > > *To:* Development list for Rails: an 18xx game >> > > *Subject:* Re: [Rails-devel] Report window as game history >> > > >> > > Is it still possible to copy text from the Report window for pasting >> into >> > > an email? >> > > >> > > -- >> > > Chris >> > > >> > > Please consider the environment before printing this e-mail. >> > > >> > > On Tue, Aug 10, 2010 at 4:20 PM, Stefan Frey <ste...@we...> >> wrote: >> > >> The linked movesets in the CGR 1856 merger inspired a feature that >> > >> proved to >> > >> be surprisingly easy (as it leverages on the excellent move/state >> > >> mechanisms >> > >> in Rails). The downside is that it can be effected by the all undo >> > >> related bugs, but the number of those was on the decrease lately. >> > >> >> > >> The report window now acts as game history: There are hyperlinks for >> > >> each action. Clicking on any of those lets Rails jump to that game >> > >> situation (by >> > >> calling undo repeatedly). Return to a later position is possible >> unless >> > >> an action is taken (as it is the case for standard redo). I also >> added >> > >> two buttons (<< and >>) to allow single-step moves. >> > >> >> > >> The old report window (which is editable) can be activated via the >> > >> Configuration menu (or setting report.window.type to static in the >> > >> legacy configfiles). >> > >> >> > >> Stefan >> > >> >> > >> >> > >> >> ------------------------------------------------------------------------ >> > >> ------ This SF.net email is sponsored by >> > >> >> > >> Make an app they can't live without >> > >> Enter the BlackBerry Developer Challenge >> > >> http://p.sf.net/sfu/RIM-dev2dev >> > >> _______________________________________________ >> > >> Rails-devel mailing list >> > >> Rai...@li... >> > >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > > >> > > >> ------------------------------------------------------------------------- >> > > ----- This SF.net email is sponsored by >> > > >> > > Make an app they can't live without >> > > Enter the BlackBerry Developer Challenge >> > > http://p.sf.net/sfu/RIM-dev2dev >> > > _______________________________________________ >> > > Rails-devel mailing list >> > > Rai...@li... >> > > https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Chris S. <chr...@gm...> - 2010-08-31 14:15:53
|
I'm using 1.4 now, and I can't seem to copy text from the new report window to paste it into an email. I've tried on both Windows and Ubuntu Linux, with the configuration "report window editable" checked and unchecked on both systems. Any suggestions? -- Chris Please consider the environment before printing this e-mail. On Wed, Aug 11, 2010 at 4:21 PM, Stefan Frey <ste...@we...> wrote: > Chris & Erik: > * Fixed the missing newline in copy&paste from the new report window > (google is your friend). > > * There is a new configuration window now, which allows to set options via > an > UI. I will add some code (similar to the one font changes) that makes the > change immediate and does not require a reload. Supplying both > simultaneously > would be possible, but might bring more confusion to newbies than benefits > to > the experts? > > * I could change the (static/legacy) report window to the new behavior of > clearing undone actions instead of appending undoing, but then the > difference > between the two is merely formatting and the availability of hyperlinks. > Then > it is easier to deactivate the formatting and hyperlinks than to support > two > different subclasses of the ReportWindow. > > There are two reasons to keep the static version: > A) For me the static window acts as an accounting trail, thus keeps track > of > undos explicitly. > B) For (quite old) computers (or handhelds if Rails gets portable in the > future) the JEditorPane is a drag on performance and the whole content is > updated after each action instead of appending as in the static case. > > Stefan > > > On Thursday, August 12, 2010 12:31:15 am Chris Shaffer wrote: > > In that case, could there be an option to enable both report windows, so > > users can switch back and forth between them within a single game? And > > without requiring them to edit configuration files and reload? I'd hate > to > > have to choose between one or the other, since they both have lots of > > utility. > > > > -- > > Chris > > > > Please consider the environment before printing this e-mail. > > > > On Wed, Aug 11, 2010 at 2:17 PM, Erik Vos <eri...@xs...> wrote: > > > I found that you can do that, but at the rather severe penalty of > losing > > > > > > all end-of lines. The report becomes one long line. > > > Better keep to the (what Stefan in his wisdom disposes as) "legacy" > > > report if you want to save or copy it. > > > > > > Erik. > > > > > > ------------------------------ > > > > > > *From:* Chris Shaffer [mailto:chr...@gm...] > > > *Sent:* Wednesday 11 August 2010 21:17 > > > > > > *To:* Development list for Rails: an 18xx game > > > *Subject:* Re: [Rails-devel] Report window as game history > > > > > > Is it still possible to copy text from the Report window for pasting > into > > > an email? > > > > > > -- > > > Chris > > > > > > Please consider the environment before printing this e-mail. > > > > > > On Tue, Aug 10, 2010 at 4:20 PM, Stefan Frey <ste...@we...> > wrote: > > >> The linked movesets in the CGR 1856 merger inspired a feature that > > >> proved to > > >> be surprisingly easy (as it leverages on the excellent move/state > > >> mechanisms > > >> in Rails). The downside is that it can be effected by the all undo > > >> related bugs, but the number of those was on the decrease lately. > > >> > > >> The report window now acts as game history: There are hyperlinks for > > >> each action. Clicking on any of those lets Rails jump to that game > > >> situation (by > > >> calling undo repeatedly). Return to a later position is possible > unless > > >> an action is taken (as it is the case for standard redo). I also added > > >> two buttons (<< and >>) to allow single-step moves. > > >> > > >> The old report window (which is editable) can be activated via the > > >> Configuration menu (or setting report.window.type to static in the > > >> legacy configfiles). > > >> > > >> Stefan > > >> > > >> > > >> > ------------------------------------------------------------------------ > > >> ------ This SF.net email is sponsored by > > >> > > >> Make an app they can't live without > > >> Enter the BlackBerry Developer Challenge > > >> http://p.sf.net/sfu/RIM-dev2dev > > >> _______________________________________________ > > >> Rails-devel mailing list > > >> Rai...@li... > > >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > ------------------------------------------------------------------------- > > > ----- This SF.net email is sponsored by > > > > > > Make an app they can't live without > > > Enter the BlackBerry Developer Challenge > > > http://p.sf.net/sfu/RIM-dev2dev > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Stefan F. <ste...@we...> - 2010-08-30 22:36:10
|
Have you migrated to the recent Rails 1.4? It was a last minute fix due to a report last week. The bonus should be correctly removed from the revenue calculation there. (btw thanks for the compliments). Stefan On Monday, August 30, 2010 09:11:32 pm Matt Davis wrote: > I'm playing an 18AL game using rails right now, and there's an issue > with the Coal Field token (a +10 bonus in a given city for the company > placing it). The token comes off the board when a 6 train is purchased, > which is correct, but the +10 bonus seems to persist in later route > calculations. (Incidentally, the route calculations are fantastic.) > > -Matt Davis > > --------------------------------------------------------------------------- > --- This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Matt D. <da...@ma...> - 2010-08-30 19:59:36
|
I'm playing an 18AL game using rails right now, and there's an issue
with the Coal Field token (a +10 bonus in a given city for the company
placing it). The token comes off the board when a 6 train is purchased,
which is correct, but the +10 bonus seems to persist in later route
calculations. (Incidentally, the route calculations are fantastic.)
-Matt Davis
|
|
From: brett l. <bre...@gm...> - 2010-08-29 17:39:04
|
I'm pleased to announce the general availability of the latest version of Rails, version 1.4. Downloads are available at http://rails.sourceforge.net/ or by the direct link https://sourceforge.net/projects/rails/files/Rails/1.4/ Some release highlights: * Configuration UI - Configuration settings are available both at the StartUp window and under Options=>Configuration. - Settings are/have to be stored as profiles in a configuration file * New configuration options (especially for ftf) - Autosave option - Adjustable Font styles and sizes - Map autoscrolling * Game history - Report window replaced by GameHistory window, that allows to go backwards and forward through the game report. Start of replay at any position possible. - Old report window can be activated via configuration. - Uses undo mechanism, thus might still hang sometimes. * Other bug fixes - Fixes for 1856 and 18EU undo problems. - Improved revenue calculation (10-30% faster) ---Brett. |
|
From: brett l. <bre...@gm...> - 2010-08-28 18:51:27
|
I've tagged 1.4 in SVN, and am working on getting the release package built. Please resume your normal development activity in trunk. :-) ---Brett. |
|
From: Erik V. <eri...@xs...> - 2010-08-26 20:37:33
|
Stefan,
Since you created GenericState<>, I realized that State is redundant. My
thought was (and is) that we should try to merge State and GenericState<>
into State<>.
That would make IntegerState etc. basically redundant, as it could be
replaced by State<Integer> etc.
Alternatively, if we would need the extra methods, we can also have
subclasses like
class IntegerState extends State<Integer> {...}
where we can for instance add an add() method, and still reuse the set() and
get() methods with automatic casting. No more need for intValue().
On first sight, such an approach would more appeal to me than yours, but I
must admit that I have not worked it out beyond testing that the above
subclassing approach works (to my surprise, I must confess).
In any case, as State already extends ModelObject, we get that superclass
for free.
On IntegerChange etc., I don't see the added value of these new moves, if we
already have ObjectChange, but perhaps I'm dumb...
Here is the full code of my test classes:
package rails.game.state;
public class IntegerState2 extends GenericState<Integer> {
public IntegerState2 (String name, int i) {
super (name, i);
}
public IntegerState2 (String name) {
super (name, 0);
}
public void add (int i) {
set (get()+i);
}
}
package test;
import rails.game.state.IntegerState2;
public class Test {
public static void main(String[] args) {
IntegerState2 i = new IntegerState2 ("I", 1);
System.out.println(i.get());
i.set(3);
System.out.println(i.get());
i.add(2);
System.out.println(i.get());
}
}
which prints
1
3
5
Looks pretty lean to me...
I'm not sure if my idea could be extended to ArrayListState<E> extends
State<List<E>>, but perhaps it's worth a try...
Erik.
-----Original Message-----
From: Stefan Frey [mailto:ste...@we...]
Sent: Wednesday 25 August 2010 23:43
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Some (multi-)undo related bugs
Erik:
other implementation details follow here as they arose from to the topic in
the subject:
I have added two new state classes: ArrayListState and HashMapState, that
create ModelObjects, which use the already defined Move classes for changes
of
ArrayLists and HashMaps. It basically wraps the ModelObject/State around
standard ArrayLists and HashMaps and uses the standard method names to
manipulate them. In principle it would be possible to fully implement the
Map/List interfaces, but I was too lazy to write all required methods for
that.
My reason for adding those is that at least for the approach above protects
against accidentally using the non-move methods on list or maps, which are
in
fact stateful and thus require the moves instead. And I still prefer using
the
standard syntax stateList.add(object) instead of new AddToList("NameOfList",
stateList, object). And it allows to create more complicated operations
using
the atomic moves (for example addAll or initFromMap). It is possible to
retrieve the wrapped list/map as an unmodifiable view.
This allowed fixing the opertingCompanies bug in 1856 and the tilesPerColour
problem in 18EU.
Currently they do not inherit from neither ModelObject/State as the current
usage has not required them to do so. But it is possible to do so, but I
would
prefer to inherit from ModelObject directly.
If you do not mind I would like to add an according HashSetState class and
replace BooleanState, IntegerState and StringState with more specialized
versions that inherit from ModelObject instead of State and have according
simple Moves (BooleanChange, IntegerChange, StringChange) and it would allow
to introduce an easier syntax, for example for boolean: booleanVar.set(true)
or booleanVar.set(false) and booleanVar.is() or booleanVar.isNot()
This would also allow to deprecate (and remove later) the State class,as
there
is already a replacement available with GenericState. All those changes make
the StateI interface unnecessary. It could still be used as a mere marker
interface or have the getName() function at most.
Stefan
|
|
From: Chris S. <chr...@gm...> - 2010-08-26 14:14:04
|
No worries, was just curious as we're waiting to start an 1830 game. -- Chris Please consider the environment before printing this e-mail. On Wed, Aug 25, 2010 at 6:14 PM, brett lentz <bre...@gm...> wrote: > I'm hoping to get it out in the next few days. Life has been eating up > my free time, so I didn't get an opportunity last weekend to do the > release. > > ---Brett. > > > > On Wed, Aug 25, 2010 at 2:50 PM, Chris Shaffer <chr...@gm...> > wrote: > > When will the new release be available? > > > > -- > > Chris > > > > Please consider the environment before printing this e-mail. > > > > > > On Wed, Aug 25, 2010 at 2:48 PM, Stefan Frey <ste...@we...> wrote: > >> > >> Jim: > >> thanks for your suggestion. > >> > >> It was a little late for the new release, but storing the UI layout it > >> was/is > >> already high on my list. There are some question to discuss due to Java > >> flexible approach to layout its components. But I admit that I have > >> already a > >> code snippet on my desktop pc which moves the Map window to the second > >> available screen. > >> > >> Let us discuss this in more depth as soon as the dust after the new > >> release > >> has settled, which might/will introduce other bugs/suggestions. > >> > >> Stefan > >> > >> On Thursday, August 19, 2010 08:12:25 pm Jim Black wrote: > >> > I noticed that there's been substantial effort to add a > >> > configuration/properties system to Rails, and also look forward to > >> > seeing > >> > this in the next update. > >> > > >> > (I think the most critical update is the fix of the > >> > diesel-upgrade/tradein > >> > bug, fwiw- we always need to downgrade to 1.2.2 when the diesels come > >> > out, which disables the most useful/difficult phase of 1.3's automated > >> > route-calculation.) > >> > > >> > Along the lines of user preferences and properties, here's some more > >> > comments re: differences from a pbem user to a hotseat/moderator > user-- > >> > > >> > - I load pbem Rails games, from my dropbox, all day. The usage > pattern > >> > is: > >> > launch rails, load game file (the last two can be munged), make move, > >> > save game file, exit rails. > >> > > >> > ==> Note that loading/exiting rails for each game is awkward (and > >> > unusual)- I'd rather leave it running all day- loading games as > they're > >> > updated, saving & moving on to the next game, etc. > >> > > >> > - Also, once I load a game within Rails, I repeat my next sequence of > >> > operations too: I open most of the separate Rails game windows (map, > >> > stock-chart, report window), and, resize and position these windows > for > >> > my > >> > current display. > >> > > >> > ==> Note that having to reconfigure my desktop for each game is also > >> > awkward- I wish Rails maintained a record of my last window layout for > >> > each title/game- and. defaulted to that, when I [re-]load that > >> > title/game. > >> > > >> > For extra credit, it should keep separate copies for different display > >> > sizes- during the day, we may switch computers, or, we may simply > switch > >> > a > >> > laptops from the builtin display, to a larger external display. > (These > >> > things directly affect the way we config our windows, for each > >> > particular > >> > title.) > >> > > >> > There's nothing magic about any of this- but the awkward thing is, we > >> > have > >> > to repeat these exact little steps, /all day long/, in many standalone > >> > Rails sessions. It gets tedious to do these same tweaks every time we > >> > reload a game- it would be great if Rails just remembered our last > >> > window > >> > placements for each title (or, game), and little desktop stuff like > >> > that. > >> > > >> > best, > >> > - jim > >> > > >> > > >> > > >> > > >> > > >> > > --------------------------------------------------------------------------- > >> > --- This SF.net email is sponsored by > >> > > >> > Make an app they can't live without > >> > Enter the BlackBerry Developer Challenge > >> > http://p.sf.net/sfu/RIM-dev2dev > >> > _______________________________________________ > >> > Rails-devel mailing list > >> > Rai...@li... > >> > https://lists.sourceforge.net/lists/listinfo/rails-devel > >> > >> > >> > ------------------------------------------------------------------------------ > >> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > >> Be part of this innovative community and reach millions of netbook users > >> worldwide. Take advantage of special opportunities to increase revenue > and > >> speed time-to-market. Join now, and jumpstart your future. > >> http://p.sf.net/sfu/intel-atom-d2d > >> _______________________________________________ > >> Rails-devel mailing list > >> Rai...@li... > >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > ------------------------------------------------------------------------------ > > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > > Be part of this innovative community and reach millions of netbook users > > worldwide. Take advantage of special opportunities to increase revenue > and > > speed time-to-market. Join now, and jumpstart your future. > > http://p.sf.net/sfu/intel-atom-d2d > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: brett l. <bre...@gm...> - 2010-08-26 01:15:12
|
I'm hoping to get it out in the next few days. Life has been eating up my free time, so I didn't get an opportunity last weekend to do the release. ---Brett. On Wed, Aug 25, 2010 at 2:50 PM, Chris Shaffer <chr...@gm...> wrote: > When will the new release be available? > > -- > Chris > > Please consider the environment before printing this e-mail. > > > On Wed, Aug 25, 2010 at 2:48 PM, Stefan Frey <ste...@we...> wrote: >> >> Jim: >> thanks for your suggestion. >> >> It was a little late for the new release, but storing the UI layout it >> was/is >> already high on my list. There are some question to discuss due to Java >> flexible approach to layout its components. But I admit that I have >> already a >> code snippet on my desktop pc which moves the Map window to the second >> available screen. >> >> Let us discuss this in more depth as soon as the dust after the new >> release >> has settled, which might/will introduce other bugs/suggestions. >> >> Stefan >> >> On Thursday, August 19, 2010 08:12:25 pm Jim Black wrote: >> > I noticed that there's been substantial effort to add a >> > configuration/properties system to Rails, and also look forward to >> > seeing >> > this in the next update. >> > >> > (I think the most critical update is the fix of the >> > diesel-upgrade/tradein >> > bug, fwiw- we always need to downgrade to 1.2.2 when the diesels come >> > out, which disables the most useful/difficult phase of 1.3's automated >> > route-calculation.) >> > >> > Along the lines of user preferences and properties, here's some more >> > comments re: differences from a pbem user to a hotseat/moderator user-- >> > >> > - I load pbem Rails games, from my dropbox, all day. The usage pattern >> > is: >> > launch rails, load game file (the last two can be munged), make move, >> > save game file, exit rails. >> > >> > ==> Note that loading/exiting rails for each game is awkward (and >> > unusual)- I'd rather leave it running all day- loading games as they're >> > updated, saving & moving on to the next game, etc. >> > >> > - Also, once I load a game within Rails, I repeat my next sequence of >> > operations too: I open most of the separate Rails game windows (map, >> > stock-chart, report window), and, resize and position these windows for >> > my >> > current display. >> > >> > ==> Note that having to reconfigure my desktop for each game is also >> > awkward- I wish Rails maintained a record of my last window layout for >> > each title/game- and. defaulted to that, when I [re-]load that >> > title/game. >> > >> > For extra credit, it should keep separate copies for different display >> > sizes- during the day, we may switch computers, or, we may simply switch >> > a >> > laptops from the builtin display, to a larger external display. (These >> > things directly affect the way we config our windows, for each >> > particular >> > title.) >> > >> > There's nothing magic about any of this- but the awkward thing is, we >> > have >> > to repeat these exact little steps, /all day long/, in many standalone >> > Rails sessions. It gets tedious to do these same tweaks every time we >> > reload a game- it would be great if Rails just remembered our last >> > window >> > placements for each title (or, game), and little desktop stuff like >> > that. >> > >> > best, >> > - jim >> > >> > >> > >> > >> > >> > --------------------------------------------------------------------------- >> > --- This SF.net email is sponsored by >> > >> > Make an app they can't live without >> > Enter the BlackBerry Developer Challenge >> > http://p.sf.net/sfu/RIM-dev2dev >> > _______________________________________________ >> > Rails-devel mailing list >> > Rai...@li... >> > https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> >> ------------------------------------------------------------------------------ >> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program >> Be part of this innovative community and reach millions of netbook users >> worldwide. Take advantage of special opportunities to increase revenue and >> speed time-to-market. Join now, and jumpstart your future. >> http://p.sf.net/sfu/intel-atom-d2d >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Chris S. <chr...@gm...> - 2010-08-25 21:50:52
|
When will the new release be available? -- Chris Please consider the environment before printing this e-mail. On Wed, Aug 25, 2010 at 2:48 PM, Stefan Frey <ste...@we...> wrote: > Jim: > thanks for your suggestion. > > It was a little late for the new release, but storing the UI layout it > was/is > already high on my list. There are some question to discuss due to Java > flexible approach to layout its components. But I admit that I have already > a > code snippet on my desktop pc which moves the Map window to the second > available screen. > > Let us discuss this in more depth as soon as the dust after the new release > has settled, which might/will introduce other bugs/suggestions. > > Stefan > > On Thursday, August 19, 2010 08:12:25 pm Jim Black wrote: > > I noticed that there's been substantial effort to add a > > configuration/properties system to Rails, and also look forward to seeing > > this in the next update. > > > > (I think the most critical update is the fix of the > diesel-upgrade/tradein > > bug, fwiw- we always need to downgrade to 1.2.2 when the diesels come > > out, which disables the most useful/difficult phase of 1.3's automated > > route-calculation.) > > > > Along the lines of user preferences and properties, here's some more > > comments re: differences from a pbem user to a hotseat/moderator user-- > > > > - I load pbem Rails games, from my dropbox, all day. The usage pattern > is: > > launch rails, load game file (the last two can be munged), make move, > > save game file, exit rails. > > > > ==> Note that loading/exiting rails for each game is awkward (and > > unusual)- I'd rather leave it running all day- loading games as they're > > updated, saving & moving on to the next game, etc. > > > > - Also, once I load a game within Rails, I repeat my next sequence of > > operations too: I open most of the separate Rails game windows (map, > > stock-chart, report window), and, resize and position these windows for > my > > current display. > > > > ==> Note that having to reconfigure my desktop for each game is also > > awkward- I wish Rails maintained a record of my last window layout for > > each title/game- and. defaulted to that, when I [re-]load that > title/game. > > > > For extra credit, it should keep separate copies for different display > > sizes- during the day, we may switch computers, or, we may simply switch > a > > laptops from the builtin display, to a larger external display. (These > > things directly affect the way we config our windows, for each particular > > title.) > > > > There's nothing magic about any of this- but the awkward thing is, we > have > > to repeat these exact little steps, /all day long/, in many standalone > > Rails sessions. It gets tedious to do these same tweaks every time we > > reload a game- it would be great if Rails just remembered our last window > > placements for each title (or, game), and little desktop stuff like that. > > > > best, > > - jim > > > > > > > > > > > --------------------------------------------------------------------------- > > --- This SF.net email is sponsored by > > > > Make an app they can't live without > > Enter the BlackBerry Developer Challenge > > http://p.sf.net/sfu/RIM-dev2dev > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Stefan F. <ste...@we...> - 2010-08-25 21:48:26
|
Jim: thanks for your suggestion. It was a little late for the new release, but storing the UI layout it was/is already high on my list. There are some question to discuss due to Java flexible approach to layout its components. But I admit that I have already a code snippet on my desktop pc which moves the Map window to the second available screen. Let us discuss this in more depth as soon as the dust after the new release has settled, which might/will introduce other bugs/suggestions. Stefan On Thursday, August 19, 2010 08:12:25 pm Jim Black wrote: > I noticed that there's been substantial effort to add a > configuration/properties system to Rails, and also look forward to seeing > this in the next update. > > (I think the most critical update is the fix of the diesel-upgrade/tradein > bug, fwiw- we always need to downgrade to 1.2.2 when the diesels come > out, which disables the most useful/difficult phase of 1.3's automated > route-calculation.) > > Along the lines of user preferences and properties, here's some more > comments re: differences from a pbem user to a hotseat/moderator user-- > > - I load pbem Rails games, from my dropbox, all day. The usage pattern is: > launch rails, load game file (the last two can be munged), make move, > save game file, exit rails. > > ==> Note that loading/exiting rails for each game is awkward (and > unusual)- I'd rather leave it running all day- loading games as they're > updated, saving & moving on to the next game, etc. > > - Also, once I load a game within Rails, I repeat my next sequence of > operations too: I open most of the separate Rails game windows (map, > stock-chart, report window), and, resize and position these windows for my > current display. > > ==> Note that having to reconfigure my desktop for each game is also > awkward- I wish Rails maintained a record of my last window layout for > each title/game- and. defaulted to that, when I [re-]load that title/game. > > For extra credit, it should keep separate copies for different display > sizes- during the day, we may switch computers, or, we may simply switch a > laptops from the builtin display, to a larger external display. (These > things directly affect the way we config our windows, for each particular > title.) > > There's nothing magic about any of this- but the awkward thing is, we have > to repeat these exact little steps, /all day long/, in many standalone > Rails sessions. It gets tedious to do these same tweaks every time we > reload a game- it would be great if Rails just remembered our last window > placements for each title (or, game), and little desktop stuff like that. > > best, > - jim > > > > > --------------------------------------------------------------------------- > --- This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Stefan F. <ste...@we...> - 2010-08-25 21:42:55
|
Erik:
other implementation details follow here as they arose from to the topic in
the subject:
I have added two new state classes: ArrayListState and HashMapState, that
create ModelObjects, which use the already defined Move classes for changes of
ArrayLists and HashMaps. It basically wraps the ModelObject/State around
standard ArrayLists and HashMaps and uses the standard method names to
manipulate them. In principle it would be possible to fully implement the
Map/List interfaces, but I was too lazy to write all required methods for
that.
My reason for adding those is that at least for the approach above protects
against accidentally using the non-move methods on list or maps, which are in
fact stateful and thus require the moves instead. And I still prefer using the
standard syntax stateList.add(object) instead of new AddToList("NameOfList",
stateList, object). And it allows to create more complicated operations using
the atomic moves (for example addAll or initFromMap). It is possible to
retrieve the wrapped list/map as an unmodifiable view.
This allowed fixing the opertingCompanies bug in 1856 and the tilesPerColour
problem in 18EU.
Currently they do not inherit from neither ModelObject/State as the current
usage has not required them to do so. But it is possible to do so, but I would
prefer to inherit from ModelObject directly.
If you do not mind I would like to add an according HashSetState class and
replace BooleanState, IntegerState and StringState with more specialized
versions that inherit from ModelObject instead of State and have according
simple Moves (BooleanChange, IntegerChange, StringChange) and it would allow
to introduce an easier syntax, for example for boolean: booleanVar.set(true)
or booleanVar.set(false) and booleanVar.is() or booleanVar.isNot()
This would also allow to deprecate (and remove later) the State class,as there
is already a replacement available with GenericState. All those changes make
the StateI interface unnecessary. It could still be used as a mere marker
interface or have the getName() function at most.
Stefan
On Monday, August 16, 2010 10:48:07 pm Erik Vos wrote:
> Stefan,
>
> I'll come back to your remarks later this week. I do have thoughts on these
> matters, but no time right now.
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday 16 August 2010 21:46
> To: 'Development list for Rails: an 18xx game'
> Subject: [Rails-devel] Some (multi-)undo related bugs
>
> A rather longish discussion of implementation details to follow. Mainly
> information for Erik.
> Stefan
>
> A side-effect of the new game history is that it allows to jump around
> between
> very different game states, switching round types and phases on the fly.
> This acts as a advanced test on the undo mechanism and overall it works
> very
>
> well. However there are still some bugs to discover, which might also act
> as
>
> examples to avoid confusing the undo/redo mechanism:
>
> * The toolTip on hexes was not updated correctly after undo/redos (still
> showing the tile information from the previous state), as the update was
> controlled only by the tile/token lay UI classes and not the game backend.
> I shortly considered a ToolTipModel approach, but I realized that is much
> easier to update the toolTip at the time it is requested by the user.
> I would still like to move the code to create the toolTip string from the
> UI
>
> GUIHex class to the game MapHex class to reduce the amount of processing
> and
>
> calls to the game classes from the UI class.
> Or is there a reason to avoid that, Erik?
> It seems to me that now all UI elements update correctly after undo (I
> recently added a PresidentModel to update the president column).
>
> * A more subtle problem arose from a 18EU test: After going back from a
> major
> turns to a minor ones during the green phase, the minor was suddenly
> allowed
>
> to lay a green tile.
> This occured as the tileLayPerColour state change triggers a call to the
> operatingCompany variable inside the OperatingRound instance. This
> variable
>
> itself however is not a state variable itself, but gets only initialized
> from
> the state variable operatingCompanyObject at the begin of the companies'
> action generation. Thus during the undo Rails assume that the
> tileLayPerColour
> request is still for the major company, as the operatingRound is not
> updated.
>
> I admit that I have introduced the operatingCompanyObject myself and did
> not
>
> think about this problem at that time: The lesson to learn here is to
> strongly
> avoid working with non-state variables, which simply contain a reference to
> a
> state variable. This is an wide open door for bugs & troubles a long time
> later.
> Either use the state variable directly or encapsulate it to a method call,
> if
> the state mechanism seems to unwieldy.
>
> ---------------------------------------------------------------------------
> - --
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
> --- This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Stefan F. <ste...@we...> - 2010-08-25 21:14:03
|
Erik: some comments about details of my last week changes for the upcoming release: I used the opportunity of your changes which made it pretty easy to fix another issue with bankruptcy: The cash position of the bankrupt player was included in the total value after the (immediate) game end. As the train purchase was not executed, it was usually a substantial amount as it included cash generated by the forced selling. Stefan On Saturday, August 21, 2010 09:42:06 pm you wrote: > Fixed another long-standing bug. > > Erik. > > -----Original Message----- > From: ste...@we... [mailto:ste...@we...] > Sent: Tuesday 08 June 2010 23:36 > To: Erik Vos > Subject: 18EU bankruptcy > > Erik, > I had a test file that allowed an easy test for bankruptcy. > By chance it occured for the last company before the next SR and the final > minor exchange round. In that case the game stalls. > In other scenarios the bankrupcty code works. > Find the game files attached (before - simply buy the 5 train and after). > Stefan |
|
From: Stefan F. <ste...@we...> - 2010-08-23 21:51:17
|
Hi Arne, some good news here: This bug is already fixed in the next release, which is already is finished and only awaits the final build and package. I checked your save file and it will be fully loadable. Happy gaming, Stefan Frey On Sunday, August 22, 2010 07:19:45 pm Arne Östlund wrote: > Hi > > We play a game of 1889 PBeM. When TR (Brad) exchanged a T4 for a TD the > game stalls. He saved a file for me IR (Arne). I did my move with IR and > saved it for KU (Kevin). But when we load that file (attached with this > mail) it is still at TR and he has to buy a TD. I have attached all files > saved from Brad and on. > > /Arne Östlund |
|
From: Erik V. <eri...@xs...> - 2010-08-21 19:42:08
|
Fixed another long-standing bug. Erik. -----Original Message----- From: ste...@we... [mailto:ste...@we...] Sent: Tuesday 08 June 2010 23:36 To: Erik Vos Subject: 18EU bankruptcy Erik, I had a test file that allowed an easy test for bankruptcy. By chance it occured for the last company before the next SR and the final minor exchange round. In that case the game stalls. In other scenarios the bankrupcty code works. Find the game files attached (before - simply buy the 5 train and after). Stefan |
|
From: Stefan F. <ste...@we...> - 2010-08-21 07:08:19
|
To close the missing implementation detail I rewrote the forced selling code: It now protects against selling the presidency of the operating company and adds an option in game.xml to protect against selling of the presidency of any other company the player owns. The option is a child of the EndOfGame tag : <ForcedSelling CompanyDump="no"/> and is set for 1889. Questions for those who know better/more: - I assume that from the current list of games 1889 is the only that disallows selling any company presidency during forced sellling. - Anyone interested in a GameOption to allow playing 1889 forced selling according to the 1830 rules. - Forced selling also occurs on other occasions than train buying in Rails: 1856 has several cases related to loans and interest that can trigger forced selling. I assume that here another company can be dumped. - The case of dumping of a company which is the source of the train bought is not covered by the code specifically. I do not have a test case, but I suspect that company dump is possible in that case. This is a disputed case and I support the case that this is not possible (at least without consent of the new president), but if my guess is correct, the current strategy space allows all playing all variants. Stefan |
|
From: Erik V. <eri...@xs...> - 2010-08-19 20:19:45
|
Stefan, I remember Brett also once proposed Jabber to be used in the way you suggest. That certainly seems a viable solution to me, and much easier to achieve than mine; whether or not internet-play development would end there, I don't know. In any case, in your approach it doesn't matter much in which way the UI gets updated. And, as I already said, the tooltips can be done in any way. Although the current Rails Model/View implementation allows pulling, I don't see the added value of it when only used that way. Its strength is enabling the push through the Observable/Observer pattern. For pulling, a direct (or, perhaps in the future: remote) method call works just as well. In other words, I only see value in a separate ToolTipModel if the tooltips are pushed. And even then, why not have the existing MapHex model do the same job? It's already there, waiting for you to be enhanced... Just my ideas, all this; I don't want to keep you from doing Good Things your way. However, discussions like these, which I very much appreciate, might help to prevent us drifting apart too much... :-) Erik. -----Original Message----- From: Stefan Frey [mailto:ste...@we...] Sent: Wednesday 18 August 2010 23:52 To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] Some (multi-)undo related bugs Erik: thanks for outlining your approach. What makes things difficult to discuss, but easier to implement is the fact, that Rails has an additional layer of explicit models for the UI, which transform the game elements in something more digestible for the Take the example of shares, for which the ShareModel combines the information of the certificate portfolios. Something similar would be a ToolTipModel that generates toolTip String from the deeper game model elements. This was my motiviation to suggest the move of the generation of the ToolTip text to the game(.model) classes. I am very much agnostic, how the information is passed around between client/server model/UI, any of your solutions is a valid one. In the case of ToolTip it seems to me that the pull approach is efficient. One could even start pulling the data as soon as a user hoovers over a hex, the ToolTip display is already delayed by definition. My vision for online play currently is not a split in remote clients and a centralized server, but rather have each player a client/server combination locally (similar to what we have now) and merely pass around the actions between the server instances. Each client than still gets update from the local server instance, thus keeping network traffic at a minimum. My current idea is to use the XMPP(rotocol), better known as Jabber, which allows to pass around serialized objects or xml/json messages with existing Java libraries (e.g. Smack). This would strongly leverage on existing infrastructure. Again a rather long text for such a simple fix ;-) Stefan On Wednesday, August 18, 2010 11:06:49 pm Erik Vos wrote: > * The toolTip on hexes was not updated correctly after undo/redos (still > showing the tile information from the previous state), as the update was > controlled only by the tile/token lay UI classes and not the game backend. > I shortly considered a ToolTipModel approach, but I realized that is much > easier to update the toolTip at the time it is requested by the user. > I would still like to move the code to create the toolTip string from the > UI > > GUIHex class to the game MapHex class to reduce the amount of processing > and > > calls to the game classes from the UI class. > Or is there a reason to avoid that, Erik? > > [EV] Let me restate the long-term architectural goal (which surely is no > news to you): that one day Rails should support client-server operation, > where one client per player communicates real-time with a central server > over the Internet. Although we are not very close to reaching this goal, I > always use it as a background for any architectural decisions. I want to > work towards it, not away from it. > > In this concept, the client (UI) can obtain any info it needs for display > in three different ways: > > (1) All static info can be obtained from the objects after these have been > initialised as is done currently. This occurs independently in both client > and server. > (IIRC Brett once made a case to push all static info from server to client > as well as the dynamic info mentioned below. I would that cosnsider that a > more extreme vision than mine, and certainly possible, but it'll probably > be a further development). > > Any dynamic (state) info is not directly accessible to the client. As far > as the client needs it for display, it can get such info in two ways: > > (2) By having dynamic info be pushed from the server to the client (by > sending that info to connected clients, or queueing it for disconnected > clients). This should happen with all information that must be displayed by > all clients alike: tiles, tokens, money, shares, messages etc. Basically > this amounts to all dynamic info that the GUI needs. This server push has > already been implemented for a large part of that info, but certainly not > yet for all of it. > > (3) By having dynamic info be pulled by the client from the server. > Currently this is done in many cases by direct server method calls, as > Rails originally did for all such info. I think we should continue to get > away from that. Network latency and the need to keep all clients on the > same footing are just two reasons why I find this unattractive. We might > encounter exceptional cases that where this approach would be a good > solution, but I don't think there will be many such cases. > > -- > > What does this mean for the tooltips? > > Once the UI knows which tiles and tokens are laid in what locations and > positions, almost all tooltip info is static and can be composed from > locally available data as in approach (1). I think the only missing bit is > the current phase (for the offboard revenue values). > > Getting to know about tiles and tokens is a bit tricky. Tile info is > already pushed via approach (2) (see GUIHex.update()). This is not the > case for tokens yet, for which the server is pulled (3) when a tile is > (re-)drawn (see, for instance, GUIHex.paintStationTokens()). The latter > process obviously needs to be replaced by a server-push driven one (2). > > The current phase is currently also pulled (3), but, as all clients need > it, it will also have to be server-pushed (2). We probably need a phase > model. > > My conclusion is, that in the end it will be possible to compose the > tooltips in the UI only (1), and that there is no real need to involve the > server. But to get the tooltips right now, I concur with your proposal that > tooltips can best be created when requested by the user. For now it will be > acceptable to call the server, if possible via a common interface that is > also used by the drawing code. As said, later on all info will be locally > available after being pushed by the server. > > Other approaches are feasible. In (2) the tooltips would be composed in the > server, and pushed by MapHex on any change. The catch is, that we should be > careful not to oversee cases when the text must change: all such cases > should trigger all relevant MapHex models to update their views. That's > added complexity I'd rather avoid. > > In this particular case, even method (3) might be an option, because > tooltips only need to be displayed on request. However, I fear that the > slower tooltip appearance (because of latency) could be a bit annoying. I > don't think we should go this way. > > My opinion therefore is, that we should leave tooltip composition in the UI > (but fix it as discussed). ---------------------------------------------------------------------------- -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Jim B. <ji...@ko...> - 2010-08-19 18:12:34
|
I noticed that there's been substantial effort to add a configuration/properties system to Rails, and also look forward to seeing this in the next update. (I think the most critical update is the fix of the diesel-upgrade/tradein bug, fwiw- we always need to downgrade to 1.2.2 when the diesels come out, which disables the most useful/difficult phase of 1.3's automated route-calculation.) Along the lines of user preferences and properties, here's some more comments re: differences from a pbem user to a hotseat/moderator user-- - I load pbem Rails games, from my dropbox, all day. The usage pattern is: launch rails, load game file (the last two can be munged), make move, save game file, exit rails. ==> Note that loading/exiting rails for each game is awkward (and unusual)- I'd rather leave it running all day- loading games as they're updated, saving & moving on to the next game, etc. - Also, once I load a game within Rails, I repeat my next sequence of operations too: I open most of the separate Rails game windows (map, stock-chart, report window), and, resize and position these windows for my current display. ==> Note that having to reconfigure my desktop for each game is also awkward- I wish Rails maintained a record of my last window layout for each title/game- and. defaulted to that, when I [re-]load that title/game. For extra credit, it should keep separate copies for different display sizes- during the day, we may switch computers, or, we may simply switch a laptops from the builtin display, to a larger external display. (These things directly affect the way we config our windows, for each particular title.) There's nothing magic about any of this- but the awkward thing is, we have to repeat these exact little steps, /all day long/, in many standalone Rails sessions. It gets tedious to do these same tweaks every time we reload a game- it would be great if Rails just remembered our last window placements for each title (or, game), and little desktop stuff like that. best, - jim |
|
From: Stefan F. <ste...@we...> - 2010-08-18 21:52:30
|
Erik: thanks for outlining your approach. What makes things difficult to discuss, but easier to implement is the fact, that Rails has an additional layer of explicit models for the UI, which transform the game elements in something more digestible for the Take the example of shares, for which the ShareModel combines the information of the certificate portfolios. Something similar would be a ToolTipModel that generates toolTip String from the deeper game model elements. This was my motiviation to suggest the move of the generation of the ToolTip text to the game(.model) classes. I am very much agnostic, how the information is passed around between client/server model/UI, any of your solutions is a valid one. In the case of ToolTip it seems to me that the pull approach is efficient. One could even start pulling the data as soon as a user hoovers over a hex, the ToolTip display is already delayed by definition. My vision for online play currently is not a split in remote clients and a centralized server, but rather have each player a client/server combination locally (similar to what we have now) and merely pass around the actions between the server instances. Each client than still gets update from the local server instance, thus keeping network traffic at a minimum. My current idea is to use the XMPP(rotocol), better known as Jabber, which allows to pass around serialized objects or xml/json messages with existing Java libraries (e.g. Smack). This would strongly leverage on existing infrastructure. Again a rather long text for such a simple fix ;-) Stefan On Wednesday, August 18, 2010 11:06:49 pm Erik Vos wrote: > * The toolTip on hexes was not updated correctly after undo/redos (still > showing the tile information from the previous state), as the update was > controlled only by the tile/token lay UI classes and not the game backend. > I shortly considered a ToolTipModel approach, but I realized that is much > easier to update the toolTip at the time it is requested by the user. > I would still like to move the code to create the toolTip string from the > UI > > GUIHex class to the game MapHex class to reduce the amount of processing > and > > calls to the game classes from the UI class. > Or is there a reason to avoid that, Erik? > > [EV] Let me restate the long-term architectural goal (which surely is no > news to you): that one day Rails should support client-server operation, > where one client per player communicates real-time with a central server > over the Internet. Although we are not very close to reaching this goal, I > always use it as a background for any architectural decisions. I want to > work towards it, not away from it. > > In this concept, the client (UI) can obtain any info it needs for display > in three different ways: > > (1) All static info can be obtained from the objects after these have been > initialised as is done currently. This occurs independently in both client > and server. > (IIRC Brett once made a case to push all static info from server to client > as well as the dynamic info mentioned below. I would that cosnsider that a > more extreme vision than mine, and certainly possible, but it'll probably > be a further development). > > Any dynamic (state) info is not directly accessible to the client. As far > as the client needs it for display, it can get such info in two ways: > > (2) By having dynamic info be pushed from the server to the client (by > sending that info to connected clients, or queueing it for disconnected > clients). This should happen with all information that must be displayed by > all clients alike: tiles, tokens, money, shares, messages etc. Basically > this amounts to all dynamic info that the GUI needs. This server push has > already been implemented for a large part of that info, but certainly not > yet for all of it. > > (3) By having dynamic info be pulled by the client from the server. > Currently this is done in many cases by direct server method calls, as > Rails originally did for all such info. I think we should continue to get > away from that. Network latency and the need to keep all clients on the > same footing are just two reasons why I find this unattractive. We might > encounter exceptional cases that where this approach would be a good > solution, but I don't think there will be many such cases. > > -- > > What does this mean for the tooltips? > > Once the UI knows which tiles and tokens are laid in what locations and > positions, almost all tooltip info is static and can be composed from > locally available data as in approach (1). I think the only missing bit is > the current phase (for the offboard revenue values). > > Getting to know about tiles and tokens is a bit tricky. Tile info is > already pushed via approach (2) (see GUIHex.update()). This is not the > case for tokens yet, for which the server is pulled (3) when a tile is > (re-)drawn (see, for instance, GUIHex.paintStationTokens()). The latter > process obviously needs to be replaced by a server-push driven one (2). > > The current phase is currently also pulled (3), but, as all clients need > it, it will also have to be server-pushed (2). We probably need a phase > model. > > My conclusion is, that in the end it will be possible to compose the > tooltips in the UI only (1), and that there is no real need to involve the > server. But to get the tooltips right now, I concur with your proposal that > tooltips can best be created when requested by the user. For now it will be > acceptable to call the server, if possible via a common interface that is > also used by the drawing code. As said, later on all info will be locally > available after being pushed by the server. > > Other approaches are feasible. In (2) the tooltips would be composed in the > server, and pushed by MapHex on any change. The catch is, that we should be > careful not to oversee cases when the text must change: all such cases > should trigger all relevant MapHex models to update their views. That's > added complexity I'd rather avoid. > > In this particular case, even method (3) might be an option, because > tooltips only need to be displayed on request. However, I fear that the > slower tooltip appearance (because of latency) could be a bit annoying. I > don't think we should go this way. > > My opinion therefore is, that we should leave tooltip composition in the UI > (but fix it as discussed). |
|
From: Erik V. <eri...@xs...> - 2010-08-18 21:06:54
|
* The toolTip on hexes was not updated correctly after undo/redos (still showing the tile information from the previous state), as the update was controlled only by the tile/token lay UI classes and not the game backend. I shortly considered a ToolTipModel approach, but I realized that is much easier to update the toolTip at the time it is requested by the user. I would still like to move the code to create the toolTip string from the UI GUIHex class to the game MapHex class to reduce the amount of processing and calls to the game classes from the UI class. Or is there a reason to avoid that, Erik? [EV] Let me restate the long-term architectural goal (which surely is no news to you): that one day Rails should support client-server operation, where one client per player communicates real-time with a central server over the Internet. Although we are not very close to reaching this goal, I always use it as a background for any architectural decisions. I want to work towards it, not away from it. In this concept, the client (UI) can obtain any info it needs for display in three different ways: (1) All static info can be obtained from the objects after these have been initialised as is done currently. This occurs independently in both client and server. (IIRC Brett once made a case to push all static info from server to client as well as the dynamic info mentioned below. I would that cosnsider that a more extreme vision than mine, and certainly possible, but it'll probably be a further development). Any dynamic (state) info is not directly accessible to the client. As far as the client needs it for display, it can get such info in two ways: (2) By having dynamic info be pushed from the server to the client (by sending that info to connected clients, or queueing it for disconnected clients). This should happen with all information that must be displayed by all clients alike: tiles, tokens, money, shares, messages etc. Basically this amounts to all dynamic info that the GUI needs. This server push has already been implemented for a large part of that info, but certainly not yet for all of it. (3) By having dynamic info be pulled by the client from the server. Currently this is done in many cases by direct server method calls, as Rails originally did for all such info. I think we should continue to get away from that. Network latency and the need to keep all clients on the same footing are just two reasons why I find this unattractive. We might encounter exceptional cases that where this approach would be a good solution, but I don't think there will be many such cases. -- What does this mean for the tooltips? Once the UI knows which tiles and tokens are laid in what locations and positions, almost all tooltip info is static and can be composed from locally available data as in approach (1). I think the only missing bit is the current phase (for the offboard revenue values). Getting to know about tiles and tokens is a bit tricky. Tile info is already pushed via approach (2) (see GUIHex.update()). This is not the case for tokens yet, for which the server is pulled (3) when a tile is (re-)drawn (see, for instance, GUIHex.paintStationTokens()). The latter process obviously needs to be replaced by a server-push driven one (2). The current phase is currently also pulled (3), but, as all clients need it, it will also have to be server-pushed (2). We probably need a phase model. My conclusion is, that in the end it will be possible to compose the tooltips in the UI only (1), and that there is no real need to involve the server. But to get the tooltips right now, I concur with your proposal that tooltips can best be created when requested by the user. For now it will be acceptable to call the server, if possible via a common interface that is also used by the drawing code. As said, later on all info will be locally available after being pushed by the server. Other approaches are feasible. In (2) the tooltips would be composed in the server, and pushed by MapHex on any change. The catch is, that we should be careful not to oversee cases when the text must change: all such cases should trigger all relevant MapHex models to update their views. That's added complexity I'd rather avoid. In this particular case, even method (3) might be an option, because tooltips only need to be displayed on request. However, I fear that the slower tooltip appearance (because of latency) could be a bit annoying. I don't think we should go this way. My opinion therefore is, that we should leave tooltip composition in the UI (but fix it as discussed). -- A separate issue is, that the tooltips currently aren't multi-lingual. IMO that should change. -- Talking about internet play and multi-linguality: I envisage that clients playing the same game could use different languages. This would mean, that all multi-linguality must ultimately be achieved in the client/UI anyway, not in the server/game-engine. Each message will then be pushed as a keyword with its parameter values rather than as full text. -- Sorry that this response to only one of Stefan's questions was even longer than his whole message. But in any case now you all know what I might (or might not) find myself working on after I have retired next year, if not implementing new 18xx games, or doing other interesting things.... Erik. |
99 messages has been excluded from this view by a project administrator.
