As players who haven't figured out certain strategies might have too much
trouble beating the third repetition. Also waiting until the fourth
repetition may be too long and have players question what's going on.
Bug was that a troll on 4,21 could move through the avoid area to attack
player at 11,22 which is a likely occurrence. Expanding the avoid area
further seems inappropriate as troll avoidance is more likely to be noticed.
New implementation ensures only player will trigger the wose, maintains
proper look to the player, no longer interferes with trolls attacking, and
simplifies code.
This reverts commit 70b468070b71616aa3663088b6ad171391d0c4f0.
As I said in the commit message, the fix is not pretty, and
@CelticMinstrel said in IRC that a different fix would definitely be
better. I'll fix the problem by having an animation automatically
release the unit when done, instead (next commit).
He's been a silver-crowned hero until this scenario, and in
the final scenario he's still loyal with dialogue if he dies,
so make him easily visible to the player.
The problem was that the kill animation retained a reference to the unit.
Triggering a Lua garbage collection (which destroys the animation object)
fixes it, although it's definitely not a pretty fix.
Closes pull request #2313.
Instead of trying to iterate over two lists at once, just construct a new list of matching
handlers. This should fix#2310 too, since it ensures any additional events added after
iteration begins don't get executed.
Note that this still doesn't allow the --upload
functionality to work. After this fix,
wesnoth still complaints about unordered WML.
It is believed that this is a separate issue though,
happened because of the latest simple_wml changes.
The [kill] tag can run animations. But it can also fire the `last breath` event, which can call [kill]. When we get back to the original [kill], the unit is gone, causing an error attempting to run the animations.
Added a check to ensure the unit is still on the map before we attempt to run the animations.
The Issue also requested that [harm_unit] pass the unit causing the harm into the [kill] tag so that `last breath` could use the secondary (killing) unit available like it does elsewhere.
Closes#2298
I also moved the animation to be played *before* healing, which is the same
order as in C++ code. In the previous order, the animation isn't played for
some reason.
Fixes#2295.
send_to_players was only used in the game class implementation. The other two functions were
used in both server.cpp and game.cpp, so it made sense to be declared in server.hpp.
For some damn reason, I needed to specify `game::error` in the global namespace to get this
to build now. No idea why.
It was caused by two independent bugs. Fixing either would have made the
map labels to show up: I fixed both.
First, map_labels::visible_global_label() is intended to check whether any
label from the player's team is shown in a certain position, in order to
check if a global label in the same position can be shown. In the editor,
the "team name" is the empty string - the same as the "team name" for
global labels. As a result, all global labels were considered to be in the
player's team, and therefore every global label was suppressed in favor of
itself.
That wouldn't have been a problem on its own, however. Commit 2fb13f89daa25c8443e537a3cbafb43bb4301b4f
added a check that makes all labels visible in the editor, before checking
if they overlap team labels. The problem was that the check wasn't working.
It's true that there are no teams in the map editor, but the same isn't
true in the scenario editor - and labels can only be placed in the scenario
editor.
I fixed the first problem by checking if there is a viewing team to begin
with, and the second problem by calling display::in_editor() instead of
checking the number of teams.
This reverts commit 252e77443333ba2b0e0b3abbf070ce507d8d33b6. Turns out the key is used
by replays.wesnoth.org and not the client. The name= key accessible otherwise is only
temporary data sent by the server, whereas this key is saved in the replay.
When a host canceled a game and returned to the lobby, they would see their just-closed game briefly
appear in the game list before disappearing again. Upon debugging, I found that the client was receiving
gamelist data that included the closed game. A game-was-deleted diff entry is still sent by cleanup_game.
NE and SE base/standing frames. Defending and pincer-ing animations for both NE- and SE-facing frames. Stinger animation for SE-facing frames. Portrait replaced.
Previously, MP Staging was using connect_engine::connected_users() to fill in the user list.
However, I noticed that the server was already sending the user list to all clients, including
the host, so I could unify the handling between Staging and Join Game by just using the server
data for both.
I've also added appropriate indicators for host, observer, and self in the list for both dialogs.
Additional host= and observer= status keys are sent by the server for that purpose.
I've also made the server dispatch the player list to the host when a game is created. This is
slightly redundant, since the host is the only player at that point, but it's easier than creating
a user config locally, or using connected_users(), not to mention easier to maintain.
The wesnothd::game::send_user_list function no longer exists early id `description_` is null.
No idea why it did that. It's not even used in the function. Anyway, it needed to be removed in
order for the above change to work.
Speaking of the host's copy of the player list, I haven't touched that. It's still needed for
managing things in the connect_engine. Might simplify things further in the future by delegating
more handling to the server, since it has a lot of the data needed already, but that's a different
project.
Clip_rect_setter was implemented incorrectly: it ignored the previous clip
rectangle and sometimes made the clip rectangle *larger* than it was
before. That allowed partially obscured widgets to draw to a larger screen
area than they were supposed to.
Fixes#1583, #1591, #2202.
