* 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.
* Add ability to allow secondary authors to upload an add-on.
The secondary_authors attribute is a comma-delimited list of forum accounts that can also upload updates to an add-on. Secondary authors can't change the primary/secondary authors and can't delete the add-on.
The primary author can also make someone else the primary author by:
* Putting their username in the secondary_authors attribute
* Putting someone else's username in the author attribute
* Uploading the add-on while selecting themselves
This works since they are still (until the upload is done) the primary author in the database, so they are allowed to change the authors list, including in this case.
Required for the updated primary key - the max allowed primary key length is 3072 bytes which isn't enough when there are three VARCHAR(255) columns and each character uses 4 bytes. The max length of the data in these columns so far is also well under 100 characters.
The cause is that somehow, during regular play, MP campaigns can end up with duplicate values in the [content] data for each [addon]. A very similar issue was fixed in 6c980d12dcd56ccd16ff8b7150cd15ef19f0a821, but there's apparently some other way to trigger it that I haven't been able to reproduce. Since the error itself is harmless, it'll just be avoided server-side to avoid the spurious errors in the server log file.
This will also accept them during multiplayer matches, but it will still
warn if the unit's stats have changed. When using the new option, the
checksum includes data that has been ignored since 93fe5607a658c74b987.
The island gives the player two fronts to progress on, and it's early enough
to give the player time to prepare for the SoE. Hint to them about improving
their recall list.
When trying to add that hint as a single-line change to the dialogue, I
reviewed the existing text and felt it didn't flow well. Reading the feedback
thread, Delfador should have more emotion about finding his childhood home
overrun; however I've gone for practical thoughts first.
The hint isn't #ifdef to only appear on easy, because the text wouldn't flow
without it - take that line out and it goes from "there are more orcs than I
thought" to "we must fight these orcs, who aren't the ones at the SoE". Also,
players who are already doing XP management can feel knowledgeable when they
see it.
