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.
Added a new method, void create_engine::prepare_for_era_and_mods(),
which sets era and mod in game classification.
Prepare_for_[scenario, campaign] then set their respective defines and reload.
Conflicts:
changelog
src/gamestatus.cpp
src/gamestatus.hpp
Implemented reloading of configs with define= attributes in both mp_create and mp_wait::join_game().
Added myself to about.cfg and updated changelog.
Conflicts:
changelog
src/gamestatus.cpp
src/gamestatus.hpp
src/multiplayer_wait.cpp
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.
Without this, the engine may match map borders and send the respawnee
back to the player's recall list as those count as invalid locations
like "recall","recall".
This bit was subject to a particularly bad case of code copy-pasting
when the only real variable is the id of the first respawn hub
candidate.
Added a statement to clear the respawn_hub WML variable after running
the code since it's never used again afterwards.
This replaces map-wide ToD lighting with local ToD lighting for overlays
associated with locations that have custom local ToD lighting. The
method employed for this is more or less the same already used by
display::get_terrain_images() bar the complications associated to
dealing with terrain transitions, since overlays don't have those.
Note that for this to have an effect, local ToD lighting must be enabled
in Preferences -> Advanced. This is the default since Wesnoth 1.10.x.
This patch is more noisy than I expected, so it might require some
additional testing before landing in 1.12 to ensure it does not
introduce any regressions.
the warning was a temporary because there was a bug in the code that would have caused this assertion to fail. Since that bugs was fixed, i replaced it with an assert.
It allows the user to browse to the cache (using a desktop API call),
copy its path to clipboard, clean the cache contents (deleting stale
files), or purge it entirely.
This is ideal for people sticking to the same cache dir for very long
and thus keeping content that was generated by previous versions of
Wesnoth they might not even use anymore. Purging the cache might also
aid troubleshooting (although there is a --nocache switch for that too).
The dialog also makes Wesnoth slightly more transparent about its own
disk usage, information which may not be readily accessible to people
without the technical know-how to locate a hidden directory.
For now it's accessed by pushing a button in Preferences -> General,
even though this is not ideal since it is actually Advanced Preferences
material given the nature of the cache. Unfortunately, the Advanced
page's layout is currently monopolized by the advanced preferences
options and I'm not interested right now in solving that UI design
puzzle; it will have to wait, much like the Paths dialog has done and
continues to do for 1.12.
Cleaning the cache removes all stale cache files (files that do not
match the current cache's naming pattern), and purging removes
*everything* in sight in the cache dir.
Ideally we would clean the cache every once in a while without asking,
but for now there will be a user-controlled option to allow doing this
by hand.
