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
