The past change in 1.15 changed not only internal things,
but also the overlay given by the NO_UPKEEP macro.
Now it gives the same overlay as the loyal trait does.
Which is also the same which this macro gave in 1.14.
since the recent changes to overlays= in particular 1a7724e5472,
e71033374c35 and b2cd1cf6c [unit]overlays= is no longer the
recommended way to add an overlay and the use of the
apply_to=overlay effect is reccomended instead, so adding it
to the [trait] is the most natural option here.
this in particular fixes#4058 . Also people simply forgetting the
IS_LOYAL macro was a not-so-uncommon cause of bugs.
In some cases people want to give the LOYAL trait without giving the
loyal overlays for those cases i added a optional OVERLAY parameter to
the {TRAIT_LOYAL} macro, also heroes should now use {TRAIT_LOYAL_HERO}
instead which uses the hero overlay. The IS_LOYAL and IS_HERO macros are
no longer needed in combination with those traits.
Many UMC projects have a macro for this function, but the name isn't
standardized (RECALLXY and RECALL_POS are also in use). However, regardless
of name, all these macros follow the "id x y" order, so for compatibility
I have kept that order. UMC authors started with a RECALL macro and added
coordinates, while the unit-generating macros have to organize a lot of
extra fields that are irrelevant to [recall].
...since x,y= is the same for units on the recall list. It still
doesn't work for these (and ADVANCE_UNIT too) due to bug #17023 but at
least the units don't get lost now.
* Removed instance of generate_name=yes from macro NAMED_NOTRAIT_UNIT,
as it was conflicting with the presence of name=.
* Made the example for NAMED_NOTRAIT_UNIT correct.
Pre-declare {FOREACH and {NEXT.
Write declarations in the one place they're presently needed, Sceptre of Fire.
Reindent the data tree accordingly.
This partly addresses the feature request in bug #12180.
...that I removed in 2008-07-13T16:27:37Z!crazy-ivanovic@gmx.net and 2008-07-13T16:37:29Z!crazy-ivanovic@gmx.net,
mistakenly believing them to be no-ops.
