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).
Fixes#5755.
This is one of several layout invalidation hacks used in the old Lua
GUI2 API lost in the implementation of the new API (which the old API
now wraps).
It turns out that in the previous API (see 1.14 for reference if you
need easy access to the source) there were several calls to
invalidate_layout() that weren't there just to look pretty.
For wesnoth.set_dialog_value:
* One prior to setting the value of a text_box
* One prior to setting the value of a unit_preview_pane
* One prior to setting the value of a styled_widget
* One after changing a widget's visibility to hidden
All of these were removed by the new API implementation, with the last
one ending up commented out, restored now in commit
8989eb430311092e66177bc09e1b1c344000d5aa. All the other ones are
entirely gone, however.
It turns out that the dialog layout invalidation done for the
styled_widget case was essential to get listboxes working correctly
after clearing and adding rows to them (which was automatically done
right before in the implementation of wesnoth.set_dialog_value by the
find_widget() helper function). It was done for every single listbox
item, but without it the listbox would become completely useless under
certain conditions:
20210501 03:24:37 error gui/layout: grid [_content_grid] place: Failed to place a grid, we have 39,30 space but we need 39,93 space. This happened at a grid with the id '_content_grid' in a 'N4gui27listboxE' with the id 'list' in a 'N4gui24gridE' with the id '_window_content_grid' in a 'N4gui24gridE' with the id '_content_grid' in a 'N4gui215scrollbar_panelE' with the id '' in a 'N4gui24gridE' with the id '' in a 'N4gui26windowE' with the id ''.
Now, it seems horribly inefficient to do this for every single new row
added to the listbox, but this solution *works*.
As for the text_box and unit_preview_pane cases, their presence or
absence doesn't seem to affect anything in my testing with a live
dialog, so I'm not adding them back until someone runs into a bug with
them.
Most of the places that created a help_manager did so just to call show_help on
the next line. Move knowledge of the internals out of those callers and into
help.cpp.
This leaves editor_controller and play_controller with knowledge of help_manager,
however both of those classes handle ownership of the game_config too.
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.
This is prompted by 1f8101ef22bb23699421505235f4962802773c77. This
approach should still be correct while hopefully not bothering any
compilers *and* avoiding unnecessary copies or conversions until the
input actually needs to be converted to a different type (in this case
std::string_view, which is cheaper than std::string).
When an [about] section has a title but no [entry] tags, it's automatically
hidden in the credits. The entry with name="" was causing the title to show
up with a blank section under it.
[ci skip]
If a tool made the image bigger, the debug message was the same as if the tool
had made the image's pixel change. Clarify that into two separate messages.
As each verify_images() call checks that the file became smaller, the removed
print statement would never be reached.
57 of 57 files optimized, 678061 bytes reduced to 586300 bytes; -91761 bytes, -13.53%
This was running with the -t0 option, so that it considers any reduction good, even
if it's less than 10% on the big portrait images.
