[wesnoth-commits] [wesnoth/wesnoth] af0968: Only show planned moves to self and allies

[Steve Cotton]

  Branch: refs/heads/1.16
  Home:   https://github.com/wesnoth/wesnoth
  Commit: af0968d9c35325ce3b4bdbdb18c6112ea9ed137b
      https://github.com/wesnoth/wesnoth/commit/af0968d9c35325ce3b4bdbdb18c6112ea9ed137b
  Author: Steve Cotton <steve at octalot.co.uk>
  Date:   2022-01-13 (Thu, 13 Jan 2022)

  Changed paths:
    M src/mouse_events.cpp
    M src/mouse_events.hpp

  Log Message:
  -----------
  Only show planned moves to self and allies

Fixes #6292, that the planned final destination from multi-turn moves and
interrupted moves was visible to enemies. There are three side-numbers involved
in this logic, listed below; the GUI code was checking whether the move should
be visible to the player whose turn it is, rather to the viewing team.

* un->side(), the owner of the unit
* mouse_handler::side_num_, the side whose turn it is
* viewing_team(), the side of the player whose computer this wesnoth-client is
  running on, thus which side's shroud and fog should be applied.

The plans are still hidden for units belonging to local AI sides, to hide any
goto_x,goto_y settings by campaign authors. The edge case in multiplayer of
allied network AI sides isn't tested here, but I think it's a trivial matter
whether or not those plans are shown.


  Commit: 8351fec2aeb36a3a408bfd7fb89e7aa5d31723ba
      https://github.com/wesnoth/wesnoth/commit/8351fec2aeb36a3a408bfd7fb89e7aa5d31723ba
  Author: Steve Cotton <steve at octalot.co.uk>
  Date:   2022-01-13 (Thu, 13 Jan 2022)

  Changed paths:
    M src/menu_events.cpp

  Log Message:
  -----------
  Don't leave a hex selected when using 't' to continue a move

Fixes the minor part of issue #6292, that functionality showing the path
to a selected hex was active after continuing an interrupted move. That
feature is completely separate to the main bug of #6292, but it looks
confusingly similar in testing. The intended way to activate this feature is
via the "Select Hex" hotkey, which doesn't have any keybinding by default, so
should only be reachable by people who want the feature.

It would be good to refactor the movement handling so that it's not split
between mouse-handling and menu-handling files, but it would also need a lot of
work and would be out-of-scope for backporting to 1.16.


Compare: https://github.com/wesnoth/wesnoth/compare/22bdbc7c88b6...8351fec2aeb3