The same change was not and must not be done in the reverse case. It
should be and is possible to mark an already completed objective as
failed.
Consider a case where a player is supposed to capture, but not destroy,
a building. He captures it, the objective is complete. However, later
in the game that building gets destroyed. In this case, the objective
should be changed to failed.
* Surrendering is now possible even in maps that do not use
ConquestVictoryConditions.
* The Surrender button is greyed out instead of hidden when it cannot be
used.
Note: 3rd party KotH maps will need to be modified to work correctly
with this change. Previously, StrategicVictoryConditions was a
supplement to ConquestVictoryConditions. After this change, each works
by itself. So KotH maps will need to remove the ConquestVictoryConditions
trait from the player definitions, or both victory conditions will have
to be satisfied to win the game.
Objectives can be either primary or secondary objectives. Primary ones
influence the outcome of the game. If all primary objectives are
completed the game is won, and lost when any of them fails.
Objectives can be added at any stage during the game, allowing to react
dynamically to game events.
The objectives backend only contains the information about the
objectives themselves. It does not check if objectives are completed or
failed. Instead, the state of objectives must be manually marked. The
backend, however, does check whether the game is won or lost.
Fixes regression #5948 where you could freely build any building by
canceling the production before deploying by restoring the currentItem
checks in the PlaceBuilding order to ensure that the production is still
valid.
- Avoid calling string.Split twice in SprintFont.Measure.
- Change ActorsInBox method of ActorMap and ScreenMap to avoid allocating and intermediate list. As a bonus this allows the sequence to be lazily consumed. Also avoid LINQ in these methods.
- In FrozenUnderFog.TickRender, the method exits early if no players are visible so the attempt at lazy generation was not needed.
- Unwrap a LINQ Any call in ClassicProductionQueue.Tick.
- Merge some successive Where calls in ProximityCapturable into single predicates.
