The crash occurred if
* the AI simulated three fights for a unit in a row
* the unit was initially slowed
* the unit had a chance of killing the attacking unit in the first
fight, removing the slow status
* the second fight was NOT simulated with Monte Carlo mode...
* ...and the third fight was.
It was my mistake from commit d83e0176. I hadn't understood the meaning
of those two function parameters correctly. They don't need to be set to
true if the target unit is already slowed... and, in fact, they must not
be set to true if the attacking unit doesn't slow.
What happened here is that the combat matrix thought that the attacker's
attack slowed the defending unit, placing the result of some of
attacker's hits in the wrong plane. Meanwhile the calculation about the
probability that the defending unit is slowed produced the correct
result. In the next battle, when Monte Carlo mode scaled the "not
slowed" HP distribution with the probability of not being slowed, it
detected the severe discrepancy (in the example case, probabilities only
added up to 12,5 % instead of 100 %) and crashed the game.
This commit fixes the issue by passing correct parameter values.
Fixes#4068.
Refactor to using location_id for the location of the book, because it appears
multiple times in the .cfg file.
An edge case to this edge case: if DV's turn starts with DV next to the book
and one of DV's units on the book, DV doesn't move until the next turn. This
was also true if the unit moved to attack something, and works in the player's
favor, as it gives Malin an extra turn to grab the book, so I'm treating it as
a feature.
If DV does grab the book, explicitly say in the objectives that it's now a race
to the escape tunnel. The sequence for that is:
* DV takes the book (no messages at all)
* silently update objectives (escape to win, same as Malin taking the book)
* player ends turn
* DV moves, Malin asks if he's going to be left behind
* start of player's next turn: objectives shown (race to win)
