Commit 43de778 made all themes scale from their base dimensions rather
than from an arbitrary hard-coded 1024x768 pixel size. As a result, the
800x600 layout for the editor needs its main map explicitly sized --
the 843-pixel width no longer fits in 800x600, and it isn't being scaled
down from 1024. (But once it is explicitly set for the 800x600 layout,
it will scale up for pixel widths between 800 and 1024). This commit
adds such an explicit sizing, analogous to the one found in default.cfg.
Resolves#5193.
This is a "it's known to be broken, so let's rip it out and put in a minimal
replacement" change. Updated raw pointers to smart pointers just because,
updated the docs a bit, and ended up with a big change.
Fixes the most visible part of #5194, where Chinese needed DroidSansFallbackFull
to be loaded before DroidSansJapanese. The removed code in
`char_block_map::insert` and `char_block_map::compress` had a bug that
triggered when one font had a contiguous range of codepoints that was a
superset of several ranges in another font - this meant it treated the first
font containing U+4E00 as having the whole CJK Unified Ideographs block.
Remove the now-unused font codepoints WML. There is no schema change for this,
it seems the data/hardwired/fonts.cfg file isn't checked by the validation.
Optimise calling set_font_list with the same list (but possibly reordered), by
reusing the already-loaded fonts.
Getting fonts in the correct order is important for CJK (Chinese, Japanese,
Korean), as the same codepoint may have different images even between
DroidSansJapanese and DroidSansFallbackFull (see discussion in issue #5194).
This method of calling load_font_config() to reload the fonts is already used
during startup - see the two calls to it in src/wesnoth.cpp. This commit should
ensure that, if starting the game in a given language works properly, then
changing to that language without restarting also works properly.
Added support for the `Add-ons` tag to the pull-request labeler.
File changes in the following directories will be marked as related to the addons system:
- src/server/campaignd/**
- src/addon/**
- src/gui/dialogs/addon/**
This changes the legend at the bottom of the screen from
FG: Savannah/Forest (Forest,) | BG: Green Grass/Grassland (Flat)
to
Left-click: Savannah/Forest (Forest, ) | Right-click: Green Grass/Grassland (Flat)
Shift + left-click: paint overlay layer only | Ctrl + click: copy terrain
or (with a non-overlay selected)
Left-click: Desert Sands/Desert (Sand) | Right-click: Green Grass/Grassland (Flat)
Shift + left-click: paint base layer only | Ctrl + click: copy terrain
Depsite being a [modification] this is actuall implemented
in the C++ code the [modification] just sets a flag.
This is meant as an alterntive to the preset advancement
type of mod, i want to play around with it a bit in 1.15
maybe we will remove it later.
The problbme this is supposed to fix is that advancemnts
are done randomly during the enemeies turn. It has a few
advantages over the preset advancemnt approach:
1) It can easily handle amlas and normal advancement
2) It doesn't need special code to handle the case that
A unit advances multiple times.
3) It doesn't break in case that other wml code changed
The advancements of a unit after the preselected advancement was chosen
4) The user never needs to think about an advancement of
a unit that might not even advance
It also has a disadvantage: it changes the rules of the
game quite a bit, in partiucar if the units heals form
an adcancement (which us usally the case), since now
with this 'healing the unit on advancement by retaliation'
during the enemies turn can no longer happen. I still
think its wirth to think about this and test it though.
Despite having exception handing in process(), the loading screen is only designed to handle one exception from the worker.
If such an exception propagates to the worker, the loading screen would rethrow it in process(). It turns out we don't need
an exception_ptr, since the exception would already be stored in the future returned from std::async. Fetching it with get()
causes it to be rethrown at that point, same as before.
Do note we do not want to simply call get() and wait, since that essentially calls future::wait() instead of future::wait_for()
and would halt the main thread while it waits for the worker. Hence, we still manually check its status before fetching the
exception (if any). As a bonus, it means we can use future::valid() as a check for whether the worker is still running in the
dtor, since calling get() sets future::valid() to false. Any premature exit of the loading screen after the worker thread is
created or its exception is handled in the finally process() loop will trigger the safe_exit call.
* terrain graphics - fix sconce/candle overlay on south-facing corners
* terrain graphics - some fixes and minor additions to stone walls, mostly Xot^Edb
* new terrain - add 'Xof', overgrown walls
* terrain graphics for Xof^Efm - flowers on walls
* terrain graphics - fix broken molding in standard stone wall
* terrain graphics - fix molding on catacombs
Several new animals were added in PR #5039's
cbad6f42492be5fcbf8c29a3d10cbc43598ba32c.
The micro-ai demo can be accessed by starting Wesnoth with the command-line
arguments `--test animals`. The scenario uses some stand-ins for animals that
weren't in mainline; the new bears and tuskers fit straight in. For the sheep,
the icemonax's graphics are a bit more sheep-shaped than the troll whelp's.
This demo doesn't need to be balanced, the changed unit stats are no problem.
UtBS's dustboks aren't in core, otherwise I'd use them as the deer stand-in.
* Fixes#4223, by making the --validate and --validate-* options imply --nocache.
* Fixes#4224, showing an error if you misspell the id argument to
--validate-addon. The application doesn't (but should) quit automatically to
avoid the user spending time on a non-functional validation run, however it
does at least disable all add-ons, which should have the same end result.
* Shows a warning that --validate-addon needs the user to play the add-on, it
doesn't automatically check the add-on. This was my misunderstanding when
logging issue #4225, which has now been repurposed into a feature request for
a new tool that does what I thought --validate-addon did.
