Previously statistics were stored in global variables, now
it is a part of saved_game. With this saved_game now finally
represent the contents of a safefile as it was intended to,
without needing to fill the statistics part in some global
variable. (See also #4672 )
In particular now no longer have to manually reset the
statistics as random parts of the code, it gets reset
along with the saved_game object. Also it is now in theroy
possible for multiple saved_game objects to exist.
Statistics was split in two objects, the statistics_record
which only contains the data, and statistics_t, which
provides methods to modify statistics during a game (to get
cleaner dependencies)
This fixes multiple related bugs with statistics in replays:
- #4133 (stats not bring reset when loading a replay)
- #4133 (duplicate entry for current scenario in replay)
- #4441 (wrong stats at the beginning of a replay)
And issues with statistics being lost for non-host players when
reloading a game in (online) mp (no ticket for that one found).
This is a complement to #7416 where it replaces opening the replay's download URL in a browser with directly downloading it into the player's save folder.
At some point in the future I'd like to come back and add some search parameters - right now it shows the game history of the currently selected player in the lobby, but ideally it would instead have options for player name, era, scenario, etc.
* 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!
This implements an add-on extraction progress dialog that does not
actually run its own event loop, allowing the caller to take ownership
of it (display() static method) and update its state using a callback
function object. The object in question is passed into the add-ons
management API and used to update the dialog status each time an add-on
file is written to disk as part of the pack extraction process.
In order to avoid stalling the extraction process in UI code, the
callback is invoked for every single file, but the dialog's progress
update method places a time restriction on GUI2 API calls of 120
milliseconds -- this is a good throttle interval that allows add-ons to
be extracted in about the same amount of time as before while still
updating the progress bar smoothly enough for add-ons that take longer
than that.
(This is not the most trivial code to test, so it is suggested to add a
sleep/delay API call in unarchive_file() in src/addon/manager.cpp to
introduce artificial delays.)
One issue with this code, however, is that because modeless_dialog
doesn't execute its own event loop, the only way to get the dialog to be
updated is to force a draw event in ourselves via the new
gui2::dialogs::modeless_dialog::force_redraw() method. This is really a
side-effect of my design choice here to run the dialog in the middle of
a blocking operation instead of somewhere where events are being
processed normally. I'm not entirely sure if the draw events would be
pushed even in that case, however.
Closes#1101.
This makes the Xcode build's way of locating headers be similar to other compilers.
The header maps feature means you can include any header in the project just by the filename,
but none of the other supported build systems allow this, requiring a full path relative
to the src directory.
By disabling header maps, Xcode will give an error if you miss the file path
(unless including a file in the same directory).
This should allow it to run in different configurations:
- When clicking "run" in Xcode, it's adjacent to the Wesnoth applicaiton
- If you wanted a standalone install of wesnothd you'd now only need to copy over the Frameworks directory.
All of this assumes that wesnothd will run at all, which works with a debug build but probably not in the actual release.
The motivation for this is that Xcode is (for some reason) incapable of automatically reloading a scheme that has changed on disk, and overwrites it the moment you try to edit it with whatever it has in memory.
With this change, the information lost when it does that will be much less; in many cases, just a checkbox to toggle back on.
