It can be used to draw rectangles and lines, particularly when
passed via drawing_buffer_add as this only supports rendering
textures, not other drawing operations.
It can be loaded as "misc/single-pixel.png".
This log definition really shouldn't work. It seems to rely on log
timestamps being globally disabled during tests. However that's what
it was set up to do, so i am not changing it more than necessary.
I also added a STREAMING_LOG logger, which is equivalent to PLAIN_LOG
except that it does not add the newline at the end.
Other loggers reprint the timestamp every time, so eliding the newline
was never useful for them anyway.
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.