* The editor_icon= key will now be respected in the Unit Preview Pane
* If no appropriate icon is found, a generic icon will be used instead, in both the editor
and unit preview pane.
There's no AI manager in the editor (a game state is required), nor a need for one, so I simply
disabled the AI initialization if we're not in the editor.
Fixes#2372.
It turned out that the AI kept dangling references to the old Lua state,
and crashed while destroying AI contexts for destroyed sides.
The best way to avoid it is to ensure that game_state, which already owns
the Lua state, also owns the AI. That way, the AI will be destroyed before
the Lua state and a dangling reference can't stay.
fix code problems found by luacheck
Second iteration of the process, now handling data/lua/wml/*.lua
luacheck command used to find bugs:
luacheck ./*.lua --globals wesnoth wml --codes --ignore 542 213
Additionally, error code 211 (unused variables) could be ignored,
as using underscore convention `_` is controversial in
wesnoth ( see https://github.com/wesnoth/wesnoth/pull/2380#discussion_r162519341 )
Actual bugs found:
* items.lua, access of global `write_name` instead of local `cfg.write_name`
* kill.lua, typo `primary_unit` -> `primary`
* bad code style: global `i` instead of local `i`
(would conflict with 3-rd party code if it would use global `i`, too)
Fixup 089fc02c298e7e4f6ed6bc57935cbf4811a03234. Not sure why this works, though.
-xmove, -ymove worked fine on accelerated_rendering... Or perhaps I just didn't
notice this issue.
Also made conditions fail if they encountered a syntax or runtime error. This seems the
more logical behavior than passing.
WML conditional tags were split into their own Lua file. The one in lua/wml/object.lua
relies on local variables so was left there.
Partial revert of commit ecbb15e1c6d1106ff2f8e540c584523481426c04.
Replacing bounded_add() with std::clamp() in these contexts disables
time-of-day bonuses, since ToD bonuses (the base value in these functions)
are almost always outside the range set in terrain properties.
* Dropped bounded_add for clamp. There's a slight behavior change with this, namely that
base is no longer returned if it falls outside the bounds. However, for both usecases of
bounded_add, that behavior doesn't make sense. The wiki clearly states min/max_light=
define the bounds for light=.
* Replaced gcd with Boost's gcd function. We already use the latter in the Preferences
dialog, so this is more consistent.
* Simplified the implementation of in_ranges.
actual bugs found:
* backwards_compatibility.lua (undeclared global "helper")
* core.lua (use of undeclared global "helper")
* wml_tags.transform_unit had wrong code to deal with recall_cost
* wrong variable name in cave_map_generator
__builtin_expect is something that should only be used if you're very sure it will result in
an optimization (see http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html).
This code was added back in 2008. It seems it was part of an effort to get the preprocessor
functioning faster. It looks like mordante played some role in the decision of where to use
the LIKELY and UNLIKELY macros, so it's possible it had some use at the time (he's a rather
experienced programmer).
However, it's better to let the compiler automatically optimize code itself. I haven't done
any profiling on the preprocessor speed with or without __builtin_expect, but it doesn't seem
worth keeping this around and having to test every so often whether it's still useful or has
become a performance hit instead.
It's also worth noting that I myself noticed what seems a perceptible performance improvement
in the game (again, not backed by profiling) when I switched from TDM GCC to MSVC 2017. IIRC,
I'm using at least quick LTO for my builds. Apples and oranges, yes, but it also proves there
are likely various compiler options (such as LTO) which could improve performance on their own,
and better, than trying to point the program down branch paths ourselves.
On Windows, win32 programs such as Wesnoth aren't allowed to use control
characters in filenames, and therefore attempting to create a save file
whose name contains control characters will always fail. In addition, some
control characters (newlines in particular) also break Wesnoth's UI, as
regular text fields aren't intended to display multiple lines.
Fixes#2366.
This reverts part of commit 468c6e0f494793d57b0b1264894cd7f0b0383fa2.
Ctrl+A was removed because its emacs meaning is surprising to some
people. Ctrl+E was removed because it was the counterpart of Ctrl+A.
Ctrl+U however doesn't conflict with anything else, and it's useful
to some people (me), so reinstate it.
* moved the new function next to valid_id()
* renamed to valid_tag(), and renamed valid_id() to valid_attribute()
* removed unnecessary parentheses I forgot in
* changed the name of valid_id()'s parameter from "id" to "name"
* changed WML parser to use valid_tag() when it validates tag names
Thanks to @CelticMinstrel who told me about config::valid_id().
This was introduced this development cycle (1.13) in 2015 (commit 6010455f563f4b16bb89f2df6893908a36251cdc)
and removed in 33c2e6aa67c9377f170f9302204a8de10c200564. Presumably the action was left for backwards
compatibility, but we do not guarantee backwards compatibility for changes that never made it to a stable
release.
The implementation differs from already-existing
wml.variable.proxy in that it does not try to proxy table sub-fields,
and is fast & simple.
Example usage:
wml.variables.test = 123
print(wml.variables.test)
Since events can be added and removed constantly, this should be more performance-friendly than
a vector since it avoids reallocations. Though, since this container only holds shared_ptrs instead
of the objects themselves, it probably doesn't make that much difference right now, but I might
switch to object-direct storage in the future. Not sure.
It turned out that it works fine as long as it's called with a char
rather than unsigned char. (But to add to the confusion, the other
variant of the function in <cctype> *requires* that cast.)
The function seems to just throw std::bad_cast() in libstdc++ and libc++.
Fortunately it's very easy to write our own implementation instead.
Thanks to @Pentarctagon for the stack trace.
