Prior to this commit, the scaled= attribute was undocumented and had what I
assume was a bug - when enabled the image was scaled up to the width and height
of the background - not to the same ratio as the background, but to the full
size. So if you had a 1000 pixel wide background in an 800 pixel wide window,
then scaled=yes meant each journey-marker was an 800 pixel-wide blob.
However, if anyone was using it with background-size images as overlays then
this commit will break that usage - that use case is still supported by having
multiple [background_layer]s.
Closes#5223, which was a question about whether to fix or simply remove the
scaled attribute. Given that [background_layer]scale= and [image]scaled= have
different meanings (the background_layer one should and does cause it to be
full-window), I've kept the 'd' on the end of 'scaled' too.
Use a loop instead of recursion. This cleanup is prompted by #5041 (drawing
map labels in IntroWML), which will add more items to be drawn in this loop.
The old implementation would not have triggered tail-recursion optimisations,
as the recursion site wasn't the final code in the function.
Correct documentation in the .hpp file about when the delay takes effect (this
isn't a behavior change, just a documentation correction).
Review the schema, and remove attributes that aren't supported by the code.
Many of these attributes are supported for `background_layer` but not `image`.
This is about 10 lines of translatable text, not sure if it's okay to backport to 1.14.
The storyline itself is going to have large changes by 1.18 (maybe 1.16), so I'm not sure if
this will ever be in a stable release.
If a player loads a start-of-S02 save without the who_slew_mordak variable then it will still
work, showing the "I saw the killing blow with my own eyes" version.
Explanation for what's going on (put in the commit message because this bit is non-canon):
There are some "grey mages" in the Grey Woods, who appear in the Liberty
campaign. Most of the details of these were removed from 1.15, but in 1.14's
Liberty S06 they don't tolerate necromancers. SotA mentions an ancient elvish
civil war in these woods, with the ghosts still haunting the battlefield. I'm
assuming a general truce between elves and grey mages, on the understanding
that the grey mages are doing exorcisms of ghosts from the ancient war.
The existing tag has a confusing name - it returns the chance to be hit rather
than the defense, for example 30 would be returned for a unit on 70% terrain.
The new tag returns a higher-is-better value.
None of these had any effect, either on 1.15 or 1.14. I doubt that they ever
had an effect, because if these story screens had 4 second or even 8 second
delays then it would surely have been treated as a bug.
The image added here is a grass background to draw units on via Image Path
Functions. For the documentation, a square image looks better than a hexagon
that has black borders.
The change in theme.cpp is just to make the "title_literal" key be consistently applied as documented. Since the key isn't used in mainline, it should have no effect on actual uses.
This warns about tag definitions that can never match any tag (or for which one element of the comma-separated list can never match) because there is an earlier-defined tag definition that would match it instead.
The new check also found some errors in the schema, which have been fixed.
previously the code put the brackets in the wrong
line and handfixed that but a wmlindent comment,
but that then broke possible other uses of that
macro.
* SoF S9 - some cleanup to the final scenario
* Sof S9 - change time to tint red, replace remove key, add some small dialog to explain the reduced recall cost
* SotA - units - new sprites for sea captain, including non-skeleton undead version
* SotA - Sc4 Intro revision for ghoul background
* SotA - remove y,z characters from terrain codes, all campaign codes should now end with S.
* core terrain - new iron fence terrain *^Eqf
* SotA S2 - change large custom fence to iron fence
The remove attribute for [event] was never added to the validation schema,
and using [remove_event] seems easier to search WML for. Let's just recommend
the new key and deprecate the old one.
Instead of using the allied orb during their turn, the unmoved, moved and
partial orbs are shown. The player's own units will be shown with the moved orb
during the ally's turn, which matches the previous behavior. This is intended for
co-operative MP campaigns, where it will make it easier for players to discuss
possible moves. The UX is also visible in SP scenarios with allied sides, HttT's
first scenario is an easy place to see what it does.
If another status is added to the orb_status enum, this code is likely to
support it with no changes needed for the parts in this commit. For example,
issue #5155's proposed orb_status::disengaged has been tested with this.
Updated the documentation about orb colors. In these docs I've moved all of
the images to a single line above the bullet-pointed list, as otherwise the
layout looked bad once a line wrapped - the first line appeared
horizontally-aligned with the center of the image, the second started under the
image.
Added documentation about the delay in multiplayer games, as the purpose of this
orb-coloring feature is to assist discussion in multiplayer games.
Changed experience of Cave Bear to 100 since the Cave Bear is L2 and has no advancements.
Changed experience of Great Icemonax to 100
Changed experience of Giant Stoat to 25 since this unit is L0 and has no advancements.
Give Tusklet the Gorer as advancement since Tusklet (L0) and Gorer (L1) are of the same unit line.
Changed experience of Gorer to 50 since the Gorer is L1 and has no advancements.
Changed experience of Giant Ant to 25 since the Giant Ant is L0 and has no advancements.
It should be easier for the translators if each string is a separate translatable string. That way, they don't even need to worry about taking care with commas.
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.
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.
