New macros:
* SCREEN_FADE_OUT - to replace FADE_TO_BLACK in most cases
* SCREEN_FADE_IN - to replace FADE_IN in most cases
* SCREEN_FADE r g b duration
- convenience wrapper for [screen_fade] with 255 alpha
* SCREEN_UNFADE duration
- convenience wrapper for [screen_fade] with 0 alpha
* FLASH r g b actionWML
- like FLASH_WHITE etc but takes a colour
* FLASH_LIGHTNING actionWML
- flashes an appropriate colour and plays lightning.ogg
Modified macros:
* FLASH_WHITE/RED/GREEN/BLUE}
- these now use [screen_fade] not [color_adjust]
This implements an add-on extraction progress dialog that does not
actually run its own event loop, allowing the caller to take ownership
of it (display() static method) and update its state using a callback
function object. The object in question is passed into the add-ons
management API and used to update the dialog status each time an add-on
file is written to disk as part of the pack extraction process.
In order to avoid stalling the extraction process in UI code, the
callback is invoked for every single file, but the dialog's progress
update method places a time restriction on GUI2 API calls of 120
milliseconds -- this is a good throttle interval that allows add-ons to
be extracted in about the same amount of time as before while still
updating the progress bar smoothly enough for add-ons that take longer
than that.
(This is not the most trivial code to test, so it is suggested to add a
sleep/delay API call in unarchive_file() in src/addon/manager.cpp to
introduce artificial delays.)
One issue with this code, however, is that because modeless_dialog
doesn't execute its own event loop, the only way to get the dialog to be
updated is to force a draw event in ourselves via the new
gui2::dialogs::modeless_dialog::force_redraw() method. This is really a
side-effect of my design choice here to run the dialog in the middle of
a blocking operation instead of somewhere where events are being
processed normally. I'm not entirely sure if the draw events would be
pushed even in that case, however.
Closes#1101.
Using colors to make relevant information stand out at a quick glance.
The six attack type icons are recolored using the six equidistant hues cyan, green, yellow, red, magenta and blue, with the same saturation and lightness as the old icons. The images are optimized with woptipng.
Resistances and movement costs are colored using a gradient from red to green, like the defense values.
The resistance table in the help browser now also shows the attack type icons.
Previously, the resistance table was always ordered alphabetically by their original English names (not their translation, unlike the terrain modifiers). Now, the order is set to blade - pierce - impact - fire - cold - arcane.
These changes are made in all relevant areas, including the help browser, tooltips, the sidebar and dialogs.
Missing icons are handled by replacing them with a blank image scaled to the same size.
Re-created hotkeys file.
Borrows heavily from https://r.wesnoth.org/t41525.
Most of the common commands now have single keystrokes on the keyboard in addition to their currently defined keystrokes. Almost everything remains the same, except the following has changed:
* Continue is now `C` instead of `T`
* Go to Leader is now `K` instead of `L`
* Kill Unit is now `DEL` instead of `X`
* Undo is now `Z` or `CTRL + Z` instead of `U`
* Redo is now `SHIFT + Z` or `CTRL + SHIFT + Z` instead of `R`
* Planning mode is now `ALT + P` instead of `P`
* Delete Action (Planning Mode) is now `BACKSPACE` instead of `H`
* Suppose Dead (Planning Mode) is now `X` instead of `I`
Many items where the effect does not make sense (or looks especially
bad) were passed over and will appear on top of water as previously.
This could use more definition by using submerge values other than
0 and 1 (numbers from 0.0 to ~2.5 work as it multiplies the base
unit submerge value) however there is a bug with blitting transparent
textures so it will not appear correct for the submerged part.
It does the same thing as PLACE_IMAGE except the created item may
use the same submerge code as units. If not placed on water there
will be no submersion effect. If placed on water it will be submerged
to the same level a unit would be submerged to. In general physical
items placed into water should use this, whereas items placed on top
of water should use PLACE_IMAGE.
The new macro has been applied to the merfolk cages in the Bay of Pearls
scenario in HttT.
Basically this means each of the call modes of the old function is now a separate function.
- add_repeating and add_menu take an ID and a function
- add_wml takes variable substitution setting and a config
- add takes the full options table
* These functions take the full event data config as the final argument, rather than just the weapon info subconfigs.
* The [fire_event] tag now supports a [data] tag that can add additional data to the event, for example damage_inflicted. The [primary_attack] and [secondary_attack] tags are still supported and are not deprecated.
* wesnoth.current.event_context now has a data child which holds the full event data. It still duplicates common info (weapons and damage inflicted) in the same way as before.
Unlike the old wesnoth.game_events.on_event hook and the "convenient" on_event() wrapper for it, this new functionality supports all of the features of WML events, with the sole exception of serialization, since it's not possible to reliably serialize a Lua function.
This commit also divorces menu items from the event that they trigger. The undocumented wesnoth.interface.set_menu_item function no longer adds an event for the menu item; the caller needs to separately register an event using the new functionality.
