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.
No pun intended.
This micro-refactoring step will be required for introducing
functionality that requires to know the config cache files' naming
pattern.
This avoids the casting to superclass, and it's also a bit faster,
in the refactor of the redraw_unit function we cache all the values
from display that we need locally.
Delete a #pragma that tries to paralellize a BOOST_FOREACH loop. This
doesn't work as boost inserts lines before the for, thus hindering the
compiler to find the 'for'.
According to clang boost/function.hpp does not have include guards,
and from inspecting clang diagnostics we include it many times
in several compilation units. This commit adds an external include
guard to all of our includes of this header, it was made using
find . -type f -exec sed -i 's/^#include <boost\/function\.hpp>$/\n#ifndef I
and inspecting the results.
Previously, only terrain with C or K in the terrain code passed the
SLF. Now we check whether the hex is a castle instead, independent of
the terrain code.
The dialogue was changed to make it less basic, and the map was altered
to have the player start in the West, with Al'Tar now to the North.
This enables the player to be more actively involved in the battle
earlier on in the scenario.
