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
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
