Glad to help. And don't worry about the credit, I don't care about it. :) Regards, Petr
2014-04-15 11:27 GMT+02:00 Michael T. Pope <mp...@computer.org>: > > On Mon, 14 Apr 2014 22:42:58 +0200 > Petr Fišer <pries...@gmail.com> wrote: > > Specification looks good to me but I dont understand this: > > > > <goods-type id="model.goods.horses" is-farmed="false" breeding-number="2" > > made-from="model.goods.food"> > > <market initial-amount="1000" initial-price="1" price-difference="2" /> > > </goods-type> > > > > Why is there made-from="model.goods.food" when in the other spec. file is: > > > > <production> > > <input goods-type="model.goods.grain" value="1"/> > > <output goods-type="model.goods.horses" value="1"/> > > </production> > > Good catch. That is clearly wrong, the horses GoodsType needs to be > made-from food in classic and grain in the freecol rules. That is easy > enough to fix. However the obvious fix breaks some tests, which look easy > to fix but actually reveal a nasty lurking bug. > > There are three fields in GoodsType that are derived from the overall > specification (buildingMaterial, makes, militaryGoods) which are > currently set on the fly as a specification is read. This works if we > just read a simple single specification, but not if we do something > more elaborate like read a derived specification (e.g. the freecol > rules:-S) or mods that mess with the goods types. So ATM when we read > the food GoodsType from the classic rules spec, the buildingMaterial > flag is set true, but then when we read the freecol rules spec, the > buildingMaterial flag is set true for grain but not cleared for food. > What needs to happen is for the derived fields to be set only when the > specification has been fully read. Fortunately we have a well defined > place where we already do a bunch of post-read cleanup in > Specification.clean. So this is now done in git.f742245, which has the > pleasant benefit that it allows dropping some GoodsType mutators. > That fix means that isBuildingMaterial, isRawMaterial, getOutputType, > isRawBuildingMaterial were previously not always correct. > > With that fix in place, the obvious change to the freecol spec plus > the required test fixes work as expected. These have been committed > in git.9a88c77, and after that the freecol rules work. > > To completely fix it, we need your next patch which indeed gets to the > real cause of the bug. I have changed it slightly by putting the test > into goodsToMake which ISTM is clearer. Alas I fumbled the commit > message and failed to credit you (git.61ee4ea) for which I apologize. > > Thanks for chasing that one down. > > Cheers, > Mike Pope ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
