Instead of having the preferences dialog make a copy of all advanced preference config objects (and sorting them)
every time you invoke it, this adds a new advanced_manager class instantiated once in game_launcher (not sure if
that's the best place for it, though) that parses and handles the options. Allows me to greatly clean up the
preferences dialog code.
Now, during an active game, (that is: not during
campaign selection for example) the engine hides
all toplevel tags from addons that are not
involved in the current game. 'involved' here
means providing one of the [campaign], [scenario],
[era], [multiplayer], [modification] or [resource]
tags that are active in the current game.
Fixes#4832
This adds an additional `test_result` attribute to [endlevel], intended for use with the automated unit tests. This allows for the unit tests to differentiate a pass/fail result separately from scenario victory or defeat, which allows for more accurately determining the outcome of a test as well as addresses the potential, for example, for a scenario to be expect to pass because of the {SUCCEED} macro but instead passes because the scenario ended as a victory through some other method.
Additional unit tests which were the original motivation for this change are also added as part of this. They test, as much as possible, that events are executed at all, and are then also executed in the expected order.
This is part of working out whether a subset of the "fail" tests could be run
in one Wesnoth instance. To run a test that returns TEST_FAIL_BROKE_STRICT with
any other test would require a mechanism to reset lg::broke_strict()'s flag.
All tests that fail with an {ASSERT} will also set the lg::broke_strict() flag,
the tests with the new status are only those that would pass without the strict
flag.
In the SUF tests, change a test from fail-on-success to breaks-strict, rename
the formula tests and add some comments. The rename is because "fai" is
"Formula AI", an obsolete name for WFL.
This allows batching all of the tests that are expected to return status zero,
which is currently 161 tests, and running the batch with a single instance of
Wesnoth. It doesn't include the changes to the run_wml_tests script to use
this new feature.
Timing on my PC:
* 4 seconds to run a single test on a debug build
* 90 seconds to run the whole batch of 161 on a debug build
* 1.2 seconds to run a single test on a release build
* 31.2 seconds to run the whole batch of 161 on a release build
There has been functionality to manage custom servers in the player's
preferences file since as far back as commit
5fb0b2a91123474d147c9de4918fc11a1b4c15ac in June 2007, but there's never
been a user interface for it.
This commit removes the current server list dialog attached to the MP
Connect dialog and replaces it with the same functionality embedded into
the latter, as well as the ability to edit the server list in the
player's preferences file. There's some code movement in a few other
places since the previous function in the preferences namespace doesn't
suit the new code (it always returned a combined list of game and
player-defined servers).
There's some disabled code referencing a situation where the listbox
with the list of servers allows the code (and the player) to clear the
selection. It's disabled because there are some UX issues with it noted
in the code comments associated to it.
Fixes#4564.
When completing the tutorial, the preferences file's [completed_campaigns]
recorded that "" had been completed at difficulty NORMAL. This is an old
bug, unrelated to the other tutorial changes that I'm making, but would
cause problems if we want to change the UI based on whether the tutorial
has already been completed.
If a save directory from another version is found, a drop-down list of
directories is added below the filter box in the Load Game dialog.
Refactor save_index_class to allow instances for other directories.
Design idea: all new saves go in to the main save directory. Games can be
loaded from other directories, but those directories are treated as read-only.
When building an index for other directories, the index is kept in memory and
not written to disk - this results in some noticeable lag in the UI when
opening the other versions' directories, but not the usual save dir.
This was never fully implemented and has been essentially abandoned. If we want to
add this again, we should look to adding full game controller support (Steam controller,
for example), though I don't know how suited this game is for controller support. As for
as I can tell, the only working part was ever map scrolling.
Includes a sqrt -> std::sqrt conversion I forgot in this file awhile back.
This was needed to get the build working with vcpkg's version of SDL, where all the SDL files are
in their own SDL folder. However, our cmake config also has a note saying it was a deliberate choice
to move our SDL files *out* of their SDL2 folder due to certain distros (FreeBSD is mentioned) not
putting the files in said folder in the first place.
There are only 3 places where it's actually really needed. Used the game_config_manager
singleton to retrieve a reference in those cases.
(cherry-picked from commit 4eee386664b66e801bd4498e8730c017af03f0aa)
A few catch blocks modify something in their exceptions, so those are kept non-const.
(cherry-picked from commit 2bf4d68c87b69256266b7745a9e3453693794e35)
Besides replacing the "End of file" error when getting disconnected from
the server under unexpected circumstances (e.g. because the server died)
with a translatable and more intuitive message, this also makes it so
other network error messages ("Connection refused", "Host not found",
etcetera) are displayed in the UI in a slightly clearer fashion, and in
an error dialog that must be dismissed with a click on a button, instead
of a transient message that can be easily missed due to an accidental
misclick.
Closes#3005.
(cherry-picked from commit c503c2ce35bc7d70fddc71daff70e31389615cf0)
The above issue was caused by the fact that image::flush_cache() wasn't called after
reload_changed_game_config() when the addons manager was exited. Using F5 at the tilescreen
caused the image to appear since that callback *did* include image::flush_cache();
reload_changed_game_config() was called in 5 places, 2 of which were followed by flush_cache.
I figured it's safest to just include the latter in the former, since the other three usecases
(multiplayer installed addons before joining a game, a new core was selected, and the addons
manager was exited) all seem like places where flushing the image cache would be appropriate.
When a banned or connection-limited client attempts to log in, it hangs.
This is because the client does not understand that the server did not finish the handshake. This moves the check to a point just after the handshake has completed (when the server would normally ask for a version number). The client never checked for errors, so added a check.
* Added a point ctor that takes an SDL_Point.
* Added a toggle_fullscreen function to CVideo.
* Change all management of resolution data to use point instead of std::pair<int, int>. This
shortens the code considerably.
* Cleaned up preferences_dialog::set_resolution_list
* Made CVideo::set_resolution return a bool indicating whether resolution was changed.
* Swapped which of the two set_resolution overloads contains the main implementation.
* Moved the events::raise_resize_event() call when setting resolution to the CVideo function
where it should have always been (instead of the prefs dialog callback). This is a pretty
essential component and having it localized in one place meant any other area of the code
that might have called set_resolution wouldn't have it.
Early in the 1.13 development cycle there used to be an option to show the mp_connect screen
(now mp_staging) before starting an SP campaign. That was scrapped and the only code that used
it (in the SP initialization process) commented it out. Since we're not going to restore it,
might as well remove this flag.
Also removes the one instance remaining of a "show_configure" flag. Pretty sure this might have
also been a relic from the same time as show_connect, but it looks like it was since removed.
SP now has a dedicated screen for configuring active modifications in SP, which was the only
reason to show the configure dialog anyway (plus the mp create and configure screens were combined
later in 1.13 anyway).
* Dropped unused CVideo class member references.
* Replaced the lone usecase of the CVideo member in loadgame with the singleton and removed said member.
* Removed CVideo references from a bunch of addon management functions.
* Cleaned up a *lot* of now-unnecessary forward CVideo declarations.
Essentially, we had CVideo arguments being passed down this chain:
- game_launcher
- free-standing MP initialization functions
- campaign_controller
- playsingle_controller/playmp_controller
- play_controller
- game_display
- display
And likewise down through
- game_launcher
- editor_controller
- editor_display
- display
With only a minimal number of actual calls along the way. :| There were maybe... two remaining?
This removes the CVideo arguments and class members from both chains (except of course, game_launcher.
That's where the "real" CVideo object lives).
The display class now initializes its CVideo reference from the singleton, which is also used in the
very few other places it's needed. I also replaced a check for a null video ptr in show_tooltip()
with a faked() check (see src/tooltips.cpp). That seems to make more sense, since CVideo is never
null now.
I had left the former alone in the above commit since I thought it might be worth keeping for the
faked() call, but that's not really a great reason.
As for the latter, I didn't realize the CVideo argument wasn't really even needed. I didn't even
need to replace it with a get_singleton() call since the resolution list is updated by set_resolution_list
before it's used.
This also removes a bunch of unnecessary CVideo arguments from various savegame functions that
emerged as I cleaned up the unused parameters. savegame::save_game did take a CVideo pointer
that did look like it was intended to be a sort of do-show-dialog flag, but since that parameter
was never passed as null, I removed it.
This a two part commit. First:
----------------------------------------------------------------------------------------------------
Added and deployed two new helper macros for the standard implementations of the static execute
and display functions. I also made use of a variadic template in order greatly simplify code
maintenance. Now, even if the dialog's ctor parameters change, no one has to worry about updating
the associated execute/display functions (though of course, this only applies if the helper macros
are used). \o/
I did not deploy the macro in cases where there were multiple overloads or the functions did more
than just show their dialogs. I might add an additional __VA_ARGS_ parameter to the macros later.
Do note for the end_credits dialog I moved the default empty-string parameter from the display
function to the ctor.
Second:
----------------------------------------------------------------------------------------------------
Another change is that modal_dialog::show and modeless_dialog::show no longer take CVideo arguments.
Since the video argument couldn't be included in the parameter pack (maintaining the argument would
have meant making it the first one, which would be just as much work), and using CVideo::get_singleton
in the macros would require adding video.hpp includes in a whole bunch of files, I simply removed the
argument. I had been intending to do this for a while anyway.
This therefor also removes the CVideo argument from:
* All dialog display/execute functions.
* modal_dialog::show
* modal_dialog::build_window
* modeless_dialog::show
* modeless_dialog::build_window
* wml_exception::show
* gui2::show_message
* gui2::show_error_message
* gui2::show_transient_message
* gui2::show_transient_error_message
* gui2::show_wml_message
* gui2::build
* gui2:🪟:window
* gui2::dialogs::tip::show
* Various GUI2-related Lua functions. The video_dispatch helper was also removed.
* Any functions that took a CVideo argument for the sole purpose of passing it to one of the above.
Ya know, all these damn CVideo arguments didn't actually do anything, besides an occasional check to
CVideo::faked. At the end of the pipeline, they just got assigned to the video_ member of gui2::window.
Huge code bloat for nothing.
