Although it's already possible to pass {formula = "whatever"},
this change allows mixing that with the simplified syntax,
such as {formula = "whatever", side = {side = 3}}
These are taken as synonyms of the actual internal tag names, [first] and [second]. So, first is interchangeable with primary_attack and second is interchangeable with secondary_attack.
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
This is a somewhat controversial change!
PROS:
- This makes wesnoth.game_events.add a drop-in replacement for the on_event function
- If you're registering events in preload, most of them WILL be repeating events
CONS:
- This makes the default depend on the call style; in positional style, it defaults to repeating, and in named-argument style, it defaults to non-repeating
- This makes the default different from the WML default of non-repeating events
- Don't try to serialize an event with a Lua filter (ie, add{filter = function() end})
- Write the serialization warning to in-game chat, but ONLY if the event was registered after preload
* 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.
The function is specified by [event]code= and will be passed the entire contents of the [event] tag (including the code itself).
If code= is omitted, a default is supplied which runs ActionWML; however, internally it is still a function rather than a list of ActionWML commands.
I put a longer-than-usual description of rendering engine changes,
with a list of closed issues tacked on the end.
I also added items for screen_fade and a couple other things that were
resolved since 1.17.5.
* Add new [screen_fade] WML action
It takes (for now) the arguments:
* red, green, blue = values between 0 and 255
* alpha = value between 0 and 255
* duration = time in ms over which to fade
The game display is faded to the given colour over the duration.
It will be left with an overlay of that colour and alpha until
a screen_fade to 0 alpha is performed.
We don't want std::cerr to be used at all, and std::cout is only for certain special
cases such as command-line responses.
Therefore, log.hpp should not include <iostream>.
