On 05-05-14 11:35, Michael T. Pope wrote: > Looking at BR#2628, we can consider hills/ore: > > Bonus Resrc Road River FreeC Expert > 0 - - - 4 8 > 0 - Y - 5 10 > 0 Y - - 6 12 > 0 Y Y - 7 14 > +1 - - - 6 12 > +1 Y - - 8 16 > +2 - - - 7 14 > +2 Y - - 9 18 > Bonus Resrc Road River FreeC Expert > > 1. Colony bonus follows the same pattern as for coniferForest/lumber[C], > although negative cases are not present in the data. > > 2. The resource is worth +2[F], doubled for the expert unit[f]. > > 3. A road is worth +1[F], but +2[C] with an expert unit. This is more > like coniferForest/fur. > > 4. River data is omitted. > > 5. Base productivity is 4[F], doubled with the expert unit[F]. > > 6. The formula that might work here is: > > (BASE + RESOURCE + ROAD + RIVER?) x EXPERT + COLONY > > which is different again from the previous two. > > > I could add in the results from BR#2629, but silver is also just weird. > > The question then is how to accomodate these variations. The colony > bonus already has its own special routine, which will clearly have to > get a bit more complex. The different handling of roads and rivers > means we have to pick one formula and vary the road and river bonuses > by context. I propose arbitrarily to work from the > coniferForest/lumber formula (mainly because that is the closest to > the existing code and tests), and try varying the bonuses using > scopes-by-unitType. We shall see if that can work. > > No promises on whether this can be completely fixed in a backward > compatible way. The (BASE + RESOURCE) bracketing is done (git.a565ae7), > but the rest looks like a nasty rathole. > >> Since we are aiming for a release, i think we should focus on getting >> the display to match what the production code does now. > Agreed, and the display should now match as of git.3980654. If that > worked, that is the last of the release blocking bugs folks. Look hard for > things that have been forgotten. If nothing serious surfaces, I will aim > to release on the "next free weekend", which is a rather unconstrained > quantity but might include the coming one. > > Cheers, > Mike Pope > >
Mike, i'd advise caution when using BR#2628, BR#2629 and BR#2630 . While the data in them is correct, it only deals with a few cases. The tables on http://sourceforge.net/p/freecol/wiki/WWC1D%20-%20resource%20output%20v2/ do cover all the cases mentioned in those BRs. Maybe it would be better to close them, and make a new feature request under 'Pending Features for FreeCol 1' that links to the wiki page above ? LW ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
