Forgot that variation_name has an actual meaning when paired with
variation_id as opposed to it just being a deprecated form of
variation_id. This makes it so it's favoured by the UI over a
potentially overridden type name when present.
This makes it so the mainline Walking Corpse and Soulless units have
their translatable variation names properly displayed.
Instead of generating the unit preview from the gender variation
attached to the unit type variation, we need to generate it from the
unit type variation attached to the gender variation. I know this sounds
really crazy, but it matches the behaviour in unit::advance_to():
// Adjust the new type for gender and variation.
const unit_type& new_type = u_type.get_gender_unit_type(gender_).get_variation(variation_);
This behaviour is also relied upon by at least one pre-existing add-on
(After the Storm Episode 3, Demon Shapeshifter unit type).
Without this patch, the preview display doesn't reflect gender
variations at all when a non-default variation is selected.
As a side-note, the fix also makes the logic in
unit_create::update_displayed_type() simpler since we don't need to
verify if the variation exists at all -- if it doesn't we just get the
parent unit type back.
* Make the default variation's label "Default Variation" instead of
just "Default" (see below).
* Drop the "Variation:" and "Gender:" labels as they take up valuable
real estate and aren't strictly necessary since the controls they are
attached to are very much self-explanatory. This is a debug mode
utility dialog anyway.
* Swap the order according to option importance -- gender is usually
thought of as more of an essential property of units than their type
variation, especially since unit types with multiple variations are
rare in mainline. This means that the gender options are now on the
left instead of on the right.
* Improve display alignment for the variation/gender options row.
Yes, we already know it's a debug mode functionality. It says so on the
context menu and we needed to use :debug to get here. No need to make
the dialog caption pointlessly long.
Modified the `translation` tag in the addon structure and made the translated names shown in the corresponding locale on the client side.
See the related pull-request for more information.
The reasons being:
* It's been unmaintained for several years now, so any bugs that might be reported against it will almost certainly not be fixed.
* Having been unmaintained for so long, even if someone wanted to create a custom Wesnoth IDE plugin, it's unlikely this would be a good foundation to continue with anymore.
* There are at this point better alternatives that people are actually using and maintaining (such as the VSCode plugin).
* Having this be present can give the impression that this IDE plugin is something UMC authors should still be using, which I think makes it actively harmful. Case in point, the current version of this available on SourceForge (2.0.1) was downloaded twice as of the current week; however the most recent version (2.0.2 in the changelog, or 2.0.3 based on some git commits) is not available on SourceForge at all, nobody apparently ever uploading it.
This fixes the case when the unit cannot reach the previously found next_hop location from the ideal next_hop location in the part of the code that tries to keep units from moving in single file.
The former was added in commit 40a1e7d3fa74d59e7bba2d23fc535d9aa0a7f499.
However, ai/testing predates it by several years (added in commit
ab540dca1517e82d0f93153604cdb00f256becd6).
Reasons:
* These projectfiles are still 32-bit, whereas all other builds for all other OSes are now 64-bit.
* Relatedly, these projectfiles are dependent on the libraries kept at the aquileia/external repository.
* VS2019 is still listed as supporting Windows 7, so there is a minimal likelihood of developers not being able to use VS2019.
* The VS2019 projectfiles instead use vcpkg to get the required dependencies, which is easier to setup than the aquileia/external prebuilt libraries.
* It's one less thing that needs to be updated whenever source files are added/moved/removed.
* It's two fewer jobs that Travis needs to run, which means Travis builds will finish more quickly.
Now, during an active game, (that is: not during
campaign selection for example) the engine hides
all toplevel tags from addons that are not
involved in the current game. 'involved' here
means providing one of the [campaign], [scenario],
[era], [multiplayer], [modification] or [resource]
tags that are active in the current game.
Fixes#4832
This commit prepares a patch to disable unused
addons during a game. We try to reduce codes
that change the game_config config object.
In particular this removes a code that changes
the order of terrain graphics tag. This could
in theory break code that relied on that order
but afaik the terrain_graphics tags offers a
`precedence` that allows users to specify the
order in which terrain graphics are applied.
so no additional compatabiltiy code is needed.
the game_config_view object offers const
access to the game_config object, furthermore
it allows the game_config config object to be
replaced by a vector of config objects which
is what we will do later.
