The only reason game_preferences_display.cpp receives special
considerations is that it depends on a preprocessor symbol that we don't
want to trigger a full rebuild every time the relevant scons option is
changed. hotkey_preferences_display.cpp does not use that symbol
(WESNOTH_PREFIX).
The macro-less portions of these terrain graphics rules are now the
TRASH_A and LITTER_BASE macros. I tried to the best of my ability to
understand how they are supposed to work together, so this is the naming
scheme and parameter set I found to be the most optimal:
#define TRASH_A TERRAIN PROB IMAGESTEM
Covers the first and second rules, which are used on a single
terrain pattern.
#define LITTER_BASE TERRAIN IMAGESTEM
Covers the third rule, which affects both trash terrains.
Since the GUI2 titlescreen took over, the path to tips.cfg is not
hard-coded in the engine anymore; in fact, this commit also updates that
path, which is in data/gui/default.cfg.
> Unexpected characters after variable name (expected , or =) at ~add-ons/Standalone_Addon_4.cfg:1
Becomes:
> Unexpected characters after variable name (expected , or =)
> at ~add-ons/Standalone_Addon_4.cfg:1
This is mostly intended for consistency with the new preprocessor error
location format.
Additionally, the tokenizer status information displayed when DEBUG is
defined at compile-time has changed slightly:
> $error, value '$value', previous '$previous_value' at $pos
Becomes:
> $error
> at $pos (value '$value', previous '$previous_value')
Messages such as:
> Quoted string not terminated at ~add-ons/Foo/bar.cfg
> Macro/file 'FOOBAR' is missing at ~add-ons/Baz/bat.cfg:12 included from ~add-ons/Baz/bag.cfg:2 included from ~add-ons/Baz/ban.cfg:42
Now are formatted as:
> Quoted string not terminated
> at ~add-ons/Foo/bar.cfg
> Macro/file 'FOOBAR' is missing
> at ~add-ons/Baz/bat.cfg:12
> included from ~add-ons/Baz/bag.cfg:2
> included from ~add-ons/Baz/ban.cfg:42
For messages that include the {} substitution trail, this improves
readability by making the trail a sequence of lines with file locations
rather than a massive opaque and unreadable text wall:
> Macro/file 'FOOBAR' is missing at ~add-ons/After_the_Storm//macros/scenario-segment-implementation.cfg:61 included from ~add-ons/After_the_Storm/base-loader.cfg:6 included from ~add-ons/After_the_Storm/_main.cfg:174 included from ~add-ons/After_the_Storm/base-loader.cfg:75 included from [...]
In fact, it's that particular case that motivated this report format
change. Cases where there is no substitution trail but there is still a
file location pointer are covered by this commit too mainly for the sake
of consistency and readability -- being able to see the last (first)
relevant location pointer first on a separate line should make it easier
to debug most WML issues.
* Add a list of files (missing from a previous commit) if available.
* Include the post-summary field if available.
* Indent the detailed report at the end.
It doesn't have any more options because U+0020 SPACE is the standard
character used for WML indentation, and the intended use case requires
fixed-width indentation anyway.
Fixes the copy button in gui2::twml_error not doing anything on X11 when
used on an instance of the dialog created during the very first
loadscreen sequence before the titlescreen (e.g., when there are errors
in game data files or in unconditionally-included code from _main.cfg
files in add-ons).
Originally (2004ish), the SDL_EventState(SDL_SYSWMEVENT, SDL_ENABLE)
request was done immediately after initializing SDL video. After years
and years of added functionality, it got pushed down to right before
displaying the titlescreen, resulting in most of the loadscreen steps
being executed first.
As a result, attempting to use copy_to_clipboard() on X11 before the
titlescreen appears would result in unusual behavior from the desktop
environment (KDE here) and not really work, because while the original
copy_to_clipboard() call is done and sets the X11 clipboard owner
correctly, there is no SDL_SYSWMEVENT event to receive and handle in
events::pump() through which the actual communication with members of
the X11 neighborhood would happen (the handle_system_event() function in
src/clipboard.cpp); in other words, no clipboard contents could be sent
from Wesnoth when requested by X11 applications.
Of course, this is an X11-specific bug that didn't really affect any
other platforms. The only reason we request SDL_SYSWMEVENT delivery on
Win32 seems to be the notification popups support code introduced in
commit 2fc758377a566ce6a3d6cdd7d30ca5076e8395c0.
The obvious solution is to revert to the original state of the request
in commit 6103d56dae44df74cc816af07355bc5528a9f2f5, where it was last
intentionally changed barring the aforementioned Win32-specific change
above. It was then set to be done right after initializing the
cursor::manager, right after initializing video, so that's what we
should probably do now.
The previous format had explicit line breaks after each error put into
the stringstream, which resulted in having to change every error
insertion site to change the overall report format. Now we don't insert
explicit line breaks, and instead join the vector at the very end with
two line breaks between each item for a cleaner presentation.
This also gets rid of a single trailing line break that was appearing at
the end of the report in all cases.
This way the format for the big unified report can be changed for the
GUI without affecting the stderr version, especially with regards to
where we place line breaks and such.
Note:
The hotkey/hotkey_command.hpp include is necessary to avoid build-time
errors. It was previously included through gui/dialogs/message.hpp <-
gui/widgets/control.hpp <- gui/widgets/widget.hpp <-
gui/auxiliary/event/dispatcher.hpp <- hotkey/hotkey_command.hpp.
Paths like "/home/shadowm/.wesnoth-1.11/data/add-ons/After_the_Storm/_main.cfg"
aren't very appealing to read at the start of the error message,
considering that the WML-canonical form of the path (~add-ons/.../_main.cfg)
is provided in the detailed error report later on in the same dialog.
So, in order to make the report tidier, print only the synthetic name of
the add-on guessed from the file path ("Foo Bar" for
.../data/add-ons/Foo_Bar/_main.cfg and .../data/add-ons/Foo_Bar.cfg).
This allows us to be more self-contained and require less logic in the
instantiation site for preparing the report for display.
This requires adding a new row and label for displaying the list of
faulty files, which will be hidden when the list is empty or not
provided in the display() static member function.
Information about the current state of the tokenizer isn't really useful
to pretty much everyone dealing with WML parser errors, so keep that
unnecessary and confusing verbosity restricted to builds with the DEBUG
symbol (?) defined.
("Pretty much everyone" == users)
Partially reverts commit d6d1e7df2e485e0ee2469548a4fd05ce20b69ac4, which
introduced the extra state information.
This dialog features separate summary and detail sections along with a
small heading for the latter in bold face. More features may be added
later as part of my work on improving WML diagnostics, but for now we
have the bare minimum for better message formatting with a content
structure more or less identical to the current one.
Hide the URL/path browse buttons if we don't support the current target
platform, they are wasting space otherwise since they only trigger a
stderr error in that case.
config::error is thrown by the parser to signal a parser error, so we
want to catch that so it doesn't go up the stack and cause the game to
display an obscure error message referring to an "<unknown>" WML file or
even crash to desktop.
The scenario author now has the option to use either the default AI
[avoid] tag or a specialized [avoid] tag inside the [micro_ai] tag. If
neither is given, the default remains all castle terrain.
[true] and [false] describe a condition that yields true or false,
respectively. They are intended as syntactic sugar in situations where
one absolutely needs to have a conditional statement for whatever
reason.
