This commit splits some of the functionality of the gamemap object
into a new class, the "terrain_type_data" object. This class is
intended to hold a record of known terrains and the terrain code ->
terrain type map. It handles merging in new terrain definitions,
and it is shared between map objects. It is also cached by the game
config manager, so that we only recalculate this data when we
change configs.
There is in fact a *semantic* change going on here, which is that
when a scenario introduces a new terrain type by merging, this gets
added to the global cache. The alternative is to make a copy of the
global cache, only for the this scenario, as soon as we have to
dirty the cache. However since I didn't see any downside to putting
the merged terrains together and carrying them across scenarios,
I opted not to do that here.
there are multiple reasons why i think this should be reverted:
1) this wasn't tested enough, especialy we don't even know, whether all mainline campaigns are compatible
(this can be easily fixed, but only if one know which campaigns are effected which requires testing)
2) after renaming remove_from_carryover_on_leaders_loss to remove_from_carryover_on_defeat it sounds wrong that this can result in removing units on victory.
3) this seemed to break many UMC addons.
Note that this only removes one check for defeat_condition before [endlevel].
Especialy if for example side 1 gets defeated by defeat_condition in turn 1 but the game still goes on due to multiple other non defeated sides, but then the game ends with [endlevel] result=victory in turn 2, the units will be removed from carryover (unless specified otherwise)
This was also the pre 1.11.13 behaviour.
Also note that we cannot remove the 'defeated' side in case of [endlevel]result=victory, becasue [endlevel] doesn't sepcify which sides have victory/defeat.
This especialy fixes the scenario "Stolen Gold" from "Northern Rebirth" (http://gna.org/bugs/?22601)
this commit ports e0ec8c32b22c95412925bc163eeaca6ffa96d1ab from 1.12
The filter context is, game_board + tod manager.
game_display can (and now does) implement this interface,
also game_state. This permits both animations and engine
components to use it.
This seems likely to come in handy in the future... I have added
and removed debugging code like this several times :)
I think engine/enemies is a good channel for it which won't
clutter.
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.)
there are some hotkeys that are senseful in editor and in game but not
in teh main menu, so now instead of having hotkeys eigher in GAME,
EDITOR, MAIN_MENU or GENERAL we now allow any combination of the first
3.
this is also intended to fix a bug in add_hotkey() if new_scope ==
hotkey::SCOPE_COUNT where new hotkeys doesn't correctly overwrite other
scoped hotkeys.
This allows us to eliminate two headers and move code out of
play_controller, and keep related code together. The cache is
now a static variable in the only function that calls it.
this also makes a small change in the savefile format: [endlevel] ->
[end_level_data] in snapshots.
we still have the "store_carryover" function in playcampaign.cpp which does the visual message.
Note that the real carryover happens after linger mode while that message happens before linger mode this simplifies linger mode saves.
This is needed to properly parse a list of locations from strings,
to have the dimensions available.
This allows to refactor tod_manager and not use resources:: ptrs
in its implementation, instead using the objects from the relevant
context.
It uses a shared_ptr, to prevent crashes during play_controller
initialization. But it only holds a weak_ptr, to preserve
previous behavior of skipping whiteboard ops when the ptr is
NULL.
It requires also for us to construct the whiteboard before
constructing the gui, so that we have a valid pointer to pass.
Most likely all of the managers will have to be moved forward,
in this commit we move forward the whiteboard and pathfinding
module, anticipating future commits.
unit_map is modified in many places that don't normally include
map.hpp, so to avoid doing harm by adding this class, I am making
it hold a scoped pointer to the gamemap instead of an actual
gamemap. This results in very few changes.
- The implementation of game_board has to use the pointer.
- game_board must use copy and swap idiom
- lua get terrain function must pass strings to the game_board,
not enums, and we parse them as std::strings in game_board
instead of as c strings in lua api (which was a bit gross anyhow)
The remaining uses are just, checking whether or not the pointer
is null, or resets to its value, or simply storing it in a local
variable.
It might be appropriate to add resources::game_map back as a
function taking no parameters, at least this is flexible
enough to be changed later easily.
This is the result of running, in src/ directory, the following:
find . -type f -exec sed -i 's/resources::game_map->/resources::gameboard->map()./g' '{}' \;
and carefully inspecting the result, and adding "game_board.hpp"
from savefiles toplevel to savefiles [snapshot]/[replay_start]/[carryover_sides_start]
previously this was handled specialy at scenario toplevel sometimes and in those tags at some other times.
accoringly to that change we now set n_unit::id_manager at play_controller s constructor.
