This was a casualty of 575286cb8609a913bc6d7788e06647a9f5519325
even though this particular use case is purely diagnostic for
devs reference when handling bug reports.
This includes information on the renderer's name, whether it's
a software renderer or it's hardware accelerated, whether vsync
is enabled, and the maximum texture size.
(The other items in SDL_RendererInfo do not seem particularly
relevant to us right now.)
At some point in 1.17.x, the check for whether the game window
was null disappeared. This brings it back by exposing a check
through the video namespace so as to avoid piggybacking further
on the video::get_window() function, which we are meant to avoid
using.
The logic we used here hasn't had the desired results since the move
from using custom Visual Studio project files to using the CMake
integration system, so this patch updates it to match the layout we get
with the CMake integration on Visual Studio 2019 and 2022.
The previous logic remains an alternative for configurations where it
could be beneficial to use pwd as the data dir.
The previous bugfix fixed a crash when loading savegames with units whose
abilities accessed the map while the display_context was still being
constructed, however it reintroduced a bug in the scenario editor. Using the
unit tool always crashed when adding any unit.
This commit uses 4d1fc268b1's code path whenever possible, however it falls
back to 6a21fdc675's code path when 4d1fc268b1 would assert. In practise one
path is used in game and the other is used in the scenario editor, but doing
the logic in this way ensures that any edge cases are going to affect the
scenario editor rather than the game itself.
Cherry picked from commit 1485cfd6256b73bb06aa34c512c2890749b45487,
with conflicts because code from attack_type::weapon_specials() has
moved to attack_type::weapon_specials_impl_adj().
* Add basic achievements functionality.
This reads the mainline achievements.cfg and then all the achievements of each installed add-on.
This is intentionally handled separately from other WML loading so that:
a) All achievements and their status are able to be displayed on the main menu right after Wesnoth starts and regardless of which add-ons are active.
b) Add-ons can add additional achievements to other content, whether UMC or mainline. For example, a modification that adds more achievements for mainline campaigns.
Marking something as achieved is handled by the new [set_achieved] tag and whether an achievement has been completed can be checked via [has_achievement].
There is no attempt to prevent people from manually editing which achievements they've accomplished.
NOTE: These are *not* in any way related to Steam achievements!
Because of the move to hardware rendering in commit
afd6baa7cf1685610c72305f5c9f989078462dff, some relevant info
was lost that was previously used to limit bar height in
particular.
This patch re-adds a dimension check and additionally ensures
that the bar width doesn't exceed the tile size either.
Fixes#7171.
There were two `--exclude` statements both pointing at the data/test
directory before, which was a trivial bug.
Exclude cve_tests because of the binary file that's masquerading as a .cfg;
I think it's correct to exclude the whole directory because any new tests
added there might also use weird edge cases in the parsing.
Exclude lua_tests as a "keep this PR small" thing. We should fix the bugs in
wmlindent, but I don't want to take on that work.
The exclusion of TerrainWML is again because I don't want to take on the work
of working out whether it's problems with terrain masks or bugs in wmlindent.
Most of the files in those directories wouldn't be changed, the ones that would
(or would trigger an error about not being valid UTF-8 ) are:
* data/test/scenarios/cve_tests/test_cve_2018_1999023_2.cfg
* data/test/scenarios/lua_tests/functional/lua_functional.cfg
* data/test/scenarios/lua_tests/wesnoth/map/mapgen_filter.cfg
* data/test/scenarios/wml_tests/TerrainWML/test_terrain_mask.cfg
I think I'm using two wmlindent bugs against each other here, putting two
opening statements on the same line to balance two closing statements on the
same line. However, the unit tests ought to be code that can be cut & pasted
elsewhere without causing indentation problems, and this is simpler than fixing
wmlindent's Lua parsing.
This doesn't cover all of the unit tests, it's the result of running wmlindent
on all of them and then reviewing whether the changes were bugs in the test, or
whether they're bugs in wmlindent.
Note: there are two cve_2018_1999023 tests. The other one needs to be treated
as a binary file, but the one changed here is plain text that loads its attack
from a separate file.
The change in start_position_generic.cfg doesn't seem good, but it's not
particularly bad and it's what wmlindent currently does.
For example, UtBS' Quenoth Elves now appear as a subfolder of Elves, and a major
reorganisation of animals is being discussed in https://r.wesnoth.org/t56522 .
Multiple levels of nesting are supported. If [race]help_taxonomy= points to a
race that isn't defined, or isn't defined with the current set of add-ons, then
it will fall back to adding the race at the top level. Discovering a unit
belonging to a subgroup will automatically treat the parent group as discovered
too.
I may have missed a trick in writing this nicely, the code uses several different
traversal patterns over the tree that it's constructing.
These orbs no longer look the same as the player's own orbs, so they
won't cause confusion in multiplayer.
The relevant part of the advanced preference now shows:
```
[ ] - Show ally orb
[ ] - During ally’s turn, use a two-color orb to show movement
Radio buttons for colors: ( ) ( ) ( ) ( ) ( ) ( ) ( )
```
That offers these choices:
* Don't show ally orbs at all
* Always use the one-color (with ally color, not status)
* Use the two-color when that ally is playing, single color at other times
* Use the two-color when that ally is playing, no orb at other times
Rename some `allied_orb` functions to be `ally_orb`. This makes them consistent
with both the names of the corresponding `enemy_orb` functions and the WML
attribute that's used in the preferences file.
This probably doesn't need a change to the in-game help, at least for the en_US
version of the documentation. The current text in data/core/help.cfg is:
* Blue for allied units, except during that ally's own turn.
* During the ally's own turn, their units will be shown with the colors showing
whether the units can still move and attack; however their moves, and the
corresponding orb changes, are delayed as explained in "Shroud and Fog of War'.
The vital commit is fd766eba2b4cf59c7123d46189be373e2cee959d, but
I'm taking the most recent version of vcpkg as the new baseline
because it might as well use the latest.
The collector_base class has been deprecated in Boost 1.81, and we're compiling
with Werror on the Windows CI so it needs an immediate fix for the new vcpkg.
Add some spacing to make it clearer what is grouped with what, move the
disengage orb's setting to be part of the partial orb's group, and add
a tooltip for it.
This dialog uses checkbox labels as section headers to indicate what the rows
of colors refer to. This commit doesn't change that, but it makes the grouping
clearer. Actual section headers would take additional space and probably not
look any better.
