This commit manually merges all LoW commits from the 1.12 branch into
master.
This might revert some 1.13 commits which i wasn't able to merge
correctly.
This means the Lua code implementing the WML tags are now solely
responsible for parsing the comma-separated id list. It just so happens
that I added code for that without realizing that I was duplicating
existing functionality on the C++ side.
As a result:
* wesnoth.add_time_area and wesnoth.remove_time_area can operate on
time area ids that contain commas (if someone feels this is needed
for some weird reason)
* [time_area] no longer warns about adding time areas with commas in
their ids (actually adding the first id of the list instead)
* [time_area] remove=yes and [remove_time_area] still handle
comma-separated lists of ids, in the Lua side instead of C++.
This makes the Lua API for this consistent with [event]/[remove_event].
Since the Lua API functions in question are undocumented at this moment,
it's unlikely this impacts anyone, really.
http://gna.org/bugs/?23674
We don't want to use the units and gold stored in the global variables if we already get them from normal carryover becasue that results in having them twice.
If this breaks compilation for MSVC++ users, make sure MSVC++ passes
-D_WIN32_WINNT=0x0501 to the compiler, or revert this commit. CB and SCons
already do that, so...
This change only actually concerns binaries built with the console
subsystem flag, which isn't the case with our official project files or
SCons recipe.
This makes it so we no longer try to steal the console back to a log
file when using --wconsole with the new redirection code. Now the
--wconsole switch triggers a special mode of the log file manager that
uses a native console instead of log files.
As a necessary bonus to appease compilers, the GUI2 version info dialog
now uses the correct log file path when not started with the --wconsole
switch. Yay!
A maximum of 8 previous log files are kept around in the logs directory.
Older files are automatically deleted during initialization.
I could've achieved this with stat calls, really, but the log filenames
are simpler and faster to process.
This replaces SDL 1.2's built-in stdout/stderr redirection, which writes
the log file to the process working directory (usually an
admin-restricted location) instead of a more accessible user-writable
location.
My approach combines stdout and stderr into a single log file which
includes the process id and timestamp in its filename in order to
accomodate multiple instances and (coming later) log rotation. The log
file is created in the user's temporary directory defined by Windows,
and then relocated to the game user data dir as soon as it is set-up the
first time, placed in the Windows-specific logs/ subdir.
The most pressing issues this solves are the lack of built-in
stdout/stderr redirection in SDL 2's SDL2main.lib entry point, and
Unicode path issues with SDL 1.2 (bug #22897). Additionally, it allows
us to not have to rely on UAC virtualization anymore; this is arguably
far more important because it has been known to break on occasion (e.g.
<http://r.wesnoth.org/t42970>), and starting with version 1.13.2 we want
to declare Windows Vista - 10 compatibility in our side-by-side manifest
(see commit e119f4071f047c6d740ebec4636985fdf39349bc).
Currently missing features coming later:
* Log rotation (otherwise the logs/ dir may grow forever)
* wesnothd support (although the code is already required to be linked
into wesnothd due to it being required by the FS API)
* Integration with the version info dialog
From previous commit "Tab-completion added for in-game whispers" <6280229> now whisperers set removes disconnected users. Now <b549ac2> regarding bug #9742 should be completed.
Attempt to work-around bug #18637, where planning moves on planned recruits results in a crash (because get_unit() is null when move::init() is called).
This isn't a comprehensive fix because clicking on a planned recruit will still result in the usual display feedback for planning a move. The difference here is that attempting to place a planned move will result in nothing happening when the mouse button is clicked (as opposed to the assertion failure or crash which happens currently). It is better than nothing, I believe, unless there are negative side-effects of which I am unaware of.
As per the bug report, the ideal solution is to either get planned moves on planned recruits working properly, or disallow this movement altogether.
