Apparently CB can't deal with invalid XML properly. The result was that
every file listed after that point wasn't being compiled or passed to the
linker, resulting in a flood of linker errors.
The pager is held by the play_controller and wraps around the
wmi_container, if there are too many items it adds "More Items"
or "Earlier Items" entries. These entries have special reserved
ids, if they are selected the pager traps them.
Future work might be to allow the page_size_ to be selected in
the preferences, that is currently left as a variable to make
it easy to support this.
The functionality of tracking observers and displaying chat messages
is moved to a manager class, which the gui owns.
The functionality of displaying notifications is similarly moved out
of the game_display and to a private namespace. (Static singleton
pattern seems okay here since there really won't need to be more
than one of these for a single application, it seems.)
This is consistent with the introduction of the UnitPtr class.
fake_units really aren't different from units, the only difference
is their life time / allocation and ownership. Since we are trying
to use reference counting for all units (to make them safe to use
with animations), the fake units need to be managed by a reference
counted pointer also. This is the easiest way to achieve that.
I also remove some odd code the [move_units_fake] handler --
there was explicit code to remove the fake units from the fake
unit manager, but this is redundant as it is the responsibility
of the destructor.
Code Blocks and VC project files are updated, but
Code::Blocks Scons and Xcode are not.
This commit adds a dedicated recall list manager class.
The purpose of this is to
- Simplify the code that interacts with the recall list. Prior to
the commit most such code was based on iteration with explicit
iterators, and called global helper functions implemented in
unit.cpp to wrap the code that finds a unit in a vector. It turns
out that interacting with the recall list was the *only* use of
that code, so we make it a member function of the recall list
manager and take it out of unit.cpp.
Most of the code that touches the recall list was previously
7 or 8 lines with a for loop, now it tends to be 1 or 2 lines,
although further refactor may be possible.
- Improve encapsulation. This makes it possible to track how
other classes are interacting with the recall list, and may
make it easier to debug recall list problems by adding debugging
output to the class.
This is a strict refactor, all we do is move the functions and
variables used just for animations to "unit_animation_component",
and include the necessary headers appropriate.
With a bit more work we can probably remove the graphics related
headers from unit.hpp
drawable unit inherits from unit, and implements the draw function,
used only by the display. when the display wants to use the function,
it casts a unit pointer to a drawable_unit, and draws it. this
improves encapsulation.
This use of handle-body idiom saves *alot* of includes, since a
huge number of objects include unit indirectly, and make no use
of the ai formula features.
Currently, the editor does not generate game_board objects, and
leaves the pointer resources::gameboard null. This commit makes
map_location, reports, and tod_manager, three things used in
editor mode, use the display_context pointer instead of the
game_board pointer. We also move a function to display_context,
which finds a const unit * to a visible unit at a hex.
This is a refactor to introduce an object encapsulating the unit map, the game map, and the list of teams. Introducing this object permits us to move a substantial amount of code out of the play_controller object, and also to give a home to some helper functions in unit.?pp that previously sat in the global namespace. It also allows us to simplify the construction of some of the clients of play_controller.
This refactor is ongoing WIP. The goals are
(1) better organize the architecture of the engine, to make saving and reloading easier.
(2) Facilitate the introduction of an improved pathfinding mechanism, which will need to sit between most of the other engine modules and the unit map / game map.
(3) Refactoring clarifies what the existing code is doing, therefore it may help us to find bugs in the current system, which may be fixed independently of the refactor in 1.12.
