With this, finally all actions run though synced context::run,
so that we not only have a central place that happens before/after
synced actions, we also guarantee that there is no difference between
the original and the replay codepath for all actions.
This should also make upcoming changed to the undo code easier.
This removes `get_teams()`, `get_units()`, and `get_map()` from the display class. These only served as one of the many, many ways to access this data held by the display_context, and that shouldn't be the first-class responsibility of display. Instead, we either access them through the display_context pointer that display holds (whose getter has been renamed to `context()`) or through other more convenient paths (such as play_controller). The editor_display function `map()` has now taken up the mantle of `get_map()`, mostly because both `display::get_map()` and `editor_display::map()` are used, and the former outnumbered the latter.
* Add lua mouse button event handler that can be consumed.
* Fix middle-mouse down/click not getting sent to lua
This is a flexible event handler mechanism to allow for more advanced
add-on features. It does not allow the add-on to consume the value
however, so there's no mechanism for the add-on to requrest the default
action not be executed.
We would normally deal separately with mouse down, up and click, with
the later being an event where the mouse has gone both down and up on
the same UI component. However, Wesnoth's code seems to allow a mouse up
on many UI components to serve as a click, so this implementation
follows that behavior.
This addresses issue #7949
The mouse handling code needs an overhaul, so this patch works with it
in it's current state in the best possible way. The revised code
attempts to restrict clicks to those events where a mouse went both down
and up on the same map tile. It is able to do this with the right mouse
button as well as X1 and X2, but must work as existing click events are
treated for now.
This means that "left click" is managed via the `left_click()` function
which occurrs at mouse down, "right click" via `right_mouse_up()` when
the right mouse button comes up, and the middle button's click behavior
is coded directly into mouse_handler_base::mouse_press() (so no function
is called) and "clicks" when the button comes down. The new
`on_mouse_button()` code will allow the mod developer to consume any
click event, preventing the default behavior, and also receive event
callbacks for up and down events, although the return value is ignored
for these calls and left and middle click occur on mouse down.
If it's another player's turn, then movement points will be reset in a refresh
phase and it's not useful to show current movement.
Partially reverts 978229c247 (af0968d9c3 on 1.16), using the old logic for
the movement range but the allies-based logic for goto_x,goto_y information.
Fixes#6716.
There is a new sdl::get_mouse_state() function that should be used in place
of SDL_GetMouseState() in every case. It returns coordinates relative to
the drawing surface.
With this, the pixel scale option seems to be working without issue.
Fixes#6292, that the planned final destination from multi-turn moves and
interrupted moves was visible to enemies. There are three side-numbers involved
in this logic, listed below; the GUI code was checking whether the move should
be visible to the player whose turn it is, rather to the viewing team.
* un->side(), the owner of the unit
* mouse_handler::side_num_, the side whose turn it is
* viewing_team(), the side of the player whose computer this wesnoth-client is
running on, thus which side's shroud and fog should be applied.
The plans are still hidden for units belonging to local AI sides, to hide any
goto_x,goto_y settings by campaign authors. The edge case in multiplayer of
allied network AI sides isn't tested here, but I think it's a trivial matter
whether or not those plans are shown.
(cherry picked from commit af0968d9c35325ce3b4bdbdb18c6112ea9ed137b)
This additionally:
* Makes all copyright notices identical aside from the starting year for Wesnoth-specific source files. Files not included: mariadbpp, lua, spirit po, xbrz, and bcrypt (crypt_blowfish).
* Removes all attribution from the files, since the vast majority of them are outdated or seemingly just outright incorrect. For example, I would guess that Dave is no longer the sole author of the majority of Wesnoth's current code.
This adds a new overload of get_adjacent_tiles that returns the array instead of taking the address of
the first element (a C paradigm). This also converts the use of the result to range-for loops when possible,
which is enabled b the fact that we're using std::array here instead of C arrays.
This was needed to get the build working with vcpkg's version of SDL, where all the SDL files are
in their own SDL folder. However, our cmake config also has a note saying it was a deliberate choice
to move our SDL files *out* of their SDL2 folder due to certain distros (FreeBSD is mentioned) not
putting the files in said folder in the first place.
Keeping references is bad if a unit dies and the dying unit has a halo
and a long-running listener for the "last breath" event, like in AtS E2
S10. In that case keeping the reference means that the halo will remain
as long as the event runs.
Closes#3673.
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.
as said in the comment, that get_special_bool might return the wrong value, as since 5f58cd7c6d the bc_vector no longer contains disabled attacks we can just remove this code.
fixes#3324
(cherry-picked from commit 44734570dd1824a098252d78dafc0f5a561c13cf)
Since there were weapons included that weren't shown, it was possible for the best
weapon selection to be a hidden one (in which case, the initial selection would be
wrong, and it was possible for the returned index to point to a hidden, disabled
weapon.
This resolves both issues by excluding these disabled attacks from the weapon choices
list altogether. They aren't considered when calculating the best attack either.
mouse_handler::fill_weapon_choices is also used in mouse_handler::attack_enemy_, but
I don't foresee this change should cause any issues there, since you aren't supposed
to be able to actually attack with disabled weapons anyway.
(cherry-picked from commit 00e58f12f9a57b2e25dd4f67efb1255b177e173b)
