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
parent 8d22b2f5f3
commit 53e79232e7
2 changed files with 8 additions and 0 deletions

View file

@ -189,6 +189,7 @@ Version 1.13.1+dev:
* Fixed bug 23060: unit stat tooltips do not show.
* wmllint, wmlscope, wmlindent and wmllint-1.4 now run on Python 3
* Text boxes tab completion now lists friends and whisperer nicks for easier answer (bug #9742)
* Avoid crash when planning moves on planned recruits (bug #18637)
* Fixed cases of wrong unit type used in planning moves (bug #20299)
* Fixed hang when attempting to make a screenshot from a non-existent map via
command-line (bug #20900)

View file

@ -144,6 +144,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();