Menu
▾
▴
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 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: 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-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: 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 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 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 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 > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X