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