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 > |