* Fixes#4223, by making the --validate and --validate-* options imply --nocache.
* Fixes#4224, showing an error if you misspell the id argument to
--validate-addon. The application doesn't (but should) quit automatically to
avoid the user spending time on a non-functional validation run, however it
does at least disable all add-ons, which should have the same end result.
* Shows a warning that --validate-addon needs the user to play the add-on, it
doesn't automatically check the add-on. This was my misunderstanding when
logging issue #4225, which has now been repurposed into a feature request for
a new tool that does what I thought --validate-addon did.
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
Currently this is disabled by default
Use --validate command-line argument to enable
The following new features were added in the schema format:
* Union, intersection, and list types
* Keys can specify a union of known types on-the-fly
* Key and tag names can include wildcards (* and ?, glob-style)
* Tags support any_key=yes, which means unrecognized subtags will be ignored
* Tags and keys support deprecated=yes (unimplemented)
* Specify max=infinite instead of max=-1
@gfgtdf explained in IRC that it's often used to slow Wesnoth down (instead
of speeding it up, as I had assumed).
This should also allow unit tests to compile again.
The FPS cap, originally implemented in 2007, is very poorly done. It
doesn't take frame time variance into account, and is therefore almost
guaranteed to cause missed frames all the time. It doesn't increase timer
granularity on Windows, which causes SDL_Delay() to often take much longer
than intended. And it's hardcoded for 50 FPS, which fits poorly with 60 Hz
displays.
This new implementation fixes all those issues.
My experience is that the game feels much, much smoother with the new
implementation, perfectly competitive with 1.12. In my opinion, performance
is now at an acceptable level for a stable release.
This is intended to be used instead of the Game Version dialog's
clipboard text report in the event that Wesnoth cannot reach the
titlescreen or the dialog for some reason.
Unlike the --version info dump, it performs various calls to the
filesystem API which have potential side-effects on the environment
(namely, creating a user data directory structure if none existed before
running the command). It seems highly improper for a program's --version
switch to perform any actions other than printing text to its parent
terminal, hence I thought it would be better to add a new switch with a
more active phrasing, also reflected in its accompanying documentation.
Ultimately, this and its UI counterpart should be used by 1.14 players
as part of the bug reporting process, preferably as a mandatory step
before submitting new reports on GH or the forums.
Turns out I mistook @celticminstrel's opinion that we should use include guards over pragma (737916e).
Since all major compilers support `#pragma once`, there's no reason not to use it.
For future mergability reasons, this excludes src/spirit_po and src/xBRZ. It also excludes src/boost-patched.
If a lua script is passed as an argument to wesnoth, wesnoth will
actually instantiate the application_lua_kernel defined in the
previous commits, initialize it, and run the script in that
environment.
we now use boost::istreams instead of boost::filesystem::fstream because the later doesnt work with mingw.
we now use a custom codecvt instead of boost locale because we want to get better error messages for invalid utf8 strings using our _ERR streams
we now use unicode prgamm commandline args on windows..
Reuse the boost::program_options::error class (which we already catch in
main()) instead of throwing a std::string, and simplify the throwing
logic accordingly.
There is no need to provide incredibly verbose error messages since the
user is expected to be able to read --help or the man page to get here
in the first place.
Reuse the boost::program_options::error class (which we already catch in
main()) instead of throwing a std::string, and simplify the throwing
logic accordingly.
There is no need to provide incredibly verbose error messages since the
user is expected to be able to read --help or the man page to get here
in the first place.
When the game is run using e.g. "--log-strict=warning", then
writing anything to a log channel of severity warning or higher
will result in a game::game_error exception being thrown.
This will only happen the first time that such a write is
attempted, subsequent attempts to get the logging object will
pass without exception and such messages will be reported.
after unit tests play, then unless --noreplaycheck flag is used,
they save a replay at the end of the scenario (using autosave
code path), without compression. then they try to load it and
play it to completion.
this is the initial attempt.
