This fixes two specific causes of #3059, where code assumes that all parts of
the add-ons manager's UI are accessible, an assumption that fails when the
dialog uses a stacked widget to handle small window sizes.
It would be better to redesign the C++ for this dialog, but a quick workaround
for the observed issues is much easier.
* Fixes#5810, triggered by using the version drop-down in small-screen mode.
* Adds a workaround for keyboard input changing the selected add-on on small screens.
The existing PblWML specification includes a comma-separated list of tags.
Until now there are no official tag names, but some of the 1.14 add-ons already
have some unofficial ones. If this feature is included in 1.16 then I assume
many UMC authors will use the newly-official tags.
For a larger add-on list than the dev server has, use port 15014 which will
connect to the 1.14 server instead (in the connect dialog change the address to
addons.wesnoth.org:15014).
Show the contents of PblWML's "tags" attribute in the add-ons dialog. They're
shown at the bottom of the right-hand panel (only if the window size is large
enough to trigger that dialog's two-panel layout).
When processing [effect]apply_to=movement, if apply_to_vision is 'yes'
(which is the default) then the vision points will change by the same amount.
Previously, it sometimes affected vision and sometimes didn't; for most cases
where it makes a difference, I expect it to be a change from unanticipated
behavior to expected behavior.
Please refer to the new unit test added in this commit for more detailed docs;
that test is also a rough draft for the Wiki update needed when this merges.
The reason it sometimes affected vision was that the special value of -1 vision
points was interpreted as "use the value of the max movement points instead".
The special value of -1 is still supported and frequently used, and refactor that
is out of scope for this commit - it's easy to check when the code path changed
in this commit is used, however it's considerably more complex to find all
routes that create a unit with vision set to -1.
I'm expecting one add-on, Rebirth In Nature, to need a large update for this;
as well as a trivial change needed to the Add Creature Pack.
There are several mods that have their own handling for vision, recalculate the
values frequently, and are expected to continue working as before, as they'll
just overwrite any changes that the engine makes.
* Proper Flying Mod / Proper Vision Mod
* LotI
* Blessed Altar Mod
* Shards Era's `CALCULATE_WEAPONS_ONLY` macro
* Castle of Evil Spirit
Rebirth In Nature is an RPG-style campaign that expects the player's unit to
have vision separated from movement along with right-click menus that change
the character's movement, this will probably need `apply_to_vision=no` in
many places. OTOH, its `item_id=mobility` uses `apply_to=movement` followed by
`apply_to=vision` to implement in 1.14 what this change will make default
behavior in 1.16.
There are a few sharpshooter units which have vision better than their
movement. If given a buff which boosts their movement, this will give
them a buff to vision too; likely a change towards expected behavior.
* Archaic Era's Royal Ranger
* Ageless Era's Royal Ranger and Dwarvish Forest Sniper
* Eastern Europe at War's Yacht and Great Yacht
* Era of More Units's Lone Wolf
* Southernerns has several sharpshooters
* WWII Era has several sharpshooters
* War of Dominions has some guard towers with very low movement
Silver Age has abilities that modify vision based on time-of-day, but unlike
the Proper Flying Mod and LotI these are done by adding and removing objects
that add or subtract one vision point, these should be unaffected by this
change. Unrelated to that, it declares values for `[unit_type]vision=` even
when the value is the same as max moves - like the sharpshooters this means
that buffs to their movement wouldn't have buffed their vision but now do.
There are few units with vision less than movement. Generally these seem to be
missile weapons that are represented as units, and they probably won't meet any
apply_to=movement statements - even if a movement power-up is available, the
player would probably choose a different unit.
The Add Creature Pack has two creatures (the Cactose Elder and Carnivore Fatal
Plant) that have reduced vision, along with AMLAs that increase those units'
movement; these AMLAs will need to use `apply_to_vision=no`. These two
creatures are used in Castle of Evil Spirit, but they won't get enough
experience to get an AMLA there.
Fixes#3356.
The line-by-line workaround for rendering huge areas of text is dropped, as we
now only expect to be rendering screen-sized or smaller parts of the text.
Rendering huge texts (greater than 64kpixels high) now requires the caller of
pango_text::render() to change to calling pango_text::render(SDL_Rect) instead.
This is used by text_shape, fixing the crash when opening the credits screen.
This should reduce memory usage when rendering text. It doesn't seem to reduce
the amount of work done by Pango, but the drawing will be clipped in the Cairo
library.
A Python version was added in b3fe980d70, the
main reason for removing the old one is that it's inconsistent to have two
tools where one does almost (but not quite) the same as the other.
Both versions check that the old and new images look the same. However, if any
tool changed the pixels' values then old script would discard the changes from
the other tools too. The new script checks the image after each tool is run, so
that the optimisations from the other tools can still be kept.
The indexed2rgb.sh script had a call to utils/wesnoth-optipng. It's deleted
instead of updated because both wesnoth-optipng itself (since 17c242a9f) and
the new woptipng both do what indexed2rgb.sh did (they all run ImageMagick with
option "png:color-type=6").
Add 'ability_id_active' attribute to filter
Until now, only the type of ability could be filtered with activity, and id only for unit who have ability, same if she's inactive.
If a widget is partially hidden or off-screen, this commit makes canvas.cpp
optimise and only draw the visible part.
Many of the asserts in canvas.cpp are removed, as the surface is no longer the
full canvas. The SDL_Render* functions do support the out-of-bounds and
negative values for x and y that are now passed to them, these are tested by
SDL2's testviewport.c.
Scrolling by a single pixel will force canvas::draw to do the full work of
redrawing the canvas. I had considered rendering a few of the off-screen lines
too, however it seems this isn't optimisable because the dirty flag is already
set on each redraw - that can be traced to window.cpp's push_draw_event()
causing canvas::set_is_dirty(true) to be called.
Refactor handling of the x, y, w, h variables with a common rect_bounded_shape
class, so that there are less code paths that might have unnoticed bugs.
