After changes in 618659c083b6, the leader keys in Krash's side caused him
to be reborn if he was killed in the previous scenario for S11a-S13a.
[ci skip]
Have objectives match endlevel.
Bump carryover so a more impressive amount is stored next scenario.
On my easy level playthrough I only had 680 carryover. This
change makes it be around 1700 instead.
[ci skip]
Due to rounding error, if the unit was already slowed, it was possible for
the code that calculates the probability to be slowed to arrive at a bit
above 100%. If the AI later simulated another fight for the same unit, it
triggered the assertion that the probability wasn't in allowed range.
Fixed by limiting the probability to 100%.
fix no_leader having no effect
fixes#2604
it previously only worked if both leader_lock and no_leader were set to yes. Now it the type= is preserved if any of the two are given, the difference bewteen those two is that no_leader only works is type= is empty.
this also fixes some wrong parameternames in the the flg_manager ctor declaration.
This commit does not change the default value for those keys: no_leader default to yes in [side]s in [scenario] but not in multiplayer. While leader_lock defaults to the force_lock_settings key in [scenario]/[multiuplayer]
This should help mitigate an odd issue some people have reported with 1.13.11. After reloading a
save *after* executing a first_time_only=yes event, they can execute the event again. Looking at
savefiles for one of the reports, the event was included in the savefile even though it had already
executed. Most likely, when the player reloaded, the event was re-added to the gamestate and they
could execute it again.
The questions is then why the event had never been removed in handler cleanup. I'll have to look
into that further, but this at least ensures we don't get dead events written to config (that
includes saved games).
This adds a tags= attribute to the pbl WML that can be used to specify
comma-separated tags to let users filter on them on the Add-ons Manager.
We don't do anything fancy with the tags at the moment since they can be
matched with the existing filter algorithm without any changes, with the
caveat that the word separator the filter box uses is whitespace instead
of commas -- meaning that to match multiple tags they must be specified
with spaces between them, in any order, and that pasting the tags from
the WML into the filter box will not yield a match as some people might
expect.
There is also no UI for the tags right now other than the filter box, so
they are little more than an implementation detail hidden from the user.
See also issue #2565.
Notably this does not allow overriding credentials or the add-on name,
which is a can of worms I don't want to touch right now. For the former
there's a setpass command already.
Also removed a bunch of unnecessary typedefs:
* the value_type typedefs weren't since you can do map::value_type (granted, that gives you
a const version, but they weren't used anywhere anyway)
* iterator typedefs weren't needed since we have range-for now. No need to construct a pair
of iterators and then use an increment-for loop to iterate over the container.
This refactors ability tests to use a passed-in unit instead of
searching for the unit on the map based on its location.
While it does fix#2247, I am not confident that this won't also
have some undesirable side-effects.
Currently the MP unit tests will randomly fail due to one of the two background wesnoth instances failing video initialization. All unit tests require the display server to be initialized however, or they fail with the same error as the MP tests sometimes fail with. However, the MP tests are the only tests to randomly fail due to video initialization, while for the same travis job the WML unit tests (which run before) and the boost unit tests (which run after) are still able to be successfully completed.
Therefore, the video initialization failures are not entirely random, and the MP tests are also the only tests that experience this failure while also being the only tests that have more than one instance of wesnoth running simultaneously.
tl;dr: the attempted solution here is to sleep for 5 seconds between starting background processes in the mp unit test script.
Also removes starting the display server prior outside of the docker container, since that's not needed anymore.
