The support parameter in the attack evaluation quantifies how much
power the AI can bring to an attack hex. This is supposed to include
the attacking unit itself. However, in some circumstances (such as when
the unit cannot move for one reason or another) this unit is not
accounted for. If no other units can get to this hex either, support is
(erroneously) set to zero, resulting in an attack score of zero, which
in turn results in no attack. Skipping the multiplication of the score
by support in this case does not affect comparison with other attacks
here, as this is by definition the only attack possible on the given
hex.
Note that the '!is_surrounded' conditional is also covered by 'support
!= 0' and can therefore be deleted.
This fixes bug #23720.
Some explanations:
- savepng uses setjmp, so I changed it to C; this guarantees that someone does not accidentally introduce a C++ object in it (unlikely though that is)
- The loop in multiplayer.cpp seemed intended to allow the command-line to request repeated plays, so the break was removed rather than refactoring it to an if statement
- Some uninitialized structs were changed to be zero-initialized
- Use luaW_toboolean instead of lua_toboolean
- Needed explicit constructor for vconfig iterators, since their only member is const
The unit::get_ability_bool() function accessed resources::gameboard that
is not set in the editor. Now the function receives the display context
as a parameter instead.
I also fixed two crashes on editor startup in MSVC debug builds (both
caused by indexing the teams vector when there aren't any teams), and the
GUI2 unit list dialog showing wrong status icons.
Plus two minor changes:
- Support [spacer] to add space between options
(This may or may not be kept indefinitely)
- Deprecate the misleading [combo] in favour of [choice]
This goes along with the principle of using references when a pointer
cannot be null. It's also better for data encapsulation to not give
someone the address of one of your private data members.
When pressing End Scenario and proceeding to the next scenario, the user_team_name shown on Menu|Status Table is incorrect.
If you Load (from the title screen) the saved scenario-start, the correct user_team_name appears.
This is caused by the random-shuffle feature for multi-player scenario. This fixes it for Single-Player campaigns and tries not to break it too badly for randomized Multi-Player campaigns.
