stronger_amlas: move from amlas.cfg to resources/AMLAs
stronger_amlas: Previously, use_stronger_amlas added extra AMLAs to units that match a certain filter. If units didn't match the filter when they were placed, but did later-on, they still wouldn't be eligible for AMLAs. Fix that here.
resource_weather: [terrain_graphics] cannot be assigned or modified mid-scenario, but can be filtered by ToD. To dynamically modify weather mid-scenario (such as in TSG), use these special "noweather" ToDs.
resource_weather: add wind
both: change textdomain to "wesnoth"
The use_stronger_amlas resources includes a modifiable filter to choose which units are affected.
Formerly, that filter did not apply to a help message, resulting in the ANKA help message appearing even for units that weren't eligible for the AMLAs.
EI contains a basic custom set of AMLAs, replacing the default +3hp for all player units. Units gain a +8hp AMLA option, and units with 1/2/3+ melee/ranged strikes gain options for +4/+2/+1 melee/ranged damage, respectively. Investing XP into these AMLAs remains much weaker than leveling a new unit.
* new ships Derelict Hulk and Fireship
* new "race" Ships - includes Transport Galleon, Pirate Galleon, Derelict Hulk, and Fireship
* Pirate Galleon chaotic
* animations for all four touched ships
* ship portraits for Derelict Hulk and Fireship
* crew portraits by LordBob for Boat, Galleon, Transport Galleon, and Pirate Galleon
* old (non-pixel art) transport galleon and pirate galleon images moved to scenery
hitpoints from 42 to 48
movement from 9 to 7
claws from 5x4 to 6x4, now usable on offense
bite from 15x2 to 9x2 charge, now usable in defense
arcane resistance from 20% to 10%
price from 21 to 30
Redesigns the Naga Guard, Shield Guard, and High Guard to make their shield bash attack less redundant.
Also adds the new Unwieldy and Guard specials, and deprecates the Absorb special.
* Removed duplicate map_location hasher, removed unused teleport_id variable, dst_node reference is used at other possible locations, teleport destination heuristic distance now calculated before path finding loop only once, teleport source heuristic distance now stored in nodes, only calculated once and reused.
---------
Co-authored-by: SomeName42 <>
1. remove obviously English and English sounding female names from Dunefolk female names list
2. remove 'bakri' from male name list (means 'goat', could be offensive)
3. remove one potentially offensive name from saurian name list
4. remove 'Dalal' from dunefolk female names (can be used as slang)
* Death Squire optional advancement and damage nerf
The existing {ENABLE_DEATH_KNIGHT} macro allows Revenants to advance to Death Knights. The newly core-ed Death Squire also advances to Death Knight, but has no {ENABLE_DEATH_SQUIRE} macro.
I suggest adding a new {ENABLE_DEATH_SQUIRE} macro, while keeping the old {ENABLE_DEATH_KNIGHT} for backwards compatibility.
I also propose reducing the Death Squire's attack from 8x4 to 9x3, to make the Revenant a more competitive advancement.
Who's the current maintainer of SotA? Should {ENABLE_DEATH_SQUIRE} be used there, or should we continue using {ENABLE_DEATH_KNIGHT}?
Hejnewar, if you approve, what cost should the Death Squire be after this change?
* Reduce Death Squire damage from 8x4 to 9x3
* Update Skele_Death_Squire.cfg
Multiline comments need the `po:` prefix on each line, otherwise that
line is ignored. This fixes all occurances of this.
Any lines which have nothing after the `po:` are still ignored, so I
haven't added it to the paragraph-break lines. The resulting .pot file
doesn't have paragraphs.
* fix raven SE sprite wings
* revisions to fire ant sprites to make more distinct from each other
* fix flame positioning
* minor soldier ant sprite update
* add IPF arg to MISSILE_FRAME_FIRE_BREATH for use in fire ants
* update copyrights.csv
At the suggestion of @stevecotton, I propose a special 'replacement_type' and 'alternative_type' attribute capable of modifying the type of attack used when the conditions are met.
Also make Holy water combine arcane damage with native type of weapon
Like holy water imbued ordinary weapon, it's seem logic what arcane damage dominant what if more efficient what original type(water can't altered pierce or blading of spear or sword)
using overwrite_specials alone means that we have only two possibilities, either one_side is chosen and in this case if the ability used as a weapon carrying the attribute is applied to the unit (apply_to=self), the other abilities are the same type applied also to 'self' not carrying the attribute will be overwritten, but those of the opponent with apply_to=opponent will be kept in the list; or else both_sides is chosen and all abilities of the same type that do not carry the attribute will be overwritten. To be able to use the attribute in abilities like [damage] for example, it is necessary to be able to be even more selective as for a 'charge' type leadership with multiply=2.5 but which must not be combined with the classic charge and without overwriting the aute [damage] as backstab, [overwrite_filter] to only match damage with apply_to=both and active_on=offense is then interesting.
adding priority allows you to select that it ability can use its overwrite_specials attribute while the others can be overwritten in the same way as an ability without the attribute. Finally, this system makes it unnecessary to limit the use of the attribute to abilities used as weapons but also to special weapons.
give abilities support of halo or overlay so that the unit benefits from a second halo or overlay when conditions are matched
One of the things that bothers me is the permanent character of the halos of the Mage of Light and other units with the "illuminates" ability, which forces them to program only a permanent illumination applied only to the possessor of the ability.
Adding the halo attribute to ability does not change anything about the behavior of the unit, but can be used in several cases:
1 allowing the use of ""illuminates" whose activity would be variable, in this case encoding the halo in [illuminates] ability and not in the unit_type allows to modulate the appearance of the halo under the same conditions
2. Applying illumination to adjacent units, I know it's pretty cheesy but a set developer might consider it easier if the hlo display follows the same logic.
3 The halo used to illustrate the possession in the unit of a special weapon used as leadership, the halo would be used to raise the possessor of the ability.
for overlay, same logic for illustrate possession of a special weapon used as leadership, or influence on student
with the "halo_image" attribute, it is now possible to give Sun Sylph units an illumination ability with an activity depending on the incarnate sun attack instead of giving the ability and the halo via obect and therefore allowing the player to have access to the description of the ability even when it is inactive.
The basis for this rework is lowering the extremes in acrance resistances between units and factions. That allows for more free usage of arcane damage and helps with balance of games in which high levels are way more frequent than in standard default 1v1 or 2v2.
Support (fe)male_name key in unit.
Support FEMALE_NAME in macros for named units with random gender.
Add female variants to generic unit names in DiD, TSG and UtBS.
Units still using this in their descriptions will have the player-visible
header change from "Special Notes:" to "Special Notes (1.14-style, please
update to the new list format)".
The SPECIAL_NOTES macro was originally removed early in the 1.17 dev cycle.
That removal was reverted and postponed in the roadmap until Jan 2023, on the
grounds that it's a lot easier to test 1.17 when the big add-ons from 1.16 can
run on it.
In 1.16, UMC that hasn't upgraded yet already has a cosmetic bug - the help
pages of units still using the {SPECIAL_NOTES} macro will include duplicate
notes (assuming the expected usage of {SPECIAL_NOTES} as a heading in
[unit_type]description=, which is followed by old-style notes). These are minor
cosmetic bugs, which are expected to be removed as UMC gets updated.
That leaves the issue of what to do with the deprecated macro in 1.18. My
feeling is that we can easily continue to support the macro, albeit with the
cosmetic bug, so we should keep it for 1.18. However we could make it clearer
that the duplicated notes should be removed from the UMC.
This also removes some docs about NOTE_*s, those macros have already been
removed after being deprecated in 3568b5ff66ece00ec09f40059e552123f356d962.
New macros:
* SCREEN_FADE_OUT - to replace FADE_TO_BLACK in most cases
* SCREEN_FADE_IN - to replace FADE_IN in most cases
* SCREEN_FADE r g b duration
- convenience wrapper for [screen_fade] with 255 alpha
* SCREEN_UNFADE duration
- convenience wrapper for [screen_fade] with 0 alpha
* FLASH r g b actionWML
- like FLASH_WHITE etc but takes a colour
* FLASH_LIGHTNING actionWML
- flashes an appropriate colour and plays lightning.ogg
Modified macros:
* FLASH_WHITE/RED/GREEN/BLUE}
- these now use [screen_fade] not [color_adjust]
It does the same thing as PLACE_IMAGE except the created item may
use the same submerge code as units. If not placed on water there
will be no submersion effect. If placed on water it will be submerged
to the same level a unit would be submerged to. In general physical
items placed into water should use this, whereas items placed on top
of water should use PLACE_IMAGE.
The new macro has been applied to the merfolk cages in the Bay of Pearls
scenario in HttT.
While this will be deleted before 1.18, at the moment UMC authors
are still working on 1.16. While the 1.17 branch is being used for
new development in the engine, I think it's more useful to be able
to run 1.16 UMCs that test engine edge cases rather than force the
UMCs to be upgraded for 1.18's macros.
There's currently circa 1200 units using `{SPECIAL_NOTES}` in
Ageless Era, probably requiring manual checks to update them.
Another option would be to `#define SPECIAL_NOTES` in the UMC
itself, but that would likely also mean that the warning was
silenced when running on 1.16, and few of the 1200 units would
get fixed during the 1.16 cycle.
This reverts part of commit 61fa3627818c1a3fb5181a21fc651b67d17b133a.
