[WML] Event: name = aura_gain, aura_fade

[Xudo]

In this topic by "aura" I mean "Ability which affect adjacent units". For example: Leadership or Illumination, or any other ability which affects adjacent units.
By "source unit" I mean "unit which have the aura" (unit which have the ability which affect adjacent units). Elvish captain is source unit for aura Leadership.
By "victim unit" I mean "unit actually affected by aura". It might be any unit, which is adjacent to source unit and matches [affect_adjacent] filter.

Event with "name = aura_gain" will trigger when victim unit gets the aura. It might happen when source unit gets unstored, created, recruited, moved.
Event with "name = aura_fade" will trigger when victim unit loses the aura. It might happen when source unit gets killed, stored, moved.

[Pentarctagon]

Couldn't you simply check if any adjacent units have the illuminates or leadership abilities on a moveto event?

[Xudo]

It is not that simple. Some time ago, I have thought: "What does it takes to create some custom aura, which is not based on percentages." and tried to find a solution. I have ended up with handling whole bunch of related events.
There was:
* 4 different moveto (source to victim to apply, victim to source to apply, victim out of source to remove, source out of victim to remove)
* die (of source to remove)
* recruit (of source to apply, of victim to apply)
* I also should not forget about [store_unit] with kill=yes to remove
* ... and about all [unstore_unit] with find_vacant = yes to apply
* there were something else, I can not remember now

In game core, all those situations are already handled. Why not to expose aura application event to WML?
If this will be implemented, it will be much easier to create a lot of unusual aura abilities for UMC.

[Pentarctagon]

Then perhaps it would be better to consolidate and simplify the use of auras in WML? So instead of having [illuminates] and [leadership] and then having to implement any other custom auras by hand, have a single [aura] tag that is more flexible and able to affect a wider variety of stats. To incorporate your idea about events, there could be a pair of keys like:

Code: Select all

[aura]
fire_event_on_gain=event_one
fire_event_on_fade=event_two
[/aura]

[Xudo]

Your idea about [aura] tag is good, but I would like to add one more key.

Code: Select all

[aura]
fire_event_on_gain=event_one
fire_event_on_fade=event_two
fire_event_on_turn_refresh=event_three
[/aura]

To allow implementation of auras with periodic effects.

From other point of view, this way is a bit insosistent to the rest of existing WML.
For example if one wants to handle death of specific unit, he creates event name=death and specifies filter.
In this case, one wants to handle aura gain and aura fade. I expect he will create [dummy] ability and create event name=aura_gain and specify filter.

[optimother]

Your idea about [aura] tag is good, but I would like to add one more key.

Code: Select all

[aura]
fire_event_on_gain=event_one
fire_event_on_fade=event_two
 * * fire_event_on_turn_refresh=event_three * *
[/aura]

To allow implementation of auras with periodic effects.

I like it very much, because this would allow a clean solution for healing ability without a dedicated tag, which seems a hack to me.