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.
* 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.
There is a new global interface draw_manager which handles drawing,
and a new abstract base class top_level_drawable (TLD) to indicate
that an object is something that has a place on the screen and should
be drawn.
Basic usage is fairly straightforward. Top-level objects (such as
windows) inherit from top_level_drawable. They must implement the
functions layout(), screen_location(), and expose().
layout() should ensure that screen location and animations are current.
screen_location() should return the current draw location on screen.
expose() should do the actual drawing.
The draw manager keeps track of what regions of the screen, if any,
need to be redrawn. Regions must be invalidated by calling
invalidate_region(rect). This can be done at any time other than during
expose(). It must not be called during expose().
The draw manager has one main callable function, sparkle(). This may
be renamed at some point. It manages calling the TLD functions on all
TLDs in the correct order. It also manages loop delay and vsync.
The standard game loop now becomes:
1. events::pump()
2. draw_manager::sparkle()
Contains primitive drawing functions, such as fill, points, line, etc,
and also texture drawing functions blit, flipped, tiled.
This removes specialty drawing code from several places, most notably
CVideo and gui/core/canvas.
Functions to draw to the screen should now go in draw.cpp.
There is a new sdl::get_mouse_state() function that should be used in place
of SDL_GetMouseState() in every case. It returns coordinates relative to
the drawing surface.
With this, the pixel scale option seems to be working without issue.
Due to an upstream change in vcpkg that breaks the simple integration previously available with `vcpkg integrate install`, building using that setup method is no longer possible. In order to work correctly, cmake must instead be used to generate the VS project files, since that is able to integrate with vcpkg, since vcpkg also uses cmake to build all the library dependencies.
An additional benefit of this is that it will no longer be necessary to separately update the VS project files since it will read the same source_lists files as cmake (on linux) and scons do.
This also enables running the WML unit tests on Windows with this in order to confirm that a valid wesnoth.exe is in fact being generated as well as fixes building the boost unit tests.
The warning level for both release and debug builds are now at level three, the remaining warnings have been fixed, and therefore strict builds have been enabled - any warning will now cause the build to fail, just like for the linux jobs.
Known issues:
* The boost unit tests don't actually run successfully - they fail on CI at least with an exit code on 201 - however I don't know if this is a real problem or just a problem with running headless on CI.
* The debug build doesn't quite work since the executables are built against the non-debug dlls but cmake copies over the debug dlls into the output directory. For now this can be worked around by copying the release dlls into the debug directory.
* The instructions in INSTALL.md are not very good since I don't use Windows and thus can't write anything more detailed. Ideally someone who uses Windows can add more detailed step by step instructions at some point.
Fixes#5741
This removes the build-time dependencies on SDL_ttf and FriBidi,
alongside the SDL_ttf wrappers, the SDL_ttf text surface class, the
SDL_ttf render cache, and the SDL_ttf (de)initialization code.
This adds a minimal wrapper around pango_text intended for use in GUI1,
in particular for the help browser. Functionality is very incomplete
right now but for the time being we can render text, determine line
dimensions, and ellipsize text, which is almost the bare minimum needed
for porting the Help system (it's still missing a word wrapping
implementation).
The change to static_cast for the definition of LUAL_BUFFERSIZE replaces the fix previously used (d0100758f855ec0d8f30dff41e8a8b6ff2d45fda) for Lua 5.3. 5.4 removes the static alternative for LUAL_BUFFERSIZE. A better solution would probably be to disable the old-style-cast warning for luaconf.h, but I can't figure out how to do that so using static_cast is the easiest solution. Do note that change will have to be applied each Lua update like the aforementioned commit.
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.
This allows using full markup for the license text and making it
independently scrollable without messing up the dialog. It also enables
URL parsing in it.
This commit adds tools to test parsing of WML macros by the preprocessor
and parser. The commit also adds two tests of the #define and #undef
WML macro as examples.
The tests consist of three steps:
1. Define one WML string containing macros and one WML string
that lacks macros in each test. The two WML strings should be
equivalent after preprocessing.
2. Transform each WML string into a syntax tree (represented by config
objects) with the preprocessor and parser of Wesnoth.
3. Check if the two config objects are equal. Since the two WML strings
are equivalent, the two configs object should be equivalent if the
preprocessor and parsers are both correct.
The output of the preprocessor is in an undocumented format. Therefore,
this commit does not test the preprocessor as an isolated unit.
This also adds a few utility switches which people are probably already
familiarized with from the game proper. Most notably this means I don't
need to alter and recompile campaignd any time I want different logging
settings.
There's some functionality commented out in this commit while I figure
out how to wire it into the campaignd server class.
This includes all the Win32-specific code dealing with the retrieval of
the UTF-16 version of the command line and subsequent parsing into an
array of UTF-8 strings.
The latter code is unchanged except for the function names and one local
variable originally named `is_excaped` instead of `is_escaped`.
(Note to self: ask gfgtdf if he was aware of the existence of
CommandLineToArgvW() back when he wrote the Win32 command line retrieval
logic.)
Instead of creating lots of image::locators and calling a family of
similarly-named preferences functions, this refactor encapsulates that logic
and uses an enum.
The new orb_status files still need adding to the MacOS build.
An assert has been added to `unit_drawer`'s constructor. There are two callers
- the `display` class guards it with an explicit check before constructing
unit_drawer. The `game_display` class doesn't have an explicit check, but it's
clear that other code in that class assumes the teams are already valid (and
would crash if they weren't).
In source_lists/wesnoth, put the new files in alphabetical order.
This (as expected) fails to build on MacOS, just like the previous build.
It also fails to build with Clang on Linux, just like the previous build. That's
caused by src/scripting/push_check.hpp:89's unused parameter 'L', and is
also just like the previous build.
lua now has a widget userdata that can be used
to set/get widgets properties as one would
expect, a lot of the set/get_dialog_xy function
were converted into modifiable properties of
the widget userdata. This in particular allows
us to get rid of the strange 'path to widget'
type of arguments of gui2 functions.
It currently generates lot of compiler wanrings,
I will fix this in a later commit.
One of the main advantage is that it makes it
much easier to add new api, previously a lot
of functions where overused, probably because
that was just easier than creatign a new
function. For example set_dialog_value returned
multiple value of listbox objects. (the
compatibility path doesn't support this
particular feature yet but i don't think it is
important, it probably wasn't even used at all,
since it also wasn't documented).
This also adds some new features, like an 'add_item'
function to add an item to a listbox, a 'type'
property of widgets to query the type of a
widget and a 'item_count' property to count the
number of children in an item.
Im still not 100% sure about the
property /function names, in particular:
1) i might rename 'items' to 'elements' or
'children' in some functions. Not sure yet
2) I might rename the 'value' property to
'value_compat' to make clear that its only
supposed to be used by the
backwards_compat.lua code.
A next step in improving this api might be
to introduce a (reusable!) 'window' userdata
so that the implementaion of wesnoth.show_dialog
would become:
```
function wesnoth.show_dialog(wml, preshow, postshow)
local dialog = gui.create_dialog(wml)
preshow(dialog)
local res = dialog:show()
postshow(dialog)
return res
end
```
However this is currently not really possble
since the pure existance of a gui2::window
object blocks the gui1 code (the main game view)
from receiving events. So we clearly cannot luas
gc take ownership of gui2::window objects.
Reasoning being:
* The result_set and other APIs are nicer to use.
* We use mariadb on our server rather than mysql, so this would minimize the chance of any incompatibilities.
* The mysql C++ connector 1.1 isn't compatible with with c++17 (https://stackoverflow.com/q/47284705).
Rather than having everything in the MOTD, this adds a separate button that will popup a window which will have most of this information in two tabs:
* General server information, such as a link to the CoC.
* Announcements, such as tournaments and new versions being released.
The information on this new window will be stored in the new `server_config` database table.
The MOTD will then just be a short greeting instead of the several lines that are shown currently.
Additionally, now the motd will only be displayed in the lobby chat the first time the user logs on.
the game_config_view object offers const
access to the game_config object, furthermore
it allows the game_config config object to be
replaced by a vector of config objects which
is what we will do later.
We're going to be using NN scaling for the map, and that's already handled automatically
by SDL (and in the future, OGL). We don't need these settings for surface SCALED_TO_ZOOM
and SCALED_TO_HEX scaling. In any case, if we want to scale a surface to zoom or hex, it
will almost certainly be for map rendering (such scaling methods don't make sense in the
UI, for example), so just defaulting to NN is simplest.
This change drops the option to use Linear or xBRZ scaling for map zooming. This was already
the practical case due to me converting map rendering to use textures. NN was used for all
zoom levels, and it's fast and looks good.
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.
