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: <ab...@o2...> - 2011-03-30 05:31:07
|
I will but most likely in about 10-16 hours as I'm at work now and later I will be busy. Adam Badura -----Oryginalna wiadomość----- From: brett lentz Sent: Wednesday, March 30, 2011 7:28 AM To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] NullPointerException after changes atrevisions1501-1503 Can you post the stack trace from the NPE? That would make seeing where it went wrong a lot easier. ---Brett. On Tue, Mar 29, 2011 at 10:27 PM, <ab...@o2...> wrote: > I got those exceptions when loading game by command line argument. Nothing > more specific. > > I do have some local changes but those are new Batik version and some map > drawing changes. Both seem totally unconnected to the origin of the > exception. > > Adam Badura > > -----Oryginalna wiadomość----- > From: Bill Rosgen > Sent: Wednesday, March 30, 2011 4:01 AM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] NullPointerException after changes at > revisions1501-1503 > > On 2011-03-30, at 5:26 , Adam Badura wrote: > >> In the attachement a two .rails save files which opened correctly at >> revision 1500 and now they no longer open at revision 1503. >> Loading the game results in NullPointerException thrown at place >> suggesting privates changes. >> > > Can you provide more information? Both of these files seem to work on my > machine using revision 1503. Do you get the exception when loading the > files, or is there something more specific that I have to do to cause it? > > Bill > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: brett l. <bre...@gm...> - 2011-03-30 05:29:23
|
Can you post the stack trace from the NPE? That would make seeing where it went wrong a lot easier. ---Brett. On Tue, Mar 29, 2011 at 10:27 PM, <ab...@o2...> wrote: > I got those exceptions when loading game by command line argument. Nothing > more specific. > > I do have some local changes but those are new Batik version and some map > drawing changes. Both seem totally unconnected to the origin of the > exception. > > Adam Badura > > -----Oryginalna wiadomość----- > From: Bill Rosgen > Sent: Wednesday, March 30, 2011 4:01 AM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] NullPointerException after changes at > revisions1501-1503 > > On 2011-03-30, at 5:26 , Adam Badura wrote: > >> In the attachement a two .rails save files which opened correctly at >> revision 1500 and now they no longer open at revision 1503. >> Loading the game results in NullPointerException thrown at place >> suggesting privates changes. >> > > Can you provide more information? Both of these files seem to work on my > machine using revision 1503. Do you get the exception when loading the > files, or is there something more specific that I have to do to cause it? > > Bill > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: <ab...@o2...> - 2011-03-30 05:27:48
|
I got those exceptions when loading game by command line argument. Nothing more specific. I do have some local changes but those are new Batik version and some map drawing changes. Both seem totally unconnected to the origin of the exception. Adam Badura -----Oryginalna wiadomość----- From: Bill Rosgen Sent: Wednesday, March 30, 2011 4:01 AM To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] NullPointerException after changes at revisions1501-1503 On 2011-03-30, at 5:26 , Adam Badura wrote: > In the attachement a two .rails save files which opened correctly at > revision 1500 and now they no longer open at revision 1503. > Loading the game results in NullPointerException thrown at place > suggesting privates changes. > Can you provide more information? Both of these files seem to work on my machine using revision 1503. Do you get the exception when loading the files, or is there something more specific that I have to do to cause it? Bill ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Bill R. <ro...@gm...> - 2011-03-30 02:01:23
|
On 2011-03-30, at 5:26 , Adam Badura wrote: > In the attachement a two .rails save files which opened correctly at revision 1500 and now they no longer open at revision 1503. > Loading the game results in NullPointerException thrown at place suggesting privates changes. > Can you provide more information? Both of these files seem to work on my machine using revision 1503. Do you get the exception when loading the files, or is there something more specific that I have to do to cause it? Bill |
From: Erik V. <eri...@xs...> - 2011-03-29 13:29:42
|
Thanks! I have applied the patch and done limited testing with 1830 and 18AL. Looks fine; also the B&O private is no longer for sale. I also see that you have left in the old <CanBuyPrivates> tag (although it is now empty). I had not expected that, but I believe you're right: we need to be able to restrict the ability to buy privates to certain company types. I wonder if any games exist where we would need to exclude certain companies from this inclusion per company type; if so, we should probably somehow tweak this old tag to allow yes/no. Well done. Erik. > -----Oorspronkelijk bericht----- > Van: Bill Rosgen [mailto:ro...@gm...] > Verzonden: dinsdag 29 maart 2011 7:07 > Aan: Development list for Rails: an 18xx game > Onderwerp: Re: [Rails-devel] B&O PC Sale > > Here is a patch to implement <Tradeable> tags. I've moved all of the code > dealing with private buy-in prices into the PrivateCompany class (which > required modifying OperatingRound to get the prices from the right place). > I've also updated all of the game XML files that used the old method. This > change should also correctly prevent the B&O from being sold to a company. > I've tested 1830, 18AL, and the 1848 implementation that I am working on, > and they all seem to work. > > The syntax is as described by Erik: > > To specify a standard 1830-style private (in the CompanyType tag): > <Tradeable toCompany="yes" lowerPriceFactor="0.5" > upperPriceFactor="2.0"/> > > To make a private not tradeable to a company: > <Tradeable toCompany="no"/> > > To specify explicit min and max prices: > <Tradeable toCompany="yes" lowerPrice="1" upperPrice="40"/> > > To mark a private as sellable to another player (not yet implemented in rails, > but the private company can be told about it): > <Tradeable toPlayer="yes"/> > > Prices (or PriceFactors) specified within a tag apply only to the case(s) > specified, i.e. it's possible to have two lines that specify different prices for > different sale types, i.e.: > <Tradeable toCompany="yes" lowerPriceFactor="0.5" > upperPriceFactor="2.0"/> <Tradeable toPlayer="yes" lowerPrice="1"/> > > Any prices not specified are set to a flag PrivateCompanyI.NO_PRICE_LIMIT, > which are interpreted by OperatingRound as either 0 for a lowerPrice or the > current company treasury for an upperPrice. I'm not sure that this is the best > way to implement this: suggestions are welcome. > > Prices can be set using a mix, i.e. > <Tradeable toCompany="yes" lowerPrice="1" upperPriceFactor="2.0"/> If > over-specified, the attributes lowerPrice and upperPrice take precedence. > > I can move all of this to the Company class if desired (this should be easy), > but to my knowledge no one is currently working on a game that would use > this. > > (Hopefully the patch is well-formed: I don't have a lot of experience with > Eclipse.) > > Bill > |
From: Rick W. <wes...@pu...> - 2011-03-29 13:00:03
|
----- Original Message ----- > ----- Original Message ----- > > I have committed phase one of the AutoSave/Load feature. > > > > Does not work for me. Trying as two-player 1830 using a PC and a Mac > via Dropbox. The first player, no matter if the PC or the Mac, does > not automatically autoload. I.e., no popup. The second player does get > a popup (after the first player manually does as reload and then takes > his turn.) Redoing autoload/save as 1st player does not help. > > I might experiment some more but wanted to share my first impressions. > OK. I have it working. Sort of. The key is to: 1) Have the initial player follow the steps below. 2) Have the second player follow the steps. 3) Have the initial (first) play quit Rails and then start up as if he was a Nth player. In other words a person has to do a set up of the game and then, instead of continuing right away, quit and rejoin the game as a player. Not a big hassle but something to be aware of. Now the "sort of" part. The initial auction in 1830 works fine. However the SR does not in that once you press 'done' the yellow-tint of who is the next player does not change. Pressing 'done' again brings up a dialog box that says something like "the done button can not be used at this time". In other words the 'done' action has already been taken. Thus it becomes hard to tell whose turn it is. Similar in the OR where the yellow-tint of the current player does not change. The above should be obvious, I hope, if you test out the SR and OR. I hope that this is an easy change to make. -- Rick > > > > > It works as follows: > > > > 1. First player: > > 1a. Start game > > 1b. Select File | AutoSave/Load, and select On. You can also change > > the > > polling interval. Press OK. > > 1c. You will get the standard Save popup. Here you can navigate to > > the > > autosave/load directory (e.g. Dropbox) you want to use. > > [in a later version you will also be able to change the Prefix, > > which > > is > > everything in front of the first underscore in the filename. > > Normally > > the > > prefix only contains the game name, but you can put anything there, > > for > > instance a code like 1830A1, as some zines do to distinguish actual > > games.] > > 1d. Do your moves, until the end of your turn. Then the game will be > > saved > > automatically. You will see some fields deactivate (turn white), but > > I > > haven't yet made that consistent (in fact, I have only tested with > > the > > 1830 > > StartRound yet). > > 1e. When it is your turn again, a (non-modal) popup comes up, and > > you > > will > > see the appropriate fields in the active window get reactivated. > > [I'll probably make this configurable later, and add a configurable > > beep > > too]. > > > > 2. Other players: > > 2a. Load the game saved by the first player. > > 2b. Same as 1b. > > 2c. Same as 1c. This step is completely redundant, and will be > > removed > > in a > > later stage (at the point where this happens, the code does not know > > how the > > game was started. This needs be added). For now, please just click > > OK. > > 2d/e. Same as 1d/e. > > > > The procedure for the other players (2a-e) is a bit awkward. I plan > > to > > change this later so, that any subsequent player only needs to load > > the > > <prefix>.last_rails file that contains the name of the last saved > > file. > > AutoSave/Load would then be started automatically. The goal is to > > merge > > steps 2a-2b into one (and remove 2c). > > > > If you want a first look, please give it a try. > > > > Erik. > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet > the > growing manageability and security demands of your customers. > Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your > software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel -- Rick Westerman wes...@pu... Bioinformatics specialist at the Genomics Facility. Phone: (765) 494-0505 FAX: (765) 496-7255 Department of Horticulture and Landscape Architecture 625 Agriculture Mall Drive West Lafayette, IN 47907-2010 Physically located in room S049, WSLR building |
From: Erik V. <eri...@xs...> - 2011-03-29 09:11:54
|
Hmm. I tested 3-player (all from Eclipse on one PC) and that worked. However, I found that Autopass breaks autoload; not yet sure why. I'll try to do some more troubleshooting. Erik. > -----Oorspronkelijk bericht----- > Van: Rick Westerman [mailto:wes...@pu...] > Verzonden: dinsdag 29 maart 2011 4:23 > Aan: Development list for Rails: an 18xx game > Onderwerp: Re: [Rails-devel] Making Rails more suited to fast interactive > play. > > > > ----- Original Message ----- > > I have committed phase one of the AutoSave/Load feature. > > > > Does not work for me. Trying as two-player 1830 using a PC and a Mac via > Dropbox. The first player, no matter if the PC or the Mac, does not > automatically autoload. I.e., no popup. The second player does get a popup > (after the first player manually does as reload and then takes his turn.) > Redoing autoload/save as 1st player does not help. > > I might experiment some more but wanted to share my first impressions. > > On an unrelated note, I noticed that on the Mac when I transverse the > directory structure in order to change the place where the initial file is being > saved then the file name disappears. Does not happen on the PC. This is, > obviously, different file selection box (PC-oriented vs. Mac-oriented). Not a > big deal but interesting. > > > > > It works as follows: > > > > 1. First player: > > 1a. Start game > > 1b. Select File | AutoSave/Load, and select On. You can also change > > the polling interval. Press OK. > > 1c. You will get the standard Save popup. Here you can navigate to the > > autosave/load directory (e.g. Dropbox) you want to use. > > [in a later version you will also be able to change the Prefix, which > > is everything in front of the first underscore in the filename. > > Normally the prefix only contains the game name, but you can put > > anything there, for instance a code like 1830A1, as some zines do to > > distinguish actual games.] 1d. Do your moves, until the end of your > > turn. Then the game will be saved automatically. You will see some > > fields deactivate (turn white), but I haven't yet made that consistent > > (in fact, I have only tested with the > > 1830 > > StartRound yet). > > 1e. When it is your turn again, a (non-modal) popup comes up, and you > > will see the appropriate fields in the active window get reactivated. > > [I'll probably make this configurable later, and add a configurable > > beep too]. > > > > 2. Other players: > > 2a. Load the game saved by the first player. > > 2b. Same as 1b. > > 2c. Same as 1c. This step is completely redundant, and will be removed > > in a later stage (at the point where this happens, the code does not > > know how the game was started. This needs be added). For now, please > > just click OK. > > 2d/e. Same as 1d/e. > > > > The procedure for the other players (2a-e) is a bit awkward. I plan to > > change this later so, that any subsequent player only needs to load > > the <prefix>.last_rails file that contains the name of the last saved > > file. > > AutoSave/Load would then be started automatically. The goal is to > > merge steps 2a-2b into one (and remove 2c). > > > > If you want a first look, please give it a try. > > > > Erik. > > ---------------------------------------------------------------------------- -- > Enable your software for Intel(R) Active Management Technology to meet > the growing manageability and security demands of your customers. > Businesses are taking advantage of Intel(R) vPro (TM) technology - will your > software be a part of the solution? Download the Intel(R) Manageability > Checker today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Bill R. <ro...@gm...> - 2011-03-29 05:07:16
|
Here is a patch to implement <Tradeable> tags. I've moved all of the code dealing with private buy-in prices into the PrivateCompany class (which required modifying OperatingRound to get the prices from the right place). I've also updated all of the game XML files that used the old method. This change should also correctly prevent the B&O from being sold to a company. I've tested 1830, 18AL, and the 1848 implementation that I am working on, and they all seem to work. The syntax is as described by Erik: To specify a standard 1830-style private (in the CompanyType tag): <Tradeable toCompany="yes" lowerPriceFactor="0.5" upperPriceFactor="2.0"/> To make a private not tradeable to a company: <Tradeable toCompany="no"/> To specify explicit min and max prices: <Tradeable toCompany="yes" lowerPrice="1" upperPrice="40"/> To mark a private as sellable to another player (not yet implemented in rails, but the private company can be told about it): <Tradeable toPlayer="yes"/> Prices (or PriceFactors) specified within a tag apply only to the case(s) specified, i.e. it's possible to have two lines that specify different prices for different sale types, i.e.: <Tradeable toCompany="yes" lowerPriceFactor="0.5" upperPriceFactor="2.0"/> <Tradeable toPlayer="yes" lowerPrice="1"/> Any prices not specified are set to a flag PrivateCompanyI.NO_PRICE_LIMIT, which are interpreted by OperatingRound as either 0 for a lowerPrice or the current company treasury for an upperPrice. I'm not sure that this is the best way to implement this: suggestions are welcome. Prices can be set using a mix, i.e. <Tradeable toCompany="yes" lowerPrice="1" upperPriceFactor="2.0"/> If over-specified, the attributes lowerPrice and upperPrice take precedence. I can move all of this to the Company class if desired (this should be easy), but to my knowledge no one is currently working on a game that would use this. (Hopefully the patch is well-formed: I don't have a lot of experience with Eclipse.) Bill |
From: Rick W. <wes...@pu...> - 2011-03-29 02:23:35
|
----- Original Message ----- > I have committed phase one of the AutoSave/Load feature. > Does not work for me. Trying as two-player 1830 using a PC and a Mac via Dropbox. The first player, no matter if the PC or the Mac, does not automatically autoload. I.e., no popup. The second player does get a popup (after the first player manually does as reload and then takes his turn.) Redoing autoload/save as 1st player does not help. I might experiment some more but wanted to share my first impressions. On an unrelated note, I noticed that on the Mac when I transverse the directory structure in order to change the place where the initial file is being saved then the file name disappears. Does not happen on the PC. This is, obviously, different file selection box (PC-oriented vs. Mac-oriented). Not a big deal but interesting. > It works as follows: > > 1. First player: > 1a. Start game > 1b. Select File | AutoSave/Load, and select On. You can also change > the > polling interval. Press OK. > 1c. You will get the standard Save popup. Here you can navigate to the > autosave/load directory (e.g. Dropbox) you want to use. > [in a later version you will also be able to change the Prefix, which > is > everything in front of the first underscore in the filename. Normally > the > prefix only contains the game name, but you can put anything there, > for > instance a code like 1830A1, as some zines do to distinguish actual > games.] > 1d. Do your moves, until the end of your turn. Then the game will be > saved > automatically. You will see some fields deactivate (turn white), but I > haven't yet made that consistent (in fact, I have only tested with the > 1830 > StartRound yet). > 1e. When it is your turn again, a (non-modal) popup comes up, and you > will > see the appropriate fields in the active window get reactivated. > [I'll probably make this configurable later, and add a configurable > beep > too]. > > 2. Other players: > 2a. Load the game saved by the first player. > 2b. Same as 1b. > 2c. Same as 1c. This step is completely redundant, and will be removed > in a > later stage (at the point where this happens, the code does not know > how the > game was started. This needs be added). For now, please just click OK. > 2d/e. Same as 1d/e. > > The procedure for the other players (2a-e) is a bit awkward. I plan to > change this later so, that any subsequent player only needs to load > the > <prefix>.last_rails file that contains the name of the last saved > file. > AutoSave/Load would then be started automatically. The goal is to > merge > steps 2a-2b into one (and remove 2c). > > If you want a first look, please give it a try. > > Erik. |
From: Chris S. <chr...@gm...> - 2011-03-28 20:42:05
|
1817 has tradable public companies that have multiple shares with a stock price. I realize, of course, that Rails is a *long* way from supporting 1817. -- Chris Please consider the environment before printing this e-mail. On Mon, Mar 28, 2011 at 10:14 AM, Erik Vos <eri...@xs...> wrote: > I think the Tradeability issue can be fixed by making <Tradeable> a Company > property, rather than a PrivateCompany property, so it would apply to all > company types > > (in practice, it would only work with companies that only have one 100% > share and no share price). > > > > The current sharp distinction between private and public companies always > raises questions when we start thinking about implementing such games. > > But in Rails terminology, in fact the only fundamental difference is that > public companies can lay track and run trains, and privates don’t. > > By definition, public companies have at least one share. Minors often only > have one 100% share, but it does not necessarily have a price (see the 1835 > black minors), and it does not necessarily count against the certificate > limit. That all is already configurable (I think). > > > > If that all is correct, the main required change to implement MS and Big4 > would be to make (minor) public companies buyable via the current private > company purchasing mechanism (see my above proposal). The consequences of > such a buy would use the existing “merge” mechanism (to transfer trains, > cash etc.). > > > > Of course, the details of these merge processes may pose problems that need > different approaches (I don’t have all details in my mind right now). > > > > Erik. > > > > *Van:* Chris Shaffer [mailto:chr...@gm...] > *Verzonden:* maandag 28 maart 2011 16:12 > > *Aan:* Development list for Rails: an 18xx game > *Onderwerp:* Re: [Rails-devel] B&O PC Sale > > > > In regard to this question: > > > > The question is: should I also leave these parameters in the Public > <CompanyType>? Are there any games where different public companies can buy > privates for different ranges of values? I don't want to break one set of > games to implement another. > > > > I'm not sure how to answer the question, but I'd call your attention to the > MS and Big 4 in 1846. These are private companies that lay track, run > trains and pay 50/50 like various other minor companies. They have a > purchase price and a debt. For example, the MS has a purchase price of $60 > and a debt of $40. When initially purchased, the player pays $100, receives > the MS charter, places $60 on the charter and puts $40 in the bank. Later, > the MS private can be sold to a major company for a value between $1 and > $60, at which time its assets are transferred to the major company. > > > > Similarly, in 18West, the Granger companies can be sold to public > companies. > > > > So the model needs to accommodate private, minor and public companies in > various permutations. > > > > -- > Chris > > Please consider the environment before printing this e-mail. > > > ------------------------------------------------------------------------------ > Create and publish websites with WebMatrix > Use the most popular FREE web apps or write code yourself; > WebMatrix provides all the features you need to develop and publish > your website. http://p.sf.net/sfu/ms-webmatrix-sf > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
From: Erik V. <eri...@xs...> - 2011-03-28 17:14:33
|
I think the Tradeability issue can be fixed by making <Tradeable> a Company property, rather than a PrivateCompany property, so it would apply to all company types (in practice, it would only work with companies that only have one 100% share and no share price). The current sharp distinction between private and public companies always raises questions when we start thinking about implementing such games. But in Rails terminology, in fact the only fundamental difference is that public companies can lay track and run trains, and privates don't. By definition, public companies have at least one share. Minors often only have one 100% share, but it does not necessarily have a price (see the 1835 black minors), and it does not necessarily count against the certificate limit. That all is already configurable (I think). If that all is correct, the main required change to implement MS and Big4 would be to make (minor) public companies buyable via the current private company purchasing mechanism (see my above proposal). The consequences of such a buy would use the existing "merge" mechanism (to transfer trains, cash etc.). Of course, the details of these merge processes may pose problems that need different approaches (I don't have all details in my mind right now). Erik. Van: Chris Shaffer [mailto:chr...@gm...] Verzonden: maandag 28 maart 2011 16:12 Aan: Development list for Rails: an 18xx game Onderwerp: Re: [Rails-devel] B&O PC Sale In regard to this question: The question is: should I also leave these parameters in the Public <CompanyType>? Are there any games where different public companies can buy privates for different ranges of values? I don't want to break one set of games to implement another. I'm not sure how to answer the question, but I'd call your attention to the MS and Big 4 in 1846. These are private companies that lay track, run trains and pay 50/50 like various other minor companies. They have a purchase price and a debt. For example, the MS has a purchase price of $60 and a debt of $40. When initially purchased, the player pays $100, receives the MS charter, places $60 on the charter and puts $40 in the bank. Later, the MS private can be sold to a major company for a value between $1 and $60, at which time its assets are transferred to the major company. Similarly, in 18West, the Granger companies can be sold to public companies. So the model needs to accommodate private, minor and public companies in various permutations. -- Chris Please consider the environment before printing this e-mail. |
From: Scott P. <sc...@re...> - 2011-03-28 15:08:21
|
On Mon, Mar 28, 2011 at 9:11 AM, Chris Shaffer <chr...@gm...>wrote: > So the model needs to accommodate private, minor and public companies in > various permutations. > The Independent Railroads in 1846 and Grangers in 18West should be treated more like operating (lay track/run trains) companies than like private companies. Perhaps in order to make things easy to implement in the auction, there would be a private company that is gives ownership of the operating company, but then dissolves once the auction is complete. Of course the 1846 auction is another story... |
From: Chris S. <chr...@gm...> - 2011-03-28 14:12:05
|
In regard to this question: The question is: should I also leave these parameters in the Public > <CompanyType>? Are there any games where different public companies can buy > privates for different ranges of values? I don't want to break one set of > games to implement another. I'm not sure how to answer the question, but I'd call your attention to the MS and Big 4 in 1846. These are private companies that lay track, run trains and pay 50/50 like various other minor companies. They have a purchase price and a debt. For example, the MS has a purchase price of $60 and a debt of $40. When initially purchased, the player pays $100, receives the MS charter, places $60 on the charter and puts $40 in the bank. Later, the MS private can be sold to a major company for a value between $1 and $60, at which time its assets are transferred to the major company. Similarly, in 18West, the Granger companies can be sold to public companies. So the model needs to accommodate private, minor and public companies in various permutations. -- Chris Please consider the environment before printing this e-mail. |
From: Erik V. <eri...@xs...> - 2011-03-28 09:43:13
|
Bill, Some answers below. > -----Oorspronkelijk bericht----- > Van: Bill Rosgen [mailto:ro...@gm...] > Verzonden: maandag 28 maart 2011 11:14 > Aan: Development list for Rails: an 18xx game > Onderwerp: Re: [Rails-devel] B&O PC Sale > > Erik, > > I'll have an attempt at implementing this. > > I plan to add support for attribues to a new 'Tradeable' tag for: > > toCompany > toPlayer > lowerPrice > upperPrice > lowerPriceFactor > upperPriceFactor > > The idea is to then add attributes to the PrivateCompany class to store the > lower and upper prices (or to compute them from the upperPriceFactor and > lowerPriceFactor). > > The question is: should I also leave these parameters in the Public > <CompanyType>? No, I think this should be a complete replacement. Once you have modified the code that finds the prices to get these from the private rather than the public company, the old code is redundant and can be removed at some point (but I suppose that's not urgent). > Are there any games where different public companies > can buy privates for different ranges of values? I don't want to break one set > of games to implement another. I don't think so, but if that would be the case, I believe we could still catch that with our new XML. Of course, all currently implemented games must be checked (and later converted). > Also, if I make these changes, I'll also go through the XML and move the > PriceFactor attributes to the Private <CompanyType>. Is this going to break > savegame compatibility or is it otherwise a bad idea? It shouldn't break anything as long as you don't touch the BuyPrivate class, and I don't see any need to do that. So, yes, the old spec should ultimately be removed (but leaving it in for a while shouldn't do any harm). Erik |
From: Bill R. <ro...@gm...> - 2011-03-28 09:14:49
|
Erik, I'll have an attempt at implementing this. I plan to add support for attribues to a new 'Tradeable' tag for: toCompany toPlayer lowerPrice upperPrice lowerPriceFactor upperPriceFactor The idea is to then add attributes to the PrivateCompany class to store the lower and upper prices (or to compute them from the upperPriceFactor and lowerPriceFactor). The question is: should I also leave these parameters in the Public <CompanyType>? Are there any games where different public companies can buy privates for different ranges of values? I don't want to break one set of games to implement another. Also, if I make these changes, I'll also go through the XML and move the PriceFactor attributes to the Private <CompanyType>. Is this going to break savegame compatibility or is it otherwise a bad idea? Bill On 2011-03-28, at 16:38 , Erik Vos wrote: > Basically, anything defined under <CompanyType> can be overridden under any > <Company> implementing that type. > Of course, the catch here is, that the private buying price range is defined > with the (buying) major companies rather than the (sold) private companies. > If we want to add an ability to vary the buy price ranges per private > company, we must move these parameters to the Private <CompanyType> > definition. > That will also require some code refactoring. > > I wasn't aware that games existed having this need, but indeed 1848 does. > It's also not using factors but absolute numbers as limits, so we probably > should also have new "lowerPrice" and "upperPrice" attributes. > > I'm willing to pick this up in the near future, but if you want to give it a > try, please go ahead. > > Erik |
From: Erik V. <eri...@xs...> - 2011-03-28 08:58:54
|
On further thinking, there are a few more loose ends that we might be able to tie down this way in in one fell swoop: 1. The so far overlooked 1830 B&O exception. 2. The fact that (at least) in 1830 privates can also be sold to other players. This has not been implemented at all yet. Nobody seems to have missed this feature so far, and it would be a bit of a problem to fit it into the UI, so I'm not promising that this will be done anytime soon. But at least we might think about how it could be configured. The basic solution has already been discussed for B&O: a new <Tradeable> tag for private companies. Combining all cases that we are looking at, we could end up with something like: - for 1830 CompanyType Private: <Tradeable toCompany="yes" lowerPriceFactor="0.5" upperPriceFactor="2.0"/> <Tradeable toPlayer="yes"/> <!-- No price limit!--> - for 1830 Private Company B&O: <Tradeable toCompany="no"/> - for 1848 Private Company P1: <Tradeable toCompany="yes" lowerPrice="1" upperPrice="40"/> Etc. Erik. > -----Oorspronkelijk bericht----- > Van: Erik Vos [mailto:eri...@xs...] > Verzonden: maandag 28 maart 2011 10:38 > Aan: 'Development list for Rails: an 18xx game' > Onderwerp: Re: [Rails-devel] B&O PC Sale > > Basically, anything defined under <CompanyType> can be overridden under > any <Company> implementing that type. > Of course, the catch here is, that the private buying price range is defined > with the (buying) major companies rather than the (sold) private companies. > If we want to add an ability to vary the buy price ranges per private > company, we must move these parameters to the Private <CompanyType> > definition. > That will also require some code refactoring. > > I wasn't aware that games existed having this need, but indeed 1848 does. > It's also not using factors but absolute numbers as limits, so we probably > should also have new "lowerPrice" and "upperPrice" attributes. > > I'm willing to pick this up in the near future, but if you want to give it a try, > please go ahead. > > Erik > |
From: Erik V. <eri...@xs...> - 2011-03-28 08:38:27
|
Basically, anything defined under <CompanyType> can be overridden under any <Company> implementing that type. Of course, the catch here is, that the private buying price range is defined with the (buying) major companies rather than the (sold) private companies. If we want to add an ability to vary the buy price ranges per private company, we must move these parameters to the Private <CompanyType> definition. That will also require some code refactoring. I wasn't aware that games existed having this need, but indeed 1848 does. It's also not using factors but absolute numbers as limits, so we probably should also have new "lowerPrice" and "upperPrice" attributes. I'm willing to pick this up in the near future, but if you want to give it a try, please go ahead. Erik > -----Oorspronkelijk bericht----- > Van: Bill Rosgen [mailto:ro...@gm...] > Verzonden: maandag 28 maart 2011 7:14 > Aan: Development list for Rails: an 18xx game > CC: John A. Tamplin > Onderwerp: Re: [Rails-devel] B&O PC Sale > > > On 2011-03-27, at 0:49 , Scott Petersen wrote: > > > On Sat, Mar 26, 2011 at 11:36 AM, John A. Tamplin <ja...@ja...> wrote: > > Since various games have different limits on the purchase price, I suggest > instead having a maximum price it can be purchased for by a company, and 0 > means it can't be purchased. > > > > The variable purchase prices are already well implemented and are > changeable with XML. I suppose it would work to override it (buy in > multiplier is zero) for certain companies, but it would be even better if it did > not even show up in the list of privates to buy in. > > Is there any documentation on this? I can't find any place in the code that > reads the XML for a private company that anything like a buy in multiplier is > read or set per private company. > > I *can* find this in the PublicCompany class, but if I want to have different > multipliers for different private companies (so that, for instance, in 1848 the > various privates can be bought in for different ranges of values), this doesn't > seem to work. I can get around this by setting different base prices for the > privates, and then writing extra code so that they are sold for some other > price in the auction, but this seems not like the best way to proceed. > > Bill Rosgen > > > ---------------------------------------------------------------------------- -- > Enable your software for Intel(R) Active Management Technology to meet > the growing manageability and security demands of your customers. > Businesses are taking advantage of Intel(R) vPro (TM) technology - will your > software be a part of the solution? Download the Intel(R) Manageability > Checker today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Bill R. <ro...@gm...> - 2011-03-28 05:13:46
|
On 2011-03-27, at 0:49 , Scott Petersen wrote: > On Sat, Mar 26, 2011 at 11:36 AM, John A. Tamplin <ja...@ja...> wrote: > Since various games have different limits on the purchase price, I suggest instead having a maximum price it can be purchased for by a company, and 0 means it can't be purchased. > > The variable purchase prices are already well implemented and are changeable with XML. I suppose it would work to override it (buy in multiplier is zero) for certain companies, but it would be even better if it did not even show up in the list of privates to buy in. Is there any documentation on this? I can't find any place in the code that reads the XML for a private company that anything like a buy in multiplier is read or set per private company. I *can* find this in the PublicCompany class, but if I want to have different multipliers for different private companies (so that, for instance, in 1848 the various privates can be bought in for different ranges of values), this doesn't seem to work. I can get around this by setting different base prices for the privates, and then writing extra code so that they are sold for some other price in the auction, but this seems not like the best way to proceed. Bill Rosgen |
From: Rick W. <wes...@pu...> - 2011-03-28 01:15:13
|
----- Original Message ----- > I have committed phase one of the AutoSave/Load feature. Thanks. I hope to try this out tomorrow. -- Rick |
From: Erik V. <eri...@xs...> - 2011-03-26 21:22:13
|
I have committed phase one of the AutoSave/Load feature. It works as follows: 1. First player: 1a. Start game 1b. Select File | AutoSave/Load, and select On. You can also change the polling interval. Press OK. 1c. You will get the standard Save popup. Here you can navigate to the autosave/load directory (e.g. Dropbox) you want to use. [in a later version you will also be able to change the Prefix, which is everything in front of the first underscore in the filename. Normally the prefix only contains the game name, but you can put anything there, for instance a code like 1830A1, as some zines do to distinguish actual games.] 1d. Do your moves, until the end of your turn. Then the game will be saved automatically. You will see some fields deactivate (turn white), but I haven't yet made that consistent (in fact, I have only tested with the 1830 StartRound yet). 1e. When it is your turn again, a (non-modal) popup comes up, and you will see the appropriate fields in the active window get reactivated. [I'll probably make this configurable later, and add a configurable beep too]. 2. Other players: 2a. Load the game saved by the first player. 2b. Same as 1b. 2c. Same as 1c. This step is completely redundant, and will be removed in a later stage (at the point where this happens, the code does not know how the game was started. This needs be added). For now, please just click OK. 2d/e. Same as 1d/e. The procedure for the other players (2a-e) is a bit awkward. I plan to change this later so, that any subsequent player only needs to load the <prefix>.last_rails file that contains the name of the last saved file. AutoSave/Load would then be started automatically. The goal is to merge steps 2a-2b into one (and remove 2c). If you want a first look, please give it a try. Erik. > -----Oorspronkelijk bericht----- > Van: Rick Westerman [mailto:wes...@pu...] > Verzonden: vrijdag 18 maart 2011 17:28 > Aan: Development list for Rails: an 18xx game > Onderwerp: Re: [Rails-devel] Making Rails more suited to fast interactive > play. > > > > ----- Original Message ----- > > Each to their own of course, just providing my personal opinions :) > > > > I think we can generally agree that intrusiveness is bad (since if you > > are using it real-time, you are paying attention anyway ... > > Actually that is not, at least in my case, totally true. While I'll keep Rails > open on one screen on my other screen I'll be checking email, surfing the > web, or even trying to figure out the Rails code and how to modify it. :-) > Some sort of notification -- audible or flashing of the screen, or even a pop- > up to catch the corner of my eye -- is handy. Otherwise I have to manually > check the status. Of course for people who don't want the popup then it > should be able to be turned off. > > In many ways this is like email or twitter or IM. You don't want to be glued > to your email/twitter/IM screen waiting for the next message. On the other > hand you often want to be notified in a timely manner that something is > happening -- thus a pop or something on the notification bar is desired. Yet > there are also times when you just want to drop out and not be notified that > a new message is waiting for you. > > Basically I think that we all agree that if there are popups implemented then > they should be able to be toggled. I just do not want to see the idea of > popups disappear entirely. > > -- Rick > > > ---------------------------------------------------------------------------- -- > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit for your > organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Scott P. <sc...@re...> - 2011-03-26 16:50:08
|
On Sat, Mar 26, 2011 at 11:36 AM, John A. Tamplin <ja...@ja...> wrote: > Since various games have different limits on the purchase price, I suggest > instead having a maximum price it can be purchased for by a company, and 0 > means it can't be purchased. > The variable purchase prices are already well implemented and are changeable with XML. I suppose it would work to override it (buy in multiplier is zero) for certain companies, but it would be even better if it did not even show up in the list of privates to buy in. I like <Tradeable toCompany=”no”/>. |
From: John A. T. <ja...@ja...> - 2011-03-26 16:37:00
|
On Sat, Mar 26, 2011 at 12:32 PM, Erik Vos <eri...@xs...> wrote: > It’s not implemented in Rails, as I have just tested. > > But only now I notice that the rules **do** exclude B&O from being > purchasable by a company. I wasn’t aware of that <blush> (it’s many years > ago that I actually played 1830). > > > > In any case, we need a bit of XML to specify that exclusion. Many ways to > do that, e.g. <Tradeable toCompany=”no”/> (the default being “yes”, but only > if allowed per Phase, where the default is “no”). > > > > I would formulate the truth table more generically as below, but > essentially it’s the same as Scott’s: > Since various games have different limits on the purchase price, I suggest instead having a maximum price it can be purchased for by a company, and 0 means it can't be purchased. -- John A. Tamplin |
From: Erik V. <eri...@xs...> - 2011-03-26 16:32:27
|
It's not implemented in Rails, as I have just tested. But only now I notice that the rules *do* exclude B&O from being purchasable by a company. I wasn't aware of that <blush> (it's many years ago that I actually played 1830). In any case, we need a bit of XML to specify that exclusion. Many ways to do that, e.g. <Tradeable toCompany="no"/> (the default being "yes", but only if allowed per Phase, where the default is "no"). I would formulate the truth table more generically as below, but essentially it's the same as Scott's: <Phase> <Privates> sellingAllowed <Company> <Tradeable> toCompany Buyable No No No No Yes No Yes No No Yes Yes Yes Erik Van: sco...@gm... [mailto:sco...@gm...] Namens Scott Petersen Verzonden: zaterdag 26 maart 2011 15:36 Aan: Erik Vos Onderwerp: Re: [Rails-devel] B&O PC Sale I think you already know this, but in 1830. all privates can be purchased in Phase 3 (3-train purchased) except B&O which may never be purchased. This is already implemented in Rails, but I don't know where this is specified. I suppose the truth table would be: Phase 2 Phase 3+ Not B&O Not Buyable Buyable B&O Not Buyable Not Buyable On Sat, Mar 26, 2011 at 8:48 AM, Erik Vos <eri...@xs...> wrote: > > No, but such a tag or attribute can be added easily. > > The main question, however, is how such an attribute would interfere with the corresponding setting in the <Private> tag under <Phase>. > > What is the truth table for private being buyable by a company, given the settings in <Phase> and in <Company>? > > > > Erik. > > > > > > Van: sco...@gm... [mailto:sco...@gm...] Namens Scott Petersen > Verzonden: zaterdag 26 maart 2011 14:31 > Aan: Development list for Rails: an 18xx game > CC: Erik Vos > Onderwerp: Re: [Rails-devel] B&O PC Sale > > > > On Sat, Mar 26, 2011 at 8:20 AM, Erik Vos <eri...@xs...> wrote: > > I have no problem letting a company buy the B&O private, if it still lives when the first 3-train has been bought. > > > > Sorry, let me further explain. I would like to implement a similar private company to 1830's B&O that cannot be bought in to a Public Corporation. Is there something in the XML that specifies that property? |
From: John A. T. <ja...@ja...> - 2011-03-26 15:54:13
|
On Sat, Mar 26, 2011 at 9:20 AM, Erik Vos <eri...@xs...> wrote: > I have no problem letting a company buy the B&O private, if it still lives > when the first 3-train has been bought. > I would, as it is against the rules. > And I have no clue what circumstances could prevent that. > If the B&O isn't floated or if the B&O doesn't have a route and chooses not to buy a train. -- John A. Tamplin |
From: Eric F. <eto...@gm...> - 2011-03-26 14:21:42
|
The UP private in 18Neb behaves this way, for example. Sent from my iPhone On Mar 26, 2011, at 6:31 AM, Scott Petersen <sc...@re...> wrote: > On Sat, Mar 26, 2011 at 8:20 AM, Erik Vos <eri...@xs...> wrote: > I have no problem letting a company buy the B&O private, if it still lives when the first 3-train has been bought. > > > Sorry, let me further explain. I would like to implement a similar private company to 1830's B&O that cannot be bought in to a Public Corporation. Is there something in the XML that specifies that property? > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |