[ci skip]
These were all mentioned between 1.13.13 and 1.14.3, meaning the remaining changes
are everything new in 1.15.0-dev so far. Also removed one entry that was mentioned
twice in the WML Engine section.
Automatically checking the path relative to a maps/ directory without binary
path support results in an invalid path almost every single time. If I remember
correctly from my testing, the only time that worked was if I added a data/maps
folder.
Since there were weapons included that weren't shown, it was possible for the best
weapon selection to be a hidden one (in which case, the initial selection would be
wrong, and it was possible for the returned index to point to a hidden, disabled
weapon.
This resolves both issues by excluding these disabled attacks from the weapon choices
list altogether. They aren't considered when calculating the best attack either.
mouse_handler::fill_weapon_choices is also used in mouse_handler::attack_enemy_, but
I don't foresee this change should cause any issues there, since you aren't supposed
to be able to actually attack with disabled weapons anyway.
This is a debug mode-only dialog. If I want to spawn a unit, the game
had better allow me to spawn any unit I want. do_not_list was created
for use by wmlunits anyway.
[color_adjust] needs to be able to use absolute values as large as
2*255 in certain edge cases to set the screen a single solid colour when
interacting with time of day colour shifts.
Fixes#3144.
Leaving theme= unspecified ought to have the same effect as providing it
and setting it to an empty string. Without the check for a nil value,
however, it would result in a crash like this:
20180519 22:31:54 error scripting/lua: lua/wml-tags.lua:922: bad argument #3 to '__newindex' (string expected, got nil)
stack traceback:
[C]: in metamethod '__newindex'
lua/wml-tags.lua:922: in local 'cmd'
lua/wml-utils.lua:145: in field 'handle_event_commands'
lua/wml-flow.lua:6: in function <lua/wml-flow.lua:5>
Technically, all this code should work on Vista, (including the recent switch to using
SHGetKnownFolderPath), but since we're also considering requiring Visual Studio 2017
for building, we need Windows 7.
The specific case that brought this to our attention was color=100. In case such values
are used, the color reverts back to the default color for that side, as before.
The new codepath (team::get_side_color_id_from_config) is essentially the same as the old
one but more robust (range checking, for example, the lack of which was causing the crash
before).
