Things in the scenario didn't quite make logical sense considering the presence of Gryphon Riders. This resolves the issue by allowing them to trigger an event, and by acknowledging them in the endlevel dialog. Additionally, one translator hint is added for the "Smash" text when the rune is smashed.
The problem with this warning was that it didn't include any clue about what
had triggered it - just that there's a broken event somewhere, and it could be
in a scenario, macro, unit_type or even from another add-on if you're using a
non-default era.
When run with `--log-debug=wml`, this makes Wesnoth print out whatever the
contents of the affected [event] tag are.
(cherry picked from commit d6b56969a012853fbfc55844b1eac98a70c0346b)
Slightly different to PR #6582, which was the 1.16 version of this. The five
lines that were labelled `preserving known bug` are changed to test that it's
been fixed.
Here `apply_to=opponent` means that the weapon special gives the opponent the
ability, the unit that should get poisoned or slowed is the unit that has the
weapon special.
There's a known bug in 1.16, that `apply_to=opponent` check the wrong unit to
see it it's `unpoisonable`, `undrainable` etc. It also checks the wrong unit to
see if it's already poisoned or slowed, so a battle between two units that both
have reverse-poison results in at most one being poisoned.
Most of the credit for this is Newfrenchy's, as he's already written a fix
and a WML based test. This commit uses a Lua test instead to test more
combinations of statuses.
This adds a `COMMON_KEEP_A_B_UNIT_TEST` macro, which is a counterpart to the
`GENERIC_UNIT_TEST` macro that starts the leaders next to each other, ready
to attack. The `A_B` is because I'm planning a multiple-side variant too.
There's no test for [petrify], as simulate_combat doesn't provide a stat for it.
This tests only 3 of the 6 abilities whose behavior changed in 650f70405ff.
My thoughts on testing the others are:
* [firststrike]'s test is in 650f70405ff.
* [drains], [poison] and [slow] are tested here.
* [petrify] ends combat, it's also not exposed in simulate_combat's stats.
* [plague] triggers after combat ends.
It will try to match the default resolution (1280x720). It will also try
to ensure that the scaled resolution is less than 1920x1080. This will
result scaling as soon as the 1920x1080 resoluton is exceeded, requiring
a minimum supported resolution of 960x540 or less, however in practice this
is not a huge problem even with the existing 800x600 theme.
In any case the pixel scale can of course be overridden in preferences.
This will never reduce the drawing resolution beyond the minimum window
size specified in preferences/general.cpp.
The minimum window height has been reduced from 600px to 540px!
This is to that a 1920x1080 display can use a pixel scale of 2.
It could be changed back, but a better solutuion would be updating the
default theme to accomodate this form factor.
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.
Rendering is now done to a separate surface. All routines that previously
wrote directly to the framebuffer now write to this surface. When the screen
is flipped, this surface is copied directly to a streaming texture, which is
then scaled to the window's rendering surface for display.
This has enabled a drawing resolution that differs from display resolution.
It is active and for the most part works. Input events are converted to the
correct scale by SDL, so most input handling routines can be used unchanged,
but one or two are causing problems so there are some bugs. To test this,
change the "pixel_scale" preference. Don't expect a playable game with
any pixel scale other than 1 yet.
Turn the 4 side setup of the firststrike_and_laststrike test into a macro
called `COMMON_KEEP_A_B_C_D`for reuse in other tests.
The comment for `GENERIC_UNIT_TEST` gets a couple of extra paragraphs.
All the files get wmlindent run on them, which reindents `FAIL_IF_NOT`.
The main reason for having these is separate files is Git's fuzzy-patch
matching when merging and rebasing. Having large blocks of identical text
in `wml_unit_test_macros.cfg` can mean the wrong section gets patched.
This reverts commit 9caf43ed732f621d6d752ff5dede54466d5d4b4c. I was mistaken, this is actually meant
to check if mouse_focus_ is a styled_widget or not, and if it's not, fire events unconditionally.
This has been here since 2009 when this block of code was added (0d72daac2e1157f0d069ff07eb359a9581272cdc).
It's not clear mouse_focus_ would ever be null here, but if it ever was, this would have tried to deference
it and crash. To be safe, I've wrapped both fire() calls in a not-null check.
* GUI2/Distributor: further cleanup started in 988bf973e96efaed9eec268c8d1ba5f4ed3bed37
This restores the template to mouse_button, but it keeps the struct-based approach for specifying ui_events.
This returns a label handle which allows you to remove, reposition, or replace the label later.
In addition to all the features of wesnoth.print, you can now specify where the label appears onscreen, as well as a fadeout time separate from the duration.
You can also anchor the text to an edge or corner instead of centering in on the screen,
specify the maximum width it can occupy as an absolute width or a percentage,
and specify a background colour and transparency.
It includes a demo scenario that demonstrates many of the capabilities of the API.
To play the demo scenario, run with -toverlay_text_demo or select it from the in-game test list.
Sadly, this takes the campaign up to 100 string changes between 1.16.2 and
1.16.3. The only one of these that was already going to change for 1.16.3 is
S04t's volcanic forge one.
(cherry picked from commit a1e60f061dd85237215966e5733a8da8f7ec126b)
