newfrenchy83

> Why `[special_alignment]` and not just `[alignment]`? nemr changed to [alignment]

> Adding my current thoughts, but please don't read this as "changes required", it's just an update because I've not got review feedback ready yet. Definitely wait for @CelticMinstrel to...

> @newfrenchy83 - sorry if I caused you and anyone else confusion. Thanks for removing me as a reviewer. @Pentarctagon I agree it was strange of me to submit a...

@stevecotton i create a [unit_alignment] here: https://github.com/newfrenchy83/wesnoth/pull/79 it is that what you want?

i added a unit_alignment abilities here.

> Still wondering whether `specials_alignment` could return a `unit_alignments::type` or `std::optional`, and therefore avoid duplicating code from `combat_modifier(effective_tod, alignment, is_fearless)` or `generic_combat_modifier`. My feeling is that it feels like too...

> Still wondering whether `specials_alignment` could return a `unit_alignments::type` or `std::optional`, and therefore avoid duplicating code from `combat_modifier(effective_tod, alignment, is_fearless)` or `generic_combat_modifier`. My feeling is that it feels like too...

@stevecotton add a separate commit here: https://github.com/newfrenchy83/wesnoth/pull/79/commits/2fe7b1f63217ee1a68cc3600c57760bbcc6dd3fb for [unit_alignment] abilitie

> If adding `[unit_alignment]` in this PR is intentional, please change the title to reflect that it's adding two new tags instead of just one. done

> > The default priority rules are; fire, arcane, cold, pierce, blade and impact > > This seems both arbitrary and nonsensical. Shouldn't it be more of a "last one...