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.
Those are sometimes relevant (for example, empty WML variables or
containers/arrays). We don't want to conceal the truth here because this
is supposed to be a debugging aid.
Also accessible in:
- Weapon specials ([filter_self], [filter_opponent], [filter_attacker], [filter_defender])
- Abilities ([affect_adjacent][filter])
The backstab weapon special is now implemented using this.
(In a weapon special filter, units are guaranteed to be facing each other.)
The problem this tried to solve was solved long ago, when the new GUI2
[message] dialog was introduced in 1.5.x. Formerly, [message] was
displayed at the top of the screen, so with sufficiently long messages
and a small screen resolution, the viewport could be scrolled in such a
way that the target unit was covered by the dialog.
Nowadays [message] is displayed at the bottom and the scrolling
algorithm is more or less sane, so this hack is completely unneeded.
(For reference, this was originally introduced in commit
83a332a869. For a reference screenshot of
what it would do back in the day, see
<http://www.wesnoth.org/images/sshots/wesnoth-1.1.9-shot3.jpg>.)
Thanks to celticminstrel and vultraz for bringing this up on IRC.
boost::locale::generator::add_messages_domain() interprets the slash
specially, interpreting everything after it as an encoding name.
It's not clear to me why providing a textdomain with an erroneous name
like this causes Boost.Locale to throw a boost::locale::conv exception
(invalid_charset_error, apparently) when handling t_strings bound to
completely different textdomain, but if we can avoid the issue
altogether then that's good enough.
Made the legacy implementation skip and warn about these names too even
if bindtextdomain(3) says nothing about slashes having a meaning.
