* 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!
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.
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'.
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.
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.
Units still using this in their descriptions will have the player-visible
header change from "Special Notes:" to "Special Notes (1.14-style, please
update to the new list format)".
The SPECIAL_NOTES macro was originally removed early in the 1.17 dev cycle.
That removal was reverted and postponed in the roadmap until Jan 2023, on the
grounds that it's a lot easier to test 1.17 when the big add-ons from 1.16 can
run on it.
In 1.16, UMC that hasn't upgraded yet already has a cosmetic bug - the help
pages of units still using the {SPECIAL_NOTES} macro will include duplicate
notes (assuming the expected usage of {SPECIAL_NOTES} as a heading in
[unit_type]description=, which is followed by old-style notes). These are minor
cosmetic bugs, which are expected to be removed as UMC gets updated.
That leaves the issue of what to do with the deprecated macro in 1.18. My
feeling is that we can easily continue to support the macro, albeit with the
cosmetic bug, so we should keep it for 1.18. However we could make it clearer
that the duplicated notes should be removed from the UMC.
This also removes some docs about NOTE_*s, those macros have already been
removed after being deprecated in 3568b5ff66.
Covers the math for [attack]add=, [attack]divide=, [attack]multiply= and
[attack]sub=. The behavior is the same in 1.16.
* 5 + 2 = 7
* 5 - 3 = 2
* 5 + 2 - 3 = 2. Yes it does, that's half of why this unit test exists ...
* 5 + 2 + 3 = 8
* 5 + 3 + 2 = 8
* 5 + 2 - (-3) = 7
* 3 * 3.34 = 10
* 3 * 3.334 = 9. ... and that's the other half of why this unit test exists.
