On Mon, Feb 27, 2006 at 15:26:58 +0000, Scott Klempner <[EMAIL PROTECTED]> wrote: > > I realize there are technical problems, namely only a subset of unit config > data are copied when the mold is read. Storing the entire unit config for > each recruited unit just in case I want to poke a value sometime to > personalize the unit is probably bad programming (I wouldn't know).
Part of the problem is that units don't really inherit from their base unit type. (I.e. they don't get a private copy of the features defined by the unit type.) So that you can't change features for a unit that are defined by unit types. Instead you have to make a new unit type and change the unit to be that type. I think having a private copy of the data is considered the more normal way to do things when using object oreinted programming. (And C++ is supposed to be an object oriented language.) I don't think memory footprint is that big of a deal as I have seen comments that this is considered to be a low priority item in the project. However, changing the code to do that would take a lot of grunt work. _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
