previously the unit ctor could invoke arbitrary umc lua code, for
example via advance_to -> add_modification ->
resources::lua_kernel->apply_effect and during that call the unit was
not owned by a unit_ptr, so the code could not use unit_ptr objects at
several places because the unit might not be owned by a unit_ptr object.
this changes it so that the during events the attack_type references its
context units always by location, like it was done in 1.12, considering
the soon 1.14 release i think this is the best fix
The problem with the old implementation basically was that if a wml
script replaced the unit in a attack events the
attack_type::self_/other_ would point to an outdated unit during the
next handler of the same event.
[ci skip]
This reverts commit 0089357edb0c3900c5645a138520391bb0f09626. It wasn't suitable for
all usecases, and it's impossible to make it a dialog option.
Fixes#2628
This ensures that throwing an exception through
game_events::manager::execute_on_events() won't corrupt the stack frame
counter and disable event handler cleanup forever.
I also added a safety check in case there are some kind of ephemeral
event handlers which run a nested game loop and never return. Saving in
such a state wouldn't be safe.
This reverts commit 45cab78cfb67441dff36826162e36c980a72a222.
Further testing indicates that exceptions can indeed pass through the
function, and therefore marking it as noexcept isn't safe.
Don't show carryover report after final battle.
Make orcish fortress look like an orcish fortress.
Fix trees being added when player can see it.
Continue to credits at end of dialog in S14a.
Fixes#2612. Bug above was caused with a legacy value for compress_saves ("no") in the user's
preferences file. Since that didn't match an option ID, the game passed an invalid value to
menu_button::set_values, which then asserted. It's not really worth it to add value aliases to
handle the legacy compression values, so we just reset the initial selection to 0 if an invalid
(in this case, one of the legacy values) is used. Might mean some user's preferences get
inadvertently reset,but they can simply update their selections again. At least it's not crashing.
Currently will remain disabled everywhere, but this allows for enabling LTO for optimized, non-xcode jobs just by changing the value of the LTO variable.
Moving it out of the same directory as the git repository means that the object files won't be copied into the temporary docker container when it's being created.
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]
