[engine] Streamline WML code for event-driven abilities

[peet]

There are quite a number of specials and abilities that are triggered by some event in the game. Some are in mainline, while many others are UMC. Most common is the special that is triggered when a unit successfully hits another, but others are triggered when the unit kills another or is hit itself.

However, for most of these a rather complex and ugly WML code has to be written to handle it. And when that happens the AI can't "see" the ability and can't come up with tactics to use them.

I would like to see in an upcoming version a WML solution to this issue. It is clear that the mechanisms for this type of code already exist - the slow, poison, plague, and drain specials all use some programming to identify when the unit hits or kills another. Making WML be able to access this coding would be great.

Perhaps a statement in a tag like:

Code: Select all

when=on_strike

could be used to indicate when the ability or special would fire.

Here are some examples I can envision for the when= argument:
on_strike - whenever the unit hits another
on_struck - whenever the unit is hit
on_miss - when the unit fires and misses
on_missed - when an enemy fires on the unit and misses
on_kill - whenever a unit kills another
on_die - when the unit dies
on_attack - when the unit makes an/the attack (depends if this is in an [abilities] tag or a [specials] tag)
on_defend - when the unit is attacked or defends with an attack type

I know this will take some work to implement but I imagine i will be worth it.

Thoughts?

Peet

[Dixie]

This would not fix the problem entirely, but the event is not just the trigger: it's also the effect. Fine, we'd have a key for "on_stike" (for example), but we'd still need an event to give/remove (steal) gold (is in the pickpocket special), to give back some mps to the attacker (as in hit and run), or any other conceivable effect.

The simplest solution would still be to allow events in abilities and specials, or to add a special event-like that could be named something else if needs be ("consequence"? "effect" is already taken...)

[peet]

Of course, this is true. But the point is to try to reduce the WML to something less ugly and manageable.

For example, the "feeding" ability has a lot of ugly code and also causes load speed problems when you have a lot of units with feeding in a game. Changing HP totals ought to be a relatively easy thing to do in an ability, and yet we are left with the messy system we have now.

So such a change in WML would also require more things that could be put in an [abilities] or [specials] tag. But if any feature of a unit is changeable in such a tag then we are most of the way there.

Peet

[Insinuator]

Here are some examples I can envision for the when= argument:
on_strike - whenever the unit hits another
on_struck - whenever the unit is hit
on_miss - when the unit fires and misses
on_missed - when an enemy fires on the unit and misses
on_kill - whenever a unit kills another
on_die - when the unit dies
on_attack - when the unit makes an/the attack (depends if this is in an [abilities] tag or a [specials] tag)
on_defend - when the unit is attacked or defends with an attack type

Many of these conditions are already predefined under the [event] tag. As Dixie said, adding a "when" filter would just increase the amount of coding needed, rather than decreasing. I think there should be more predefined parameters for the [event] tag. This would give greater flexibility and decrease "workaround" WML. Particularly the on_kill that you mention. As it is now, you have to basically work backwards with that one.

[Max]

However, for most of these a rather complex and ugly WML code has to be written to handle it. And when that happens the AI can't "see" the ability and can't come up with tactics to use them.

being able to put action wml in abilities would indeed be nice. but it wouldn't help with the ai issue (too slow and complex to take custom abilites into account).

[peet]

Many of these conditions are already predefined under the [event] tag. As Dixie said, adding a "when" filter would just increase the amount of coding needed, rather than decreasing.

It would increase the amount of coding needed in the actual program, yes, but not necessarily by as much as you think, since it is clear that the wesnoth program already does these things for some abilities and specials.

The point is to reduce the amount of WML needed to create these specials/abilities, because then you don't need to create a separate event outside of unitWML to run the special or ability. If you could actually put an [event] tag inside a [specials] or [ablities] tag then that might do the trick, but you can't at the moment.

This would have a few advantages, one of them being that it would make it possible for the AI to recognize these specials/abilities. Another is that it would reduce the amount of WML needed to design a unit, and since the load time of saved games seems to be based on how much WML data there is this would improve game performance. It also makes abilities WML for UMC less ugly.

[pauxlo]

To make it possible for the AI to use this, the AI would have to understand what the effects of an event are, independently of whether the event is embedded in the ability/weapon special or the event simply uses some condition.

This is non-trivial (not to say, it is impossible in general, see halting problem).

[Rowanthepreacher]

As a novice of Wesnoth modding, and eventual coder extraordinaire, I'd appreciate this