sounds great... maybe you should turn this whole mechanic into a type of template to ease the porting to other info...
the only question I have is WRT traits and modifications. What you describe is very similar in functionalities to the trait and modification mechanism... it might be worth investigating in what way those two approches are different and if an evolution of the modification of the modification mechanism (either to move to your way or doing stuff or extending it to cover you needs) might be a better idea On Dec 20, 2007 6:35 PM, Mark de Wever <[EMAIL PROTECTED]> wrote: > It's the time of the year to make good intentions and one of the most > common > ones is the intention to loose some weight... > My intention is to let our unit class to loose some weight. I want to add > COW for some data in the unit class. As example I use the movement_cost > data. These changes are scheduled for 1.5, I think it's a bit late for 1.4 > , > but if somebody thinks it should be 1.4 then let me know. > > Every unit has a config object with it's movement info and a cache for the > movement cost. This cache is copied for every unit and populated for every > unit. My idea is to let every unit have two new members instead. > > std::string movement_type_; // which is the id of the movement type > unit_movement_type* movement_; // defined in unit_types.hpp > > All movement types defined in WML will be stored in 1 std::map (This type > will also get the movement cache, not done yet): > std::map<std::string,unit_movement_type> movement_types; > This map is not inside a unit but global. > > The pointer in units points to an item in this map which happens when > the unit is created from a unit_type. When a unit needs to modify it's > movement cost the following code will be used: > > // We no longer use a defaut cost so clear the type, this is also the > // indication we need to store the movement cost data inside the unit. > movement_type_ = ""; > movement_ = new unit_movement_type(*movement_); > > Then the modifications to the movement can be done. > > This means when a unit is saved we either need to store the movement_type_ > if available or store the entire movement data (which also gives a nice > backwards compatibility). > > By default a unit won't store it's movement info, this influences > - [store_unit] > - unit filtering as well? > - saving and loading > > I want to add a key in [store_unit] (default false) > store_movement = true > When set the unit will write it's full info movement info in the config > otherwise only the name of the type. So it will be possible to switch > types > with 1 key. > Probably wmllint can't do the conversion since it's hard to guess whether > the movement info is needed, which means the user has to do it manually. > Setting the default to true is not an option, since that means once you > have > a store unit your unit directly gains weight again and [store_unit] is > used > quite often. > > If filtering is affected it's possible to always write a full config when > the filtering code stores a unit. > > Of course more things need to be modified > - unit copy constructor > - unit destructor > - savegame and loading > > When writing a savegame the movement_types which have been used should be > written into the savegame. > When loading the data in the savegame should overwrite the default of the > game to avoid OOS errors (which happens if a type in the core content has > been changed). > > Once movement is done more things will get the same treatment eg defense, > resistance and maybe more. > > What do you think of this idea, did I miss some obvious problems? > > Regards, > Mark de Wever aka Mordante/SkeletonCrew > > > > > _______________________________________________ > Wesnoth-dev mailing list > [email protected] > https://mail.gna.org/listinfo/wesnoth-dev >
_______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
