The current preferences handling is a mess:
* it's essentially a global config object that anything can modify in any way the caller wants, which is managed across multiple source files which have their own oddities and interdependencies.
* the general preferences has its own bit of SDL event handling and while I get the idea behind `events::sdl_handler` there's no reason to have SDL events handled in the preferences instead of just calling the relevant preferences setter for each event when it happens.
* the general preferences is where most of the preferences are handled and has its `base_manager` struct, which is part of the `manager` struct in the game preferences, which is then implicitly initialized as part of game_launcher's constructor.
* the editor preferences are the only preferences in a sub-namespace `preferences::editor` while all other preferences are just in the `preferences` namespace.
* the display, editor, and lobby preferences are all dependent on including the game preferences, the credentials are dependent on including the general preferences (but not the game preferences), the game preferences are dependent on including the general preferences, and the advanced preferences are entirely their own thing which is dependent on none of the other preference functionality and manages its own singleton.
* nothing checks whether the preferences file has actually been loaded before allowing values to be read from or written to the preferences config - if you attempt to get a value too early in wesnoth's initialization it will silently just give you whatever the default value for that preference happens to be.
With this there is instead a single access point (with exceptions handled via friend functions/classes), all predefined preferences are accessed via their own setter/getter, and all mainline preferences are defined in a single file (preference_list.hpp) so it's easily findable what preferences exist and where they're used. Having the list of all mainline preferences listed out also allows the lua preferences API to provide that full list rather than just the list of the preferences that have been set so far. Also it now checks for whether the location of the preferences file is known before attempting to load the preferences file and asserts if someone attempts to use the preferences too early.
A rich text label widget that can show text marked up with help markup.
Also includes the GUI Test Window, accessible in the title screen after launching wesnoth using --clock option. It can be used as dialog template/example or as a place to test GUI2 code.
* Redesigned the version dialog to serve as a general purpose About dialog.
* Credits button removed from title screen
* Moved community dialog contents to about dialog as new tab
Co-Authored-By: Pentarctagon
* Bugfixes to the tab_container widget
* Success indication mechanism on copy buttons
Instead set the Apple preferences folder from within the code rather than using -DPREFERENCES_DIR.
Remove -DHAS_RELATIVE_LOCALEDIR since that doesn't appear to actually do anything since its only usage is in filesystem_common.cpp, not filesystem.cpp.
Add-ons: checks for any that exist in the chosen other version but not in the current version.
Preferences: adds attributes that don't exist from the chosen other version's preferences that aren't in the current version's preferences. for attributes that exist in both, use the attributes from the file that was modified most recently.
Credentials: move if the credentials file doesn't exist.
Fixes#7936
This is necessary with Xcode 15.3 to avoid about 750 warnings across
all of the codebase regarding "Implicit conversion loses integer
precision", most of which apply in cases where theoretical limits are
involved because of conversions from unsigned 64-bit integers (usually
size_t) to signed 32-bit (int).
Ideally we want to address these warnings, but given how many of them
there are all over the place this is not something that can reasonably
be done in such short notice before Wesnoth 1.18.0 is released, and in
the meantime they make the compiler output with Xcode unnecessarily
noisy and completely bury any relevant warnings from actual code
changes. In the meantime, this is best for productivity until we can
get to a place where we can fix all of them and force using
-Wshorten-64-to-32 for all platforms in CI.
Adds a test with a schema example containing a super cycle and a .cfg file containing an unknown key to this schema. Previously, this would cause an infinite loop or crash. Now an exception for invalid key should be thrown.
Add test for the already existing validation where a tag shouldn't set itself as its own super.
Add test for the new cycle detection when validating a schema.
The super tag dependency forms a directed graph. Boost Graph's depth first search implementation was used with a back edge detector to find the cycles.
This is a preparation for enumerating all keys that a tag can use, including the keys from the super tags. If cycles aren't handled, it is impossible to validate mandatory keys without entering an infinite loop.
selected schedule will write to utils/schedule.cfg on scenario save
HOTKEY_EDITOR_CUSTOM_TODS is disabled unless user loads scenario
custom_tod:Preview button and associated callback added.
editor:translatable attributes now written with leading underscore
editor:support for multiple custom time schedules
Adds support for using these in the weapons and ability filters:
* "-1", which was previously treated as an parse error (no number before the separator).
* "-3--1"
* "-infinity" as the lower number in the range, provided a different upper number is given.
This treats "-infinity" (with no other number), "-infinity--infinity",
"infinity" (with no other number) and "infinity-infinity" as errors. It seems
unlikely that someone would intend to use a filter that can't match any
reasonable number.
The range "-infinity-infinity" will be parsed successfully. I don't see a use
case for that, but nor do I see a reason to add extra C++ to reject it.
However, it's not added to the schema, as I think it's good for the schema to
give a warning when someone creates a filter which will accept every value
(including accepting the default, so "-infinity-infinity" accepts the unset
value too).
Includes new unit tests for the C++ and the Lua stringx.parse_range functions.
The next commit adds more WML tests, but is kept separate to credit the author.
This started as a change to move common filter functions from unit.cpp to
somewhere that they could be reused for other config-based filters. In the
process a missing feature was found and added, the move is still included in a
single Git commit because the move was required in order to make these
functions accessible to the Boost unit tests.
Two CodeBlocks project files additionally get src/utils/any.hpp added,
which was in one of them but missing from the other two. I noticed because
these are alphabetically at the start of the src/utils file list.
Thanks to @CelticMinstrel for the review comments and Xcode project updates.
The key word of course being "start". This PR changes the editor by default to work at the add-on level instead of in its own separate scenarios and maps directories. The goal is to make the editor more useful generally, but also specifically to make it much easier for players to distribute content they create using the editor:
* When they click the Editor button on the main menu, they will first be prompted to choose an add-on (or mainline), or to create a new add-on.
* When saved, if the scenario cfg is in the format previously generated by the editor, it will be converted to the new format and to use the [multiplayer] tag, the map_file attribute, and have the map data saved to a separate .map file.
* Relatedly, the editor now knows how to handle scenarios with the map_file attribute at all (which yes, does mean that currently wesnoth's editor doesn't know how to load its own mainline scenarios from their cfg).
* When opening the file chooser dialog, it now defaults to their selected add-on's directory.
If they choose to create a new add-on, then the editor creates for them:
* a basic but functional _main.cfg.
* an empty achievements.cfg (at this point mostly just so they might see it at some point and realize achievements exist, but ideally an achievements editor dialog could be created eventually).
* an empty _server.pbl file.
* a proper add-on directory structure containing the standard set of folders (maps/, scenarios/, units/, utils/, images/, etc).
Additionally, as an initial proof of concept for actually using this new add-on level functionality, a new Add-ons dropdown has been added to the editor's top bar, with a pbl editor option. This allows populating the blank _server.pbl file as well as editing an existing _server.pbl. There is also an option to change the add-on's ID, which will update the add-on's folder name and _main.cfg.
Misc other changes:
* The ability to add a recruit list to a side has been added back as a text box on the edit side dialog. While admittedly this doesn't allow players to select units from within the editor itself, it does set the actual side's recruit list (rather than a specific unit's extra_recruits), will show the user what the current recruit list for the side is (which the previously removed implementation didn't show anywhere), and correctly sets the faction as Custom so that the recruit list is used.
* When saving an old-style editor scenario, everything that can be triggered via [event] is either moved to a start event with a specific id attribute. Exceptions to this are [time], [side], and [side][village]. This is done so that the editor can know (for the most part) what things are actually its own to safely replace. As such, aside from the three previously mentioned tags plus the start event, any other WML added to a scenario by a UMC author is preserved rather than being overwritten - the editor no longer replaces the entire contents of the scenario file.
* The editor no longer writes out cfg files missing the top level scenario tag. If it doesn't find one or this is the first save of a new scenario it defaults to [multiplayer], but otherwise it will properly handle finding [test] or [scenario] as well.
* Requires that map files have the .map extension and scenario files have the .cfg extension. Also it assumes that .map files do actually only have map data in them and the .cfg files do actually have valid WML in them. I understand that this is not a limitation it had previously, but I don't think this is an unreasonable thing to require.
* Addresses part of #7667 by just not using regex for figuring out the map_data attribute value.
Additionally, it is not possible to change the currently selected add-on without going back to the main menu, clicking the editor button, and choosing a different add-on. This is intentional - I don't want to deal with having multiple add-ons open at the same time. If someone feels really strongly otherwise, then they can implement that themselves later.
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.
