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.
For non-Windows platforms this adds:
* a new check for whether the logs directory exists and is writable by attempting to write a single whitespace to a dummy.log file.
* a popup shown immediately after the GUI system is initialized letting the player know if there was an issue creating the log file.
For Windows, this changes:
* instead of writing to the OS temp directory and then attempting to move that file to the logs directory, this uses the same check that was described above for non-Windows platforms.
* the alert shown when writing the dummy log file fails is now a Wesnoth alert message rather than the Windows-specific MessageBox.
* a failure to create a log file does not immediately exit wesnoth anymore.
Additionally, this makes it so that for the default state (logging to file), all platforms follow the same code path by calling `lg::set_log_to_file()`. `log_windows` now contains only the Windows-specific logic needed for handling the creation/redirection of output to a console.
* 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.
