The block on line 99 was entered for BW years, but shouldn't have been.
Fixes#3187.
(cherry picked from commit 5e97d1505f529c45ff8e48f694b6fd938b56e3af)
In the scenarios where one plays him he retains now his usual overlay.
Master only, as the scenarios depend on changes in previous scenarios,
which breakssave compatibility.
[ci skip]
Now content that is loaded via [load_resource] is placed to the position
where the [load_resource] was. This fixes a problem where previously one could
not use lua variables/functions created by the [resource][lua] because the
engine would put the [lua] tags from the [resource] after the [resource] from the
scenario.
This time it uses size_t indicies instad of vector iterators to prevent
possible bugs arisong from invalidating iterators when the size of the
vector changes.
This reverts commit b3e1680f886ec27c29150912bb27949d7cdd7f6e.
In the long run i think it might actually be better to allow [event] and
[lua] to have a order/priority attribute similar to lua on_event events.
Then this commit would probably not be needed anymore.
Noticing that orcs can control undead units feels strange. This
can give the AI an advantage too. One would expect monsters and
undeads to move autonomously.
This makes sure that when Jevyan dies, we check for Aethyr's
presence before doing anything, so the player loses immediately
if he's alive.
Furthermore, we must hide the last orc leader, or his death will
make the player lose.
This reverts commit 706740220957a9313909f5cc358ba5aba3bf4118.
The commit used the `pos` iterator after invalidating
it (passing an iterator to `config::add_child_at()`
invalidates it), resulting in undefined behavior.
I originally did this in 699047766a8852014df20c44d5ed84dadb37015e and then reverted it in
08a866dc20e678602f65f0cdedb21fb28a0bfa8c due to @gfgtdf pointing out the object was never
actually destroyed since io_service::stop was never called (issue #1927).
This new method foregoes the custom wrapper class and instead waits for the worker thread
to terminate in the wesnothd_connection dtor. The use of the wrapper class is also why using
thread::detach alone worked (@jyrkive) and using join did not.
Additionally, the ptr alias is now of a unique_ptr instead of a shared_ptr.
I have verified that the connection dtor is actually called. This new method makes it clearer
what's actually going on.
This covers several things:
Instead of creating a new worker thread manually and having it set class member state flags,
I instead utilized std::future and std::async. As far as I can tell, this should avoid the
(albeit unlikely) potential race condition wherein the ls could close before loading at all
if the thread was delayed in starting.
Removed the timer interface and split it into two components:
* A drawing callback that handles the animation. This has its granularity retained at 100 ms,
but can be easily adjusted if we want it to go faster.
* A pump monitor that runs much more frequently (every time events::run_event_loop is called,
technically). This handles checking the state of the std::future object and will then close
the window. This makes the loading screen a bit speedier compared to the previous iteration
since it no longer wastes time waiting for the next timer callback to close.
The one bit I'm not 100% sure about is the check for the future object's ready state in the dtor.
Though, relatedly, I wonder if perhaps we should wait for the worker thread to complete in that
case instead of exiting....
Also shuffled a few things around, such as immediately setting enter/esc disabled in pre_show
instead of waiting for everything there to finish.
Do note there occasionally seem to be a few odd issues with the dot animation after this commit.
Will look into that. But it may be some texture cache-related issue...
This also cleans up some unused log defines and a VS 2013 conditional include.
Also covers uses of boost::this_thread.
Turns out std::thread calls std::terminate if it's destroyed while still joinable.
thread::detach needs to be called or else the program will crash.
There's also no standard library equivalent of boost:🧵:timed_join so I just
replaced it with the is_worker_running_ variable.
this fixes remove_modification for these effects, and also a bug where these effect would be applied twice after a unit advances.
fixes#3264fixes#3220
This also changes the implementation of [unit_overlay] to use [effect]s now so tht changesdone via [unit_overlay] ae persistent as they were before.
this has multiple advantages:;
1) it fixes#3594, an assertion failue that happend when a unit with
only one attack attacked when that one attack was disabled.
2) It now creates each pair or battle_context_unit_stats only once for
each pauir of attacks, previsouly the coud would create multiple
temporary battle_context_unit_stats objects to for exampel check
"disabled"
3) It simplifies the code by removing special handling of some cases.
