Avoid crash when planning moves on planned recruits (Bug #18637)

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.
This commit is contained in:
Wedge009 2015-09-24 00:30:02 +10:00 committed by Ignacio R. Morelle
parent e0594b2b44
commit 240f3c0c52
2 changed files with 8 additions and 0 deletions

View file

@ -57,6 +57,7 @@ Version 1.12.4+dev:
* Fixed hang when attempting to make a screenshot from a non-existent map via
command-line (bug #20900)
* Fixed cases of wrong unit type used in planning moves (bug #20299)
* Avoid crash when planning moves on planned recruits (bug #18637)
Version 1.12.4:
* Security fixes:

View file

@ -138,6 +138,13 @@ move::move(config const& cfg, bool hidden)
void move::init()
{
// If a unit is invalid, return immediately to avoid crashes such as trying to plan a move for a planned recruit.
// As per Bug #18637, this should be fixed so that planning moves on planned recruits work properly.
// The alternative is to disable movement on planned recruits altogether,
// possibly in select_or_action() where the fake unit is selected in the first place.
if (get_unit() == NULL)
return;
assert(get_unit());
unit_id_ = get_unit()->id();