On 18.08.2013 03:37, Michael T. Pope wrote: > On Sat, 17 Aug 2013 14:42:28 +0200 > Michael Vehrs<michael.bursc...@gmx.de> wrote: > >> It probably doesn't matter, as long as we ensure that setRole() or its >> successor is called during initialisation. >> > AFAICT role is either read directly or fixed with setRole() in all the Unit > initialization paths, so I think you are right. Testing also supports this > view, so I have committed the backwards compatibility hack (with<roles> > section spec fragment loading as suggested). > > However, it looks like the natives are having equipment issues, which is > probably not that surprising given that setRole() does not know about the > native or REF roles. I am hoping you have a plan for expressing the > hardcoding in setRole and the stuff in Role.getRoleEquipment in the > spec:-). > > Other than that, I reckon a fairly major piece of surgery is going well. > The only other thing I have spotted is some strangeness in unit labelling > which I am chasing up now. > > Cheers, > Mike Pope >
Well, we could just put the equipment in the spec, but my long-term goal is to get rid of the equipment type entirely. We know what goods a unit with a role carries, since these were the goods used to equip it. And Role.getRoleEquipment() would simply become role.getRequiredGoods(). Regards Michael ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
