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: Erik V. <eri...@xs...> - 2013-10-04 21:20:38
|
The term "floating" does not occur in the 1856 rules, only "operating" is used. Having floated has no meaning in 1856. In Rails, setFloated() is called in the SR as usual, as Rails requires it, but that does not imply that the company actually will operate. At the start of each 1856 OR, Rails does an additional check if each company can operate, including the check on number of shares. If it fails that test, the company will not be included in the list of operating companies for that OR. A similar thing occurs when the CGR has been formed but at least one of its precursors has operated: it has "floated" but does not yet operate. So I don't think there is a bug - unless you can prove it with an actual saved game. Erik. From: Michael Alexander [mailto:out...@us...] Sent: Friday, October 04, 2013 7:39 AM To: Ticket 170 Subject: [rails:bugs] #170 1856: Companies float too soon. _____ [bugs:#170] <http://sourceforge.net/p/rails/bugs/170/> 1856: Companies float too soon. Status: open Created: Fri Oct 04, 2013 05:38 AM UTC by Michael Alexander Last Updated: Fri Oct 04, 2013 05:38 AM UTC Owner: nobody In 1856, companies are floating during the stock round. They should only check to see if they float when it is their turn in the operating round. It is very possible by the rules, for example, for a company to open with 2 shares in the initial stock round, but when it is their turn to operate for the first time, no 2-trains are left. In this case, the company does not actually open or operate. _____ Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/rails/bugs/170/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ |
|
From: brett l. <bre...@gm...> - 2013-10-04 13:33:10
|
+1 from me. IMO, it should be: text eol=lf ---Brett. On Fri, Oct 4, 2013 at 7:13 AM, Martin Brumm <dr....@t-...>wrote: > Hi, > > i am running into repeated whitespace problems again and again. > > Please have a look at the following article and lets discuss if that is > a valid way to avoid them in the future :) > > https://help.github.com/articles/dealing-with-line-endings > > Kind Regards, > Martin > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Martin B. <dr....@t-...> - 2013-10-04 11:13:33
|
Hi, i am running into repeated whitespace problems again and again. Please have a look at the following article and lets discuss if that is a valid way to avoid them in the future :) https://help.github.com/articles/dealing-with-line-endings Kind Regards, Martin |
|
From: Martin B. <dr....@t-...> - 2013-10-04 10:59:58
|
Hi Stefan, Erik, somewhere in between the 1.7.10 and the current HEAD of the 1.7.x branch the reprocessing of save games in 1835 falls for specific szenario. From what i was able to see: The stepobject inside the OR doesnt get advanced (OR5.2 Opcompany BY) if Opcomp lays a tile to the next OR Step (probably has to do with the rare case that the OPcomp here owns a private which would allow another tilelay for free. This leads to the point that the internal representation of StepObject differs from the recorded Action. I.e. the recorded action is NullAction.SkIP (for skpipping the LayToken) but the Step.Object is still pointing at LAY_TRACK. The subsequent action SetDividend then fails because the Internal StepObject is pointing at LAY_TOKEN. Somehow the Nullaction regarding the special TileLay isnt recorded there valid. If one plays the interrupted game to the end and saves that builds a new report, that then tests ok. But the master branch doesnt fail but subsequently fails on the new savegame and report. So that puts us in the position that master is not reflecting the state of rails1.7.x. And my question now would be how to proceed to release 1.8 ? We are ready with 1880, rails1.7.x_1880 is a branch based on the latest rails1.7.x which incorporates all from specific_1880. and could be used to release 1.8. but how should i incoporate specific_1880 into the master branch ?. Kind regards, Martin |
|
From: Erik V. <eri...@xs...> - 2013-10-02 20:13:34
|
> > Are there other games that do it dynamically? Actually, the CGR in 1856 > comes to mind... > > I have no checked exactly how this is done in 1856, but if I remember > correctly it is done similar. Maybe Erik can shed more light on this. The CGR certificates are created as 20 5% shares. If 10 shares suffice, the first 10 certificates are changed into 10% shares (actually, I believe only a single shareUnit variable has to be changed to achieve this), and the remaining 10 are discarded. > > One way that it could be done would be to start with a 20% share > > defined in the XML file, then if during the floatCompany call it was > > determined I needed a 30% (or 40%) share instead, I could up the shares > value in the certificate and scrap one (or two) of the 10% shares. > > nearly exactly what I outline in my own words above. I agree. Erik |
|
From: Michael A. <out...@gm...> - 2013-10-01 11:30:03
|
I didn't mean to imply that it is bad. I certainly don't feel that way. :) I've personally had a lot of fun working on this. It's one heck of a lot nicer code to work with than the code I write professionally. And the support has been outstanding, so thank you. I don't believe that one can write great software on the first pass. You just don't know what you don't know when you start. I hadn't been keeping track of the list of changes. I'll start now with the changes I've made. Mike On Tue, Oct 1, 2013 at 7:08 AM, Stefan Frey <ste...@we...> wrote: > No I have to defend Rails 1.x, it is not that bad. ;-) > > However you get issues especially touching those things that started > evolving from the beginning (OR/SR and Game Objects) and thus there are > lots of legacy issues, that are to be expected. With hindsight it is > easier to design. And I assume that most people never believed that > Rails would get that far, me included :-) > > In Rails 2.0 I "only" touch the game/state/model packages and the tile > and token related stuff in the GUI classes. > > The good thing was that algorithm always had its own optimized view of > the 18xx elements, thus there is no dependence other than the conversion > from Rails objects to 18xx-Algorithm objects. > > That is the general approach in Rails2.0: Protect the core code of Rails > against implementation needs of new 18xx by providing specified > interfaces to interact with the core code to avoid breaking existing > games the implementer might not even now about. > > Unfortunately I made the mistake to start rewriting the game > initialization code at a time I thought I have enough time to get it > done. Some code there was still from the Colossus project, so I was able > to remove many lines of code. > Without getting this fully done, unfortunately no release is possible. > > But it was more work as expected (no surprise), but I was caught > by real world issues. However I am 80% through, so even it looks like I > have not made a lot of progress, that is the wrong impression. I only > avoid committing myself to any fixed date. But expect a first alpha soon. > > Please keep a good list of all changes required for 1880, as in some > cases it will be easier and quicker to re-implement them in Rails 2.0 > instead of trying to merge the change. > But it is great to see other people work on Rails again, so I will try > to give my best to support your efforts, like what Erik did some time ago. > > > On 10/01/2013 12:49 PM, Michael Alexander wrote: > > Yes, just the tool tip, not the total percentage is wrong. Thanks again. > > > > It sounds like moving this to 2.0 is going to be less of a "port" and > > more of a "re-write, and harvest what can be taken from this version." > > Which is fine, because they all sound like good changes. So when do we > > get to do that again? :) > > > > Mike > > > > > > On Tue, Oct 1, 2013 at 5:02 AM, Stefan Frey <ste...@we... > > <mailto:ste...@we...>> wrote: > > > > Sorry forgot about that: In Rails 2.0 I have removed the > > dependency of certTypeId and displayed text in GUI. > > > > I assume it only effects the ToolTip values and not the total > > percentages? > > > > Workaround: > > 1) Add a method called getDisplayType() that > > returns the "current" certTypeId based on the current values of > shares. > > > > 2) Change method getUpdate() inside ShareModel to use > getDisplayType() > > instead of the certTypeId. > > > > This should remove the dependency. > > If the total percentages are still wrong, maybe you are able to track > > this down. Otherwise ask. > > > > > > On 10/01/2013 05:50 AM, Michael Alexander wrote: > > > I've hit a snag. Field appears to ultimately use the "certTypeId" > in > > > order to display what certificates a player holds. So while I can > > > create a certificate that is a 30% certificate, it still displays > as a > > > 20% certificate. Changing that certTypeId seems to make me unable > to > > > actually move the certificate anywhere. Any advice? > > > > > > Mike > > > > > > > > > On Mon, Sep 30, 2013 at 9:21 AM, Michael Alexander > > > <out...@gm... <mailto:out...@gm...> > > <mailto:out...@gm... <mailto:out...@gm...>>> > > wrote: > > > > > > Sounds good - I'll take that first approach then. Thanks for > > your help. > > > > > > Mike > > > > > > > > > On Mon, Sep 30, 2013 at 8:58 AM, Stefan Frey > > <ste...@we... <mailto:ste...@we...> > > > <mailto:ste...@we... <mailto:ste...@we...>>> > wrote: > > > > > > Seems to be more complicated, as it would add a > ArrayListState > > > instead of changing an Integer into a IntegerState. And > going > > > forward to Rails 2.0 it would require ownership of > > Certificates > > > of other Certificates, as all ownable items need a defined > > > owner. And Scrapheap is a defined owner. > > > I do not mind share being writable, as I assume as the code > > > changing it is not malign. > > > I only mind writing to non-state fields as this breaks > > undo. In > > > Rails 2.0 there is the general rule that all non-state > > variables > > > have to be final. > > > > > > > > > Michael Alexander <out...@gm... > > <mailto:out...@gm...> > > > <mailto:out...@gm... > > <mailto:out...@gm...>>> wrote: > > > > > > Just as a thought, what would you think about having a > > > method inside Public Certificate that you would call > > on the > > > president's share, passing in another share, and > > inside the > > > method it would "combine" them? That would eliminate > > > exposing the share value to be written, and guarantee > that > > > exactly 100% of the company was still in play. > > > > > > 1880 already has the change in the UI, so that is not a > > > problem. :) > > > > > > > > > On Mon, Sep 30, 2013 at 6:57 AM, Stefan > > > Frey<ste...@we... <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>>> wrote: > > > > > > Again some quick comments, see below. > > > > > > On 09/30/2013 05:45 AM, Michael Alexander wrote: > > > > In 1880, a player choose upon opening a company > > if he > > > wants that company > > > > to have a 20%, a 30%, or a 40% president's > > > certificate. This can't be > > > > simulated by just giving them extra 10% shares > > at the > > > start, because it > > > > only counts as 1 against the share limit. Also, > the > > > president can't > > > > sell down to 30% if he has a 40% president's > share > > > (assuming he isn't > > > > dumping the company on someone who doesn't have > > 40%). > > > > > > > > Any advice on how to implement this? > > > > > > > > > > My recommendations are identical to the last of > your > > > proposal, only > > > pointing out to change share to an IntegerState. > > > To avoid any misunderstanding I explain how I > > would do it. > > > > > > A) Change field shares in PublicCertficate class > to an > > > IntegerState to > > > allow dynamic changes. > > > > > > B) Create a president certificates based on 20% > > > definition and > > > certificates of 10% for a full 100%. > > > > > > C) At the time purchase of the president > > certificate, if > > > needed, change > > > the value of share for the president certificate > and > > > move the redundant > > > 10% certificates to the scrapheap (see Bank class). > > > Change the value of > > > share for those to zero. > > > > > > D) You will have to change the UI to allow choice > > of the > > > president > > > certificates shares and extend/augment the > > > StartCompany/BuyCertificate > > > actions for the additional choice. > > > > > > E) The change of president code in various > StockRound > > > class methods > > > should still work, as the do not rely on the fixed > > > assumption of 20% for > > > the president share already. However extensive > testing > > > is recommended. > > > > > > The proposal ensurses the following assumptions at > > every > > > point in the > > > game and is undo-proof. > > > > > > 1) All certificates are created at initialization. > > > 2) The sum of the field "share" of all certificates > > > equals 100 / > > > shareUnit, thus in 1880 10. "shareUnit" is a field > of > > > PublicCompany. > > > > > > Follow-up questions were: > > > > > > > Are there other games that do it dynamically? > > > Actually, the CGR in 1856 comes to mind... > > > > > > I have no checked exactly how this is done in > > 1856, but > > > if I remember > > > correctly it is done similar. Maybe Erik can shed > more > > > light on this. > > > > > > > One way that it could be done would be to start > > with a > > > 20% share defined in the XML file, > > > > then if during the floatCompany call it was > > determined > > > I needed a 30% (or 40%) share instead, > > > > I could up the shares value in the certificate > and > > > scrap one (or two) of the 10% shares. > > > > > > nearly exactly what I outline in my own words > above. > > > > > > > > > ------------------------------------------------------------------------------ > > > October Webinars: Code for Performance > > > Free Intel webinars can help you accelerate > > application > > > performance. > > > Explore tips for MPI, OpenMP, advanced profiling, > and > > > more. Get the most from > > > the latest Intel processors and coprocessors. See > > > abstracts and register > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > October Webinars: Code for Performance > > > Free Intel webinars can help you accelerate application > > performance. > > > Explore tips for MPI, OpenMP, advanced profiling, and > > more. Get > > > the most from > > > the latest Intel processors and coprocessors. See > > abstracts and > > > register > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > October Webinars: Code for Performance > > > Free Intel webinars can help you accelerate application > performance. > > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get > > the most from > > > the latest Intel processors and coprocessors. See abstracts and > > register > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > > > > > > > > > > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > <mailto:Rai...@li...> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > > most from > > the latest Intel processors and coprocessors. See abstracts and > > register > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > <mailto:Rai...@li...> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > > the latest Intel processors and coprocessors. See abstracts and register > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Stefan F. <ste...@we...> - 2013-10-01 11:08:22
|
No I have to defend Rails 1.x, it is not that bad. ;-) However you get issues especially touching those things that started evolving from the beginning (OR/SR and Game Objects) and thus there are lots of legacy issues, that are to be expected. With hindsight it is easier to design. And I assume that most people never believed that Rails would get that far, me included :-) In Rails 2.0 I "only" touch the game/state/model packages and the tile and token related stuff in the GUI classes. The good thing was that algorithm always had its own optimized view of the 18xx elements, thus there is no dependence other than the conversion from Rails objects to 18xx-Algorithm objects. That is the general approach in Rails2.0: Protect the core code of Rails against implementation needs of new 18xx by providing specified interfaces to interact with the core code to avoid breaking existing games the implementer might not even now about. Unfortunately I made the mistake to start rewriting the game initialization code at a time I thought I have enough time to get it done. Some code there was still from the Colossus project, so I was able to remove many lines of code. Without getting this fully done, unfortunately no release is possible. But it was more work as expected (no surprise), but I was caught by real world issues. However I am 80% through, so even it looks like I have not made a lot of progress, that is the wrong impression. I only avoid committing myself to any fixed date. But expect a first alpha soon. Please keep a good list of all changes required for 1880, as in some cases it will be easier and quicker to re-implement them in Rails 2.0 instead of trying to merge the change. But it is great to see other people work on Rails again, so I will try to give my best to support your efforts, like what Erik did some time ago. On 10/01/2013 12:49 PM, Michael Alexander wrote: > Yes, just the tool tip, not the total percentage is wrong. Thanks again. > > It sounds like moving this to 2.0 is going to be less of a "port" and > more of a "re-write, and harvest what can be taken from this version." > Which is fine, because they all sound like good changes. So when do we > get to do that again? :) > > Mike > > > On Tue, Oct 1, 2013 at 5:02 AM, Stefan Frey <ste...@we... > <mailto:ste...@we...>> wrote: > > Sorry forgot about that: In Rails 2.0 I have removed the > dependency of certTypeId and displayed text in GUI. > > I assume it only effects the ToolTip values and not the total > percentages? > > Workaround: > 1) Add a method called getDisplayType() that > returns the "current" certTypeId based on the current values of shares. > > 2) Change method getUpdate() inside ShareModel to use getDisplayType() > instead of the certTypeId. > > This should remove the dependency. > If the total percentages are still wrong, maybe you are able to track > this down. Otherwise ask. > > > On 10/01/2013 05:50 AM, Michael Alexander wrote: > > I've hit a snag. Field appears to ultimately use the "certTypeId" in > > order to display what certificates a player holds. So while I can > > create a certificate that is a 30% certificate, it still displays as a > > 20% certificate. Changing that certTypeId seems to make me unable to > > actually move the certificate anywhere. Any advice? > > > > Mike > > > > > > On Mon, Sep 30, 2013 at 9:21 AM, Michael Alexander > > <out...@gm... <mailto:out...@gm...> > <mailto:out...@gm... <mailto:out...@gm...>>> > wrote: > > > > Sounds good - I'll take that first approach then. Thanks for > your help. > > > > Mike > > > > > > On Mon, Sep 30, 2013 at 8:58 AM, Stefan Frey > <ste...@we... <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>>> wrote: > > > > Seems to be more complicated, as it would add a ArrayListState > > instead of changing an Integer into a IntegerState. And going > > forward to Rails 2.0 it would require ownership of > Certificates > > of other Certificates, as all ownable items need a defined > > owner. And Scrapheap is a defined owner. > > I do not mind share being writable, as I assume as the code > > changing it is not malign. > > I only mind writing to non-state fields as this breaks > undo. In > > Rails 2.0 there is the general rule that all non-state > variables > > have to be final. > > > > > > Michael Alexander <out...@gm... > <mailto:out...@gm...> > > <mailto:out...@gm... > <mailto:out...@gm...>>> wrote: > > > > Just as a thought, what would you think about having a > > method inside Public Certificate that you would call > on the > > president's share, passing in another share, and > inside the > > method it would "combine" them? That would eliminate > > exposing the share value to be written, and guarantee that > > exactly 100% of the company was still in play. > > > > 1880 already has the change in the UI, so that is not a > > problem. :) > > > > > > On Mon, Sep 30, 2013 at 6:57 AM, Stefan > > Frey<ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>>> wrote: > > > > Again some quick comments, see below. > > > > On 09/30/2013 05:45 AM, Michael Alexander wrote: > > > In 1880, a player choose upon opening a company > if he > > wants that company > > > to have a 20%, a 30%, or a 40% president's > > certificate. This can't be > > > simulated by just giving them extra 10% shares > at the > > start, because it > > > only counts as 1 against the share limit. Also, the > > president can't > > > sell down to 30% if he has a 40% president's share > > (assuming he isn't > > > dumping the company on someone who doesn't have > 40%). > > > > > > Any advice on how to implement this? > > > > > > > My recommendations are identical to the last of your > > proposal, only > > pointing out to change share to an IntegerState. > > To avoid any misunderstanding I explain how I > would do it. > > > > A) Change field shares in PublicCertficate class to an > > IntegerState to > > allow dynamic changes. > > > > B) Create a president certificates based on 20% > > definition and > > certificates of 10% for a full 100%. > > > > C) At the time purchase of the president > certificate, if > > needed, change > > the value of share for the president certificate and > > move the redundant > > 10% certificates to the scrapheap (see Bank class). > > Change the value of > > share for those to zero. > > > > D) You will have to change the UI to allow choice > of the > > president > > certificates shares and extend/augment the > > StartCompany/BuyCertificate > > actions for the additional choice. > > > > E) The change of president code in various StockRound > > class methods > > should still work, as the do not rely on the fixed > > assumption of 20% for > > the president share already. However extensive testing > > is recommended. > > > > The proposal ensurses the following assumptions at > every > > point in the > > game and is undo-proof. > > > > 1) All certificates are created at initialization. > > 2) The sum of the field "share" of all certificates > > equals 100 / > > shareUnit, thus in 1880 10. "shareUnit" is a field of > > PublicCompany. > > > > Follow-up questions were: > > > > > Are there other games that do it dynamically? > > Actually, the CGR in 1856 comes to mind... > > > > I have no checked exactly how this is done in > 1856, but > > if I remember > > correctly it is done similar. Maybe Erik can shed more > > light on this. > > > > > One way that it could be done would be to start > with a > > 20% share defined in the XML file, > > > then if during the floatCompany call it was > determined > > I needed a 30% (or 40%) share instead, > > > I could up the shares value in the certificate and > > scrap one (or two) of the 10% shares. > > > > nearly exactly what I outline in my own words above. > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate > application > > performance. > > Explore tips for MPI, OpenMP, advanced profiling, and > > more. Get the most from > > the latest Intel processors and coprocessors. See > > abstracts and register > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application > performance. > > Explore tips for MPI, OpenMP, advanced profiling, and > more. Get > > the most from > > the latest Intel processors and coprocessors. See > abstracts and > > register > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get > the most from > > the latest Intel processors and coprocessors. See abstracts and > register > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > <mailto:Rai...@li...> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > most from > the latest Intel processors and coprocessors. See abstracts and > register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > <mailto:Rai...@li...> > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Michael A. <out...@gm...> - 2013-10-01 10:49:12
|
Yes, just the tool tip, not the total percentage is wrong. Thanks again. It sounds like moving this to 2.0 is going to be less of a "port" and more of a "re-write, and harvest what can be taken from this version." Which is fine, because they all sound like good changes. So when do we get to do that again? :) Mike On Tue, Oct 1, 2013 at 5:02 AM, Stefan Frey <ste...@we...> wrote: > Sorry forgot about that: In Rails 2.0 I have removed the > dependency of certTypeId and displayed text in GUI. > > I assume it only effects the ToolTip values and not the total percentages? > > Workaround: > 1) Add a method called getDisplayType() that > returns the "current" certTypeId based on the current values of shares. > > 2) Change method getUpdate() inside ShareModel to use getDisplayType() > instead of the certTypeId. > > This should remove the dependency. > If the total percentages are still wrong, maybe you are able to track > this down. Otherwise ask. > > > On 10/01/2013 05:50 AM, Michael Alexander wrote: > > I've hit a snag. Field appears to ultimately use the "certTypeId" in > > order to display what certificates a player holds. So while I can > > create a certificate that is a 30% certificate, it still displays as a > > 20% certificate. Changing that certTypeId seems to make me unable to > > actually move the certificate anywhere. Any advice? > > > > Mike > > > > > > On Mon, Sep 30, 2013 at 9:21 AM, Michael Alexander > > <out...@gm... <mailto:out...@gm...>> wrote: > > > > Sounds good - I'll take that first approach then. Thanks for your > help. > > > > Mike > > > > > > On Mon, Sep 30, 2013 at 8:58 AM, Stefan Frey <ste...@we... > > <mailto:ste...@we...>> wrote: > > > > Seems to be more complicated, as it would add a ArrayListState > > instead of changing an Integer into a IntegerState. And going > > forward to Rails 2.0 it would require ownership of Certificates > > of other Certificates, as all ownable items need a defined > > owner. And Scrapheap is a defined owner. > > I do not mind share being writable, as I assume as the code > > changing it is not malign. > > I only mind writing to non-state fields as this breaks undo. In > > Rails 2.0 there is the general rule that all non-state variables > > have to be final. > > > > > > Michael Alexander <out...@gm... > > <mailto:out...@gm...>> wrote: > > > > Just as a thought, what would you think about having a > > method inside Public Certificate that you would call on the > > president's share, passing in another share, and inside the > > method it would "combine" them? That would eliminate > > exposing the share value to be written, and guarantee that > > exactly 100% of the company was still in play. > > > > 1880 already has the change in the UI, so that is not a > > problem. :) > > > > > > On Mon, Sep 30, 2013 at 6:57 AM, Stefan > > Frey<ste...@we... <mailto:ste...@we...>> wrote: > > > > Again some quick comments, see below. > > > > On 09/30/2013 05:45 AM, Michael Alexander wrote: > > > In 1880, a player choose upon opening a company if he > > wants that company > > > to have a 20%, a 30%, or a 40% president's > > certificate. This can't be > > > simulated by just giving them extra 10% shares at the > > start, because it > > > only counts as 1 against the share limit. Also, the > > president can't > > > sell down to 30% if he has a 40% president's share > > (assuming he isn't > > > dumping the company on someone who doesn't have 40%). > > > > > > Any advice on how to implement this? > > > > > > > My recommendations are identical to the last of your > > proposal, only > > pointing out to change share to an IntegerState. > > To avoid any misunderstanding I explain how I would do > it. > > > > A) Change field shares in PublicCertficate class to an > > IntegerState to > > allow dynamic changes. > > > > B) Create a president certificates based on 20% > > definition and > > certificates of 10% for a full 100%. > > > > C) At the time purchase of the president certificate, if > > needed, change > > the value of share for the president certificate and > > move the redundant > > 10% certificates to the scrapheap (see Bank class). > > Change the value of > > share for those to zero. > > > > D) You will have to change the UI to allow choice of the > > president > > certificates shares and extend/augment the > > StartCompany/BuyCertificate > > actions for the additional choice. > > > > E) The change of president code in various StockRound > > class methods > > should still work, as the do not rely on the fixed > > assumption of 20% for > > the president share already. However extensive testing > > is recommended. > > > > The proposal ensurses the following assumptions at every > > point in the > > game and is undo-proof. > > > > 1) All certificates are created at initialization. > > 2) The sum of the field "share" of all certificates > > equals 100 / > > shareUnit, thus in 1880 10. "shareUnit" is a field of > > PublicCompany. > > > > Follow-up questions were: > > > > > Are there other games that do it dynamically? > > Actually, the CGR in 1856 comes to mind... > > > > I have no checked exactly how this is done in 1856, but > > if I remember > > correctly it is done similar. Maybe Erik can shed more > > light on this. > > > > > One way that it could be done would be to start with a > > 20% share defined in the XML file, > > > then if during the floatCompany call it was determined > > I needed a 30% (or 40%) share instead, > > > I could up the shares value in the certificate and > > scrap one (or two) of the 10% shares. > > > > nearly exactly what I outline in my own words above. > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application > > performance. > > Explore tips for MPI, OpenMP, advanced profiling, and > > more. Get the most from > > the latest Intel processors and coprocessors. See > > abstracts and register > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > <mailto:Rai...@li...> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application > performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get > > the most from > > the latest Intel processors and coprocessors. See abstracts and > > register > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > <mailto:Rai...@li...> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > > the latest Intel processors and coprocessors. See abstracts and register > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Stefan F. <ste...@we...> - 2013-10-01 09:02:54
|
Sorry forgot about that: In Rails 2.0 I have removed the dependency of certTypeId and displayed text in GUI. I assume it only effects the ToolTip values and not the total percentages? Workaround: 1) Add a method called getDisplayType() that returns the "current" certTypeId based on the current values of shares. 2) Change method getUpdate() inside ShareModel to use getDisplayType() instead of the certTypeId. This should remove the dependency. If the total percentages are still wrong, maybe you are able to track this down. Otherwise ask. On 10/01/2013 05:50 AM, Michael Alexander wrote: > I've hit a snag. Field appears to ultimately use the "certTypeId" in > order to display what certificates a player holds. So while I can > create a certificate that is a 30% certificate, it still displays as a > 20% certificate. Changing that certTypeId seems to make me unable to > actually move the certificate anywhere. Any advice? > > Mike > > > On Mon, Sep 30, 2013 at 9:21 AM, Michael Alexander > <out...@gm... <mailto:out...@gm...>> wrote: > > Sounds good - I'll take that first approach then. Thanks for your help. > > Mike > > > On Mon, Sep 30, 2013 at 8:58 AM, Stefan Frey <ste...@we... > <mailto:ste...@we...>> wrote: > > Seems to be more complicated, as it would add a ArrayListState > instead of changing an Integer into a IntegerState. And going > forward to Rails 2.0 it would require ownership of Certificates > of other Certificates, as all ownable items need a defined > owner. And Scrapheap is a defined owner. > I do not mind share being writable, as I assume as the code > changing it is not malign. > I only mind writing to non-state fields as this breaks undo. In > Rails 2.0 there is the general rule that all non-state variables > have to be final. > > > Michael Alexander <out...@gm... > <mailto:out...@gm...>> wrote: > > Just as a thought, what would you think about having a > method inside Public Certificate that you would call on the > president's share, passing in another share, and inside the > method it would "combine" them? That would eliminate > exposing the share value to be written, and guarantee that > exactly 100% of the company was still in play. > > 1880 already has the change in the UI, so that is not a > problem. :) > > > On Mon, Sep 30, 2013 at 6:57 AM, Stefan > Frey<ste...@we... <mailto:ste...@we...>> wrote: > > Again some quick comments, see below. > > On 09/30/2013 05:45 AM, Michael Alexander wrote: > > In 1880, a player choose upon opening a company if he > wants that company > > to have a 20%, a 30%, or a 40% president's > certificate. This can't be > > simulated by just giving them extra 10% shares at the > start, because it > > only counts as 1 against the share limit. Also, the > president can't > > sell down to 30% if he has a 40% president's share > (assuming he isn't > > dumping the company on someone who doesn't have 40%). > > > > Any advice on how to implement this? > > > > My recommendations are identical to the last of your > proposal, only > pointing out to change share to an IntegerState. > To avoid any misunderstanding I explain how I would do it. > > A) Change field shares in PublicCertficate class to an > IntegerState to > allow dynamic changes. > > B) Create a president certificates based on 20% > definition and > certificates of 10% for a full 100%. > > C) At the time purchase of the president certificate, if > needed, change > the value of share for the president certificate and > move the redundant > 10% certificates to the scrapheap (see Bank class). > Change the value of > share for those to zero. > > D) You will have to change the UI to allow choice of the > president > certificates shares and extend/augment the > StartCompany/BuyCertificate > actions for the additional choice. > > E) The change of president code in various StockRound > class methods > should still work, as the do not rely on the fixed > assumption of 20% for > the president share already. However extensive testing > is recommended. > > The proposal ensurses the following assumptions at every > point in the > game and is undo-proof. > > 1) All certificates are created at initialization. > 2) The sum of the field "share" of all certificates > equals 100 / > shareUnit, thus in 1880 10. "shareUnit" is a field of > PublicCompany. > > Follow-up questions were: > > > Are there other games that do it dynamically? > Actually, the CGR in 1856 comes to mind... > > I have no checked exactly how this is done in 1856, but > if I remember > correctly it is done similar. Maybe Erik can shed more > light on this. > > > One way that it could be done would be to start with a > 20% share defined in the XML file, > > then if during the floatCompany call it was determined > I needed a 30% (or 40%) share instead, > > I could up the shares value in the certificate and > scrap one (or two) of the 10% shares. > > nearly exactly what I outline in my own words above. > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application > performance. > Explore tips for MPI, OpenMP, advanced profiling, and > more. Get the most from > the latest Intel processors and coprocessors. See > abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > <mailto:Rai...@li...> > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get > the most from > the latest Intel processors and coprocessors. See abstracts and > register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > <mailto:Rai...@li...> > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Michael A. <out...@gm...> - 2013-10-01 03:51:04
|
I've hit a snag. Field appears to ultimately use the "certTypeId" in order to display what certificates a player holds. So while I can create a certificate that is a 30% certificate, it still displays as a 20% certificate. Changing that certTypeId seems to make me unable to actually move the certificate anywhere. Any advice? Mike On Mon, Sep 30, 2013 at 9:21 AM, Michael Alexander <out...@gm...>wrote: > Sounds good - I'll take that first approach then. Thanks for your help. > > Mike > > > On Mon, Sep 30, 2013 at 8:58 AM, Stefan Frey <ste...@we...> wrote: > >> Seems to be more complicated, as it would add a ArrayListState instead of >> changing an Integer into a IntegerState. And going forward to Rails 2.0 it >> would require ownership of Certificates of other Certificates, as all >> ownable items need a defined owner. And Scrapheap is a defined owner. >> I do not mind share being writable, as I assume as the code changing it >> is not malign. >> I only mind writing to non-state fields as this breaks undo. In Rails 2.0 >> there is the general rule that all non-state variables have to be final. >> >> >> Michael Alexander <out...@gm...> wrote: >>> >>> Just as a thought, what would you think about having a method inside >>> Public Certificate that you would call on the president's share, passing in >>> another share, and inside the method it would "combine" them? That would >>> eliminate exposing the share value to be written, and guarantee that >>> exactly 100% of the company was still in play. >>> >>> 1880 already has the change in the UI, so that is not a problem. :) >>> >>> >>> On Mon, Sep 30, 2013 at 6:57 AM, Stefan Frey <ste...@we...>wrote: >>> >>>> Again some quick comments, see below. >>>> >>>> On 09/30/2013 05:45 AM, Michael Alexander wrote: >>>> > In 1880, a player choose upon opening a company if he wants that >>>> company >>>> > to have a 20%, a 30%, or a 40% president's certificate. This can't be >>>> > simulated by just giving them extra 10% shares at the start, because >>>> it >>>> > only counts as 1 against the share limit. Also, the president can't >>>> > sell down to 30% if he has a 40% president's share (assuming he isn't >>>> > dumping the company on someone who doesn't have 40%). >>>> > >>>> > Any advice on how to implement this? >>>> > >>>> >>>> My recommendations are identical to the last of your proposal, only >>>> pointing out to change share to an IntegerState. >>>> To avoid any misunderstanding I explain how I would do it. >>>> >>>> A) Change field shares in PublicCertficate class to an IntegerState to >>>> allow dynamic changes. >>>> >>>> B) Create a president certificates based on 20% definition and >>>> certificates of 10% for a full 100%. >>>> >>>> C) At the time purchase of the president certificate, if needed, change >>>> the value of share for the president certificate and move the redundant >>>> 10% certificates to the scrapheap (see Bank class). Change the value of >>>> share for those to zero. >>>> >>>> D) You will have to change the UI to allow choice of the president >>>> certificates shares and extend/augment the StartCompany/BuyCertificate >>>> actions for the additional choice. >>>> >>>> E) The change of president code in various StockRound class methods >>>> should still work, as the do not rely on the fixed assumption of 20% for >>>> the president share already. However extensive testing is recommended. >>>> >>>> The proposal ensurses the following assumptions at every point in the >>>> game and is undo-proof. >>>> >>>> 1) All certificates are created at initialization. >>>> 2) The sum of the field "share" of all certificates equals 100 / >>>> shareUnit, thus in 1880 10. "shareUnit" is a field of PublicCompany. >>>> >>>> Follow-up questions were: >>>> >>>> > Are there other games that do it dynamically? Actually, the CGR in >>>> 1856 comes to mind... >>>> >>>> I have no checked exactly how this is done in 1856, but if I remember >>>> correctly it is done similar. Maybe Erik can shed more light on this. >>>> >>>> > One way that it could be done would be to start with a 20% share >>>> defined in the XML file, >>>> > then if during the floatCompany call it was determined I needed a 30% >>>> (or 40%) share instead, >>>> > I could up the shares value in the certificate and scrap one (or two) >>>> of the 10% shares. >>>> >>>> nearly exactly what I outline in my own words above. >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> October Webinars: Code for Performance >>>> Free Intel webinars can help you accelerate application performance. >>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >>>> most from >>>> the latest Intel processors and coprocessors. See abstracts and >>>> register > >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Rails-devel mailing list >>>> Rai...@li... >>>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>>> >>> >>> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and register > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> > |
|
From: Michael A. <out...@gm...> - 2013-10-01 03:50:49
|
I've hit a snag. Field appears to ultimately use the "certTypeId" in order to display what certificates a player holds. So while I can create a certificate that is a 30% certificate, it still displays as a 20% certificate. Changing that certTypeId seems to make me unable to actually move the certificate anywhere. Any advice? Mike On Mon, Sep 30, 2013 at 9:21 AM, Michael Alexander <out...@gm...>wrote: > Sounds good - I'll take that first approach then. Thanks for your help. > > Mike > > > On Mon, Sep 30, 2013 at 8:58 AM, Stefan Frey <ste...@we...> wrote: > >> Seems to be more complicated, as it would add a ArrayListState instead of >> changing an Integer into a IntegerState. And going forward to Rails 2.0 it >> would require ownership of Certificates of other Certificates, as all >> ownable items need a defined owner. And Scrapheap is a defined owner. >> I do not mind share being writable, as I assume as the code changing it >> is not malign. >> I only mind writing to non-state fields as this breaks undo. In Rails 2.0 >> there is the general rule that all non-state variables have to be final. >> >> >> Michael Alexander <out...@gm...> wrote: >>> >>> Just as a thought, what would you think about having a method inside >>> Public Certificate that you would call on the president's share, passing in >>> another share, and inside the method it would "combine" them? That would >>> eliminate exposing the share value to be written, and guarantee that >>> exactly 100% of the company was still in play. >>> >>> 1880 already has the change in the UI, so that is not a problem. :) >>> >>> >>> On Mon, Sep 30, 2013 at 6:57 AM, Stefan Frey <ste...@we...>wrote: >>> >>>> Again some quick comments, see below. >>>> >>>> On 09/30/2013 05:45 AM, Michael Alexander wrote: >>>> > In 1880, a player choose upon opening a company if he wants that >>>> company >>>> > to have a 20%, a 30%, or a 40% president's certificate. This can't be >>>> > simulated by just giving them extra 10% shares at the start, because >>>> it >>>> > only counts as 1 against the share limit. Also, the president can't >>>> > sell down to 30% if he has a 40% president's share (assuming he isn't >>>> > dumping the company on someone who doesn't have 40%). >>>> > >>>> > Any advice on how to implement this? >>>> > >>>> >>>> My recommendations are identical to the last of your proposal, only >>>> pointing out to change share to an IntegerState. >>>> To avoid any misunderstanding I explain how I would do it. >>>> >>>> A) Change field shares in PublicCertficate class to an IntegerState to >>>> allow dynamic changes. >>>> >>>> B) Create a president certificates based on 20% definition and >>>> certificates of 10% for a full 100%. >>>> >>>> C) At the time purchase of the president certificate, if needed, change >>>> the value of share for the president certificate and move the redundant >>>> 10% certificates to the scrapheap (see Bank class). Change the value of >>>> share for those to zero. >>>> >>>> D) You will have to change the UI to allow choice of the president >>>> certificates shares and extend/augment the StartCompany/BuyCertificate >>>> actions for the additional choice. >>>> >>>> E) The change of president code in various StockRound class methods >>>> should still work, as the do not rely on the fixed assumption of 20% for >>>> the president share already. However extensive testing is recommended. >>>> >>>> The proposal ensurses the following assumptions at every point in the >>>> game and is undo-proof. >>>> >>>> 1) All certificates are created at initialization. >>>> 2) The sum of the field "share" of all certificates equals 100 / >>>> shareUnit, thus in 1880 10. "shareUnit" is a field of PublicCompany. >>>> >>>> Follow-up questions were: >>>> >>>> > Are there other games that do it dynamically? Actually, the CGR in >>>> 1856 comes to mind... >>>> >>>> I have no checked exactly how this is done in 1856, but if I remember >>>> correctly it is done similar. Maybe Erik can shed more light on this. >>>> >>>> > One way that it could be done would be to start with a 20% share >>>> defined in the XML file, >>>> > then if during the floatCompany call it was determined I needed a 30% >>>> (or 40%) share instead, >>>> > I could up the shares value in the certificate and scrap one (or two) >>>> of the 10% shares. >>>> >>>> nearly exactly what I outline in my own words above. >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> October Webinars: Code for Performance >>>> Free Intel webinars can help you accelerate application performance. >>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >>>> most from >>>> the latest Intel processors and coprocessors. See abstracts and >>>> register > >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Rails-devel mailing list >>>> Rai...@li... >>>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>>> >>> >>> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and register > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> > |
|
From: Michael A. <out...@gm...> - 2013-09-30 13:21:09
|
Sounds good - I'll take that first approach then. Thanks for your help. Mike On Mon, Sep 30, 2013 at 8:58 AM, Stefan Frey <ste...@we...> wrote: > Seems to be more complicated, as it would add a ArrayListState instead of > changing an Integer into a IntegerState. And going forward to Rails 2.0 it > would require ownership of Certificates of other Certificates, as all > ownable items need a defined owner. And Scrapheap is a defined owner. > I do not mind share being writable, as I assume as the code changing it is > not malign. > I only mind writing to non-state fields as this breaks undo. In Rails 2.0 > there is the general rule that all non-state variables have to be final. > > > Michael Alexander <out...@gm...> wrote: >> >> Just as a thought, what would you think about having a method inside >> Public Certificate that you would call on the president's share, passing in >> another share, and inside the method it would "combine" them? That would >> eliminate exposing the share value to be written, and guarantee that >> exactly 100% of the company was still in play. >> >> 1880 already has the change in the UI, so that is not a problem. :) >> >> >> On Mon, Sep 30, 2013 at 6:57 AM, Stefan Frey <ste...@we...> wrote: >> >>> Again some quick comments, see below. >>> >>> On 09/30/2013 05:45 AM, Michael Alexander wrote: >>> > In 1880, a player choose upon opening a company if he wants that >>> company >>> > to have a 20%, a 30%, or a 40% president's certificate. This can't be >>> > simulated by just giving them extra 10% shares at the start, because it >>> > only counts as 1 against the share limit. Also, the president can't >>> > sell down to 30% if he has a 40% president's share (assuming he isn't >>> > dumping the company on someone who doesn't have 40%). >>> > >>> > Any advice on how to implement this? >>> > >>> >>> My recommendations are identical to the last of your proposal, only >>> pointing out to change share to an IntegerState. >>> To avoid any misunderstanding I explain how I would do it. >>> >>> A) Change field shares in PublicCertficate class to an IntegerState to >>> allow dynamic changes. >>> >>> B) Create a president certificates based on 20% definition and >>> certificates of 10% for a full 100%. >>> >>> C) At the time purchase of the president certificate, if needed, change >>> the value of share for the president certificate and move the redundant >>> 10% certificates to the scrapheap (see Bank class). Change the value of >>> share for those to zero. >>> >>> D) You will have to change the UI to allow choice of the president >>> certificates shares and extend/augment the StartCompany/BuyCertificate >>> actions for the additional choice. >>> >>> E) The change of president code in various StockRound class methods >>> should still work, as the do not rely on the fixed assumption of 20% for >>> the president share already. However extensive testing is recommended. >>> >>> The proposal ensurses the following assumptions at every point in the >>> game and is undo-proof. >>> >>> 1) All certificates are created at initialization. >>> 2) The sum of the field "share" of all certificates equals 100 / >>> shareUnit, thus in 1880 10. "shareUnit" is a field of PublicCompany. >>> >>> Follow-up questions were: >>> >>> > Are there other games that do it dynamically? Actually, the CGR in >>> 1856 comes to mind... >>> >>> I have no checked exactly how this is done in 1856, but if I remember >>> correctly it is done similar. Maybe Erik can shed more light on this. >>> >>> > One way that it could be done would be to start with a 20% share >>> defined in the XML file, >>> > then if during the floatCompany call it was determined I needed a 30% >>> (or 40%) share instead, >>> > I could up the shares value in the certificate and scrap one (or two) >>> of the 10% shares. >>> >>> nearly exactly what I outline in my own words above. >>> >>> >>> ------------------------------------------------------------------------------ >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >>> from >>> the latest Intel processors and coprocessors. See abstracts and register >>> > >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Rails-devel mailing list >>> Rai...@li... >>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>> >> >> > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Stefan F. <ste...@we...> - 2013-09-30 12:58:33
|
<html>
<head>
</head>
<body>Seems to be more complicated, as it would add a ArrayListState instead of changing an Integer into a IntegerState. And going forward to Rails 2.0 it would require ownership of Certificates of other Certificates, as all ownable items need a defined owner. And Scrapheap is a defined owner.<br>
I do not mind share being writable, as I assume as the code changing it is not malign.<br>
I only mind writing to non-state fields as this breaks undo. In Rails 2.0 there is the general rule that all non-state variables have to be final. <br>
<br><br><div class="gmail_quote">Michael Alexander <out...@gm...> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>
<div>
Just as a thought, what would you think about having a method inside Public Certificate that you would call on the president's share, passing in another share, and inside the method it would "combine" them? That would eliminate exposing the share value to be written, and guarantee that exactly 100% of the company was still in play.<br/>
<br/>
</div>
1880 already has the change in the UI, so that is not a problem. :)<br/>
</div>
<div class="gmail_extra">
<br/>
<br/>
<div class="gmail_quote">
On Mon, Sep 30, 2013 at 6:57 AM, Stefan Frey<span> <<a href="mailto:ste...@we..." target="_blank">ste...@we...</a>></span> wrote:<br/>
<blockquote class="gmail_quote" style="margin: 0 0 0 0.8ex;border-left: 1.0px rgb(204,204,204) solid;padding-left: 1.0ex;">
Again some quick comments, see below.<br/>
<div>
<div class="h5">
<br/>
On 09/30/2013 05:45 AM, Michael Alexander wrote:<br/>
> In 1880, a player choose upon opening a company if he wants that company<br/>
> to have a 20%, a 30%, or a 40% president's certificate. This can't be<br/>
> simulated by just giving them extra 10% shares at the start, because it<br/>
> only counts as 1 against the share limit. Also, the president can't<br/>
> sell down to 30% if he has a 40% president's share (assuming he isn't<br/>
> dumping the company on someone who doesn't have 40%).<br/>
><br/>
> Any advice on how to implement this?<br/>
><br/>
<br/>
</div>
</div>
My recommendations are identical to the last of your proposal, only<br/>
pointing out to change share to an IntegerState.<br/>
To avoid any misunderstanding I explain how I would do it.<br/>
<br/>
A) Change field shares in PublicCertficate class to an IntegerState to<br/>
allow dynamic changes.<br/>
<br/>
B) Create a president certificates based on 20% definition and<br/>
certificates of 10% for a full 100%.<br/>
<br/>
C) At the time purchase of the president certificate, if needed, change<br/>
the value of share for the president certificate and move the redundant<br/>
10% certificates to the scrapheap (see Bank class). Change the value of<br/>
share for those to zero.<br/>
<br/>
D) You will have to change the UI to allow choice of the president<br/>
certificates shares and extend/augment the StartCompany/BuyCertificate<br/>
actions for the additional choice.<br/>
<br/>
E) The change of president code in various StockRound class methods<br/>
should still work, as the do not rely on the fixed assumption of 20% for<br/>
the president share already. However extensive testing is recommended.<br/>
<br/>
The proposal ensurses the following assumptions at every point in the<br/>
game and is undo-proof.<br/>
<br/>
1) All certificates are created at initialization.<br/>
2) The sum of the field "share" of all certificates equals 100 /<br/>
shareUnit, thus in 1880 10. "shareUnit" is a field of PublicCompany.<br/>
<br/>
Follow-up questions were:<br/>
<div class="im">
<br/>
> Are there other games that do it dynamically? Actually, the CGR in 1856 comes to mind...<br/>
<br/>
</div>
I have no checked exactly how this is done in 1856, but if I remember<br/>
correctly it is done similar. Maybe Erik can shed more light on this.<br/>
<div class="im">
<br/>
> One way that it could be done would be to start with a 20% share defined in the XML file,<br/>
> then if during the floatCompany call it was determined I needed a 30% (or 40%) share instead,<br/>
> I could up the shares value in the certificate and scrap one (or two) of the 10% shares.<br/>
<br/>
</div>
nearly exactly what I outline in my own words above.<br/>
<div class="HOEnZb">
<div class="h5">
<br/>
------------------------------------------------------------------------------<br/>
October Webinars: Code for Performance<br/>
Free Intel webinars can help you accelerate application performance.<br/>
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from<br/>
the latest Intel processors and coprocessors. See abstracts and register ><br/>
<a href="http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk</a><br/>
_______________________________________________<br/>
Rails-devel mailing list<br/>
<a href="mailto:Rai...@li..." target="_blank">Rai...@li...</a><br/>
<a href="https://lists.sourceforge.net/lists/listinfo/rails-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/rails-devel</a><br/>
</div>
</div>
</blockquote>
</div>
<br/>
</div>
</blockquote></div></body>
</html>
|
|
From: Michael A. <out...@gm...> - 2013-09-30 11:43:17
|
Just as a thought, what would you think about having a method inside Public Certificate that you would call on the president's share, passing in another share, and inside the method it would "combine" them? That would eliminate exposing the share value to be written, and guarantee that exactly 100% of the company was still in play. 1880 already has the change in the UI, so that is not a problem. :) On Mon, Sep 30, 2013 at 6:57 AM, Stefan Frey <ste...@we...> wrote: > Again some quick comments, see below. > > On 09/30/2013 05:45 AM, Michael Alexander wrote: > > In 1880, a player choose upon opening a company if he wants that company > > to have a 20%, a 30%, or a 40% president's certificate. This can't be > > simulated by just giving them extra 10% shares at the start, because it > > only counts as 1 against the share limit. Also, the president can't > > sell down to 30% if he has a 40% president's share (assuming he isn't > > dumping the company on someone who doesn't have 40%). > > > > Any advice on how to implement this? > > > > My recommendations are identical to the last of your proposal, only > pointing out to change share to an IntegerState. > To avoid any misunderstanding I explain how I would do it. > > A) Change field shares in PublicCertficate class to an IntegerState to > allow dynamic changes. > > B) Create a president certificates based on 20% definition and > certificates of 10% for a full 100%. > > C) At the time purchase of the president certificate, if needed, change > the value of share for the president certificate and move the redundant > 10% certificates to the scrapheap (see Bank class). Change the value of > share for those to zero. > > D) You will have to change the UI to allow choice of the president > certificates shares and extend/augment the StartCompany/BuyCertificate > actions for the additional choice. > > E) The change of president code in various StockRound class methods > should still work, as the do not rely on the fixed assumption of 20% for > the president share already. However extensive testing is recommended. > > The proposal ensurses the following assumptions at every point in the > game and is undo-proof. > > 1) All certificates are created at initialization. > 2) The sum of the field "share" of all certificates equals 100 / > shareUnit, thus in 1880 10. "shareUnit" is a field of PublicCompany. > > Follow-up questions were: > > > Are there other games that do it dynamically? Actually, the CGR in 1856 > comes to mind... > > I have no checked exactly how this is done in 1856, but if I remember > correctly it is done similar. Maybe Erik can shed more light on this. > > > One way that it could be done would be to start with a 20% share defined > in the XML file, > > then if during the floatCompany call it was determined I needed a 30% > (or 40%) share instead, > > I could up the shares value in the certificate and scrap one (or two) of > the 10% shares. > > nearly exactly what I outline in my own words above. > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Stefan F. <ste...@we...> - 2013-09-30 10:57:52
|
Again some quick comments, see below. On 09/30/2013 05:45 AM, Michael Alexander wrote: > In 1880, a player choose upon opening a company if he wants that company > to have a 20%, a 30%, or a 40% president's certificate. This can't be > simulated by just giving them extra 10% shares at the start, because it > only counts as 1 against the share limit. Also, the president can't > sell down to 30% if he has a 40% president's share (assuming he isn't > dumping the company on someone who doesn't have 40%). > > Any advice on how to implement this? > My recommendations are identical to the last of your proposal, only pointing out to change share to an IntegerState. To avoid any misunderstanding I explain how I would do it. A) Change field shares in PublicCertficate class to an IntegerState to allow dynamic changes. B) Create a president certificates based on 20% definition and certificates of 10% for a full 100%. C) At the time purchase of the president certificate, if needed, change the value of share for the president certificate and move the redundant 10% certificates to the scrapheap (see Bank class). Change the value of share for those to zero. D) You will have to change the UI to allow choice of the president certificates shares and extend/augment the StartCompany/BuyCertificate actions for the additional choice. E) The change of president code in various StockRound class methods should still work, as the do not rely on the fixed assumption of 20% for the president share already. However extensive testing is recommended. The proposal ensurses the following assumptions at every point in the game and is undo-proof. 1) All certificates are created at initialization. 2) The sum of the field "share" of all certificates equals 100 / shareUnit, thus in 1880 10. "shareUnit" is a field of PublicCompany. Follow-up questions were: > Are there other games that do it dynamically? Actually, the CGR in 1856 comes to mind... I have no checked exactly how this is done in 1856, but if I remember correctly it is done similar. Maybe Erik can shed more light on this. > One way that it could be done would be to start with a 20% share defined in the XML file, > then if during the floatCompany call it was determined I needed a 30% (or 40%) share instead, > I could up the shares value in the certificate and scrap one (or two) of the 10% shares. nearly exactly what I outline in my own words above. |
|
From: Michael A. <out...@gm...> - 2013-09-30 04:55:50
|
Sorry - I meant inside "startCompany", not "floatCompany". On Mon, Sep 30, 2013 at 12:38 AM, Michael Alexander <out...@gm... > wrote: > One way that it could be done would be to start with a 20% share defined > in the XML file, then if during the floatCompany call it was determined I > needed a 30% (or 40%) share instead, I could up the shares value in the > certificate and scrap one (or two) of the 10% shares. > > The only problem with that is that it requires the addition of a > "setShares" call inside "PublicCertificate", which in turn invalidates all > the checking that is done to make sure that exactly 100% of a company is > available. > > > On Mon, Sep 30, 2013 at 12:20 AM, Michael Alexander < > out...@gm...> wrote: > >> Are there other games that do it dynamically? Actually, the CGR in 1856 >> comes to mind... >> >> >> On Sun, Sep 29, 2013 at 11:47 PM, John A. Tamplin <ja...@ja...> wrote: >> >>> On Sun, Sep 29, 2013 at 11:45 PM, Michael Alexander < >>> out...@gm...> wrote: >>> >>>> In 1880, a player choose upon opening a company if he wants that >>>> company to have a 20%, a 30%, or a 40% president's certificate. This can't >>>> be simulated by just giving them extra 10% shares at the start, because it >>>> only counts as 1 against the share limit. Also, the president can't sell >>>> down to 30% if he has a 40% president's share (assuming he isn't dumping >>>> the company on someone who doesn't have 40%). >>>> >>>> Any advice on how to implement this? >>>> >>> >>> Many games have some president's certificates that aren't 20%, so make >>> sure it supports those as well. >>> >>> -- >>> John A. Tamplin >>> >>> >>> ------------------------------------------------------------------------------ >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >>> from >>> the latest Intel processors and coprocessors. See abstracts and register >>> > >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Rails-devel mailing list >>> Rai...@li... >>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>> >>> >> > |
|
From: Michael A. <out...@gm...> - 2013-09-30 04:39:03
|
One way that it could be done would be to start with a 20% share defined in the XML file, then if during the floatCompany call it was determined I needed a 30% (or 40%) share instead, I could up the shares value in the certificate and scrap one (or two) of the 10% shares. The only problem with that is that it requires the addition of a "setShares" call inside "PublicCertificate", which in turn invalidates all the checking that is done to make sure that exactly 100% of a company is available. On Mon, Sep 30, 2013 at 12:20 AM, Michael Alexander <out...@gm... > wrote: > Are there other games that do it dynamically? Actually, the CGR in 1856 > comes to mind... > > > On Sun, Sep 29, 2013 at 11:47 PM, John A. Tamplin <ja...@ja...> wrote: > >> On Sun, Sep 29, 2013 at 11:45 PM, Michael Alexander < >> out...@gm...> wrote: >> >>> In 1880, a player choose upon opening a company if he wants that company >>> to have a 20%, a 30%, or a 40% president's certificate. This can't be >>> simulated by just giving them extra 10% shares at the start, because it >>> only counts as 1 against the share limit. Also, the president can't sell >>> down to 30% if he has a 40% president's share (assuming he isn't dumping >>> the company on someone who doesn't have 40%). >>> >>> Any advice on how to implement this? >>> >> >> Many games have some president's certificates that aren't 20%, so make >> sure it supports those as well. >> >> -- >> John A. Tamplin >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and register > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> > |
|
From: Michael A. <out...@gm...> - 2013-09-30 04:20:11
|
Are there other games that do it dynamically? Actually, the CGR in 1856 comes to mind... On Sun, Sep 29, 2013 at 11:47 PM, John A. Tamplin <ja...@ja...> wrote: > On Sun, Sep 29, 2013 at 11:45 PM, Michael Alexander < > out...@gm...> wrote: > >> In 1880, a player choose upon opening a company if he wants that company >> to have a 20%, a 30%, or a 40% president's certificate. This can't be >> simulated by just giving them extra 10% shares at the start, because it >> only counts as 1 against the share limit. Also, the president can't sell >> down to 30% if he has a 40% president's share (assuming he isn't dumping >> the company on someone who doesn't have 40%). >> >> Any advice on how to implement this? >> > > Many games have some president's certificates that aren't 20%, so make > sure it supports those as well. > > -- > John A. Tamplin > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: John A. T. <ja...@ja...> - 2013-09-30 04:17:15
|
On Sun, Sep 29, 2013 at 11:45 PM, Michael Alexander <out...@gm... > wrote: > In 1880, a player choose upon opening a company if he wants that company > to have a 20%, a 30%, or a 40% president's certificate. This can't be > simulated by just giving them extra 10% shares at the start, because it > only counts as 1 against the share limit. Also, the president can't sell > down to 30% if he has a 40% president's share (assuming he isn't dumping > the company on someone who doesn't have 40%). > > Any advice on how to implement this? > Many games have some president's certificates that aren't 20%, so make sure it supports those as well. -- John A. Tamplin |
|
From: Mike B. <com...@ip...> - 2013-09-30 04:15:52
|
The simplest way of simulating this behaviour that comes to mind is with 10% certificates and an increase in the share limit, but that would not be very satisfactory. Mike Bourke Campaign Mastery http://www.campaignmastery.com <http://www.campaignmastery.com/> Co-author, Assassin's Amulet <http://www.legaciescampaignsetting.com/> http://www.legaciescampaignsetting.com _____ From: Michael Alexander [mailto:out...@gm...] Sent: Monday, 30 September 2013 1:45 PM To: Development list for Rails: an 18xx game Subject: [Rails-devel] 1880: President Certificates In 1880, a player choose upon opening a company if he wants that company to have a 20%, a 30%, or a 40% president's certificate. This can't be simulated by just giving them extra 10% shares at the start, because it only counts as 1 against the share limit. Also, the president can't sell down to 30% if he has a 40% president's share (assuming he isn't dumping the company on someone who doesn't have 40%). Any advice on how to implement this? |
|
From: Michael A. <out...@gm...> - 2013-09-30 03:45:16
|
In 1880, a player choose upon opening a company if he wants that company to have a 20%, a 30%, or a 40% president's certificate. This can't be simulated by just giving them extra 10% shares at the start, because it only counts as 1 against the share limit. Also, the president can't sell down to 30% if he has a 40% president's share (assuming he isn't dumping the company on someone who doesn't have 40%). Any advice on how to implement this? |
|
From: Stefan F. <ste...@we...> - 2013-09-25 23:24:37
|
This is nothing new in Rails. 1835 and 1889 feature the same type of
private powers. In 1835 companies do not own privates too.
Example of private B in 1889:
<SpecialProperty condition="ifOwnedByPlayer" when="tileLayingStep"
class="rails.game.special.SpecialTileLay">
Use condition = "ifOwnedByPlayer" here.
On 09/25/2013 05:03 PM, Michael Alexander wrote:
> The main problem with that is that companies don't own privates ever in
> 1880. The benefits for a private company extend to all companies (both
> minors ("investors" in 1880) and majors) that the owner of the private
> is the president of. So we'd either have to have a token that went with
> the player, or tokens that could come and go as the player become/lost
> the presidency of a company.
>
> Mike
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
|
|
From: Michael A. <out...@gm...> - 2013-09-25 15:03:48
|
The main problem with that is that companies don't own privates ever in
1880. The benefits for a private company extend to all companies (both
minors ("investors" in 1880) and majors) that the owner of the private is
the president of. So we'd either have to have a token that went with the
player, or tokens that could come and go as the player become/lost the
presidency of a company.
Mike
|
|
From: Mike B. <com...@ip...> - 2013-09-25 14:46:43
|
Replying to the original post because it's not quite on point. It occurs to me that the code to do all this is more or less present already if you think of ownership of these companies giving the owning company a token. This may or may not be helpful to you. Mike Bourke Campaign Mastery http://www.campaignmastery.com <http://www.campaignmastery.com/> Co-author, Assassin's Amulet <http://www.legaciescampaignsetting.com/> http://www.legaciescampaignsetting.com _____ From: Michael Alexander [mailto:out...@gm...] Sent: Wednesday, 25 September 2013 10:43 PM To: Development list for Rails: an 18xx game Subject: [Rails-devel] Private Companies in 1880... Just like everything else in 1880, private companies work a little differently than "normal". The problems are: - They never close. They just stop paying out. This is important because the benefits of the privates carry on for the entire game. - They should never count against the share limit - They count as zero value at the end of the game. It probably actually should count as zero value during the entire game. The first one is easy to deal with inside 1880 specific code. The third is difficult because inside Player the worth is based on the base price of the private. I was thinking about adding a field that could be initialized in the XML that would indicate the worth of each private and changing Player to look at it. The second I assume is similar, but I haven't had time to track that down in the code yet. Does this seem like a reasonable approach? Mike |
|
From: Michael A. <out...@gm...> - 2013-09-25 13:38:04
|
On Wed, Sep 25, 2013 at 9:23 AM, Stefan Frey <ste...@we...> wrote: > Quick answers, see below. All private companies in all 18xx work > differently ;-) Please remember that I only read 1880 rules before, > never played... > > > On 09/25/2013 02:42 PM, Michael Alexander wrote: > > Just like everything else in 1880, private companies work a little > > differently than "normal". The problems are: > > > > - They never close. They just stop paying out. This is important > > because the benefits of the privates carry on for the entire game. > > > > > - They should never count against the share limit > > > > - They count as zero value at the end of the game. It probably actually > > should count as zero value during the entire game. > > > > The first one is easy to deal with inside 1880 specific code. > > Revenue is already a list of revenue values, that can change by phase. > Compare field revenue and method getRevenueByPhase inside the > PrivateCompany class. No need for specific code. > Non-closing is not an issue just do not specify a closing condition Ahhh, ok. I can do that. > > > > > The third is difficult because inside Player the worth is based on the > > base price of the private. I was thinking about adding a field that > > could be initialized in the XML that would indicate the worth of each > > private and changing Player to look at it. > > Base price of the private is only used for worth and selling to and from > companies, the base price for each item of the start packet is defined > separately. I do not know 1880 good enough, if this not enough > flexibility already. (Compare 1830 CompanyManager.xml for an example) > In 1880, privates are never sold to companies. The base price is needed for the auction at the start of the game, but that's it. If it wasn't used for that, I could just set base price to 0 in the XML files. > > > > The second I assume is similar, but I haven't had time to track that > > down in the code yet. > > This will require a change, as PrivateCompanies are counted as one > certificate towards the certificateCount. (Compare method > getCertificateCount in Portfolio class). > > This has to be changed, my recommendation is to move up method > getCertificateCount from PublicCertificateI to Certificate interface, > with according changes to the field certificateCount in > PublicCertificate class. > > Ok, I can take a look at this. Look forward to Rails2.0, this will be simplified as all duplicate > Interfaces are dropped. > I am looking forward to it. :) > > > Does this seem like a reasonable approach? > > > > Mike > > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > > the latest Intel processors and coprocessors. See abstracts and register > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
99 messages has been excluded from this view by a project administrator.
