Movetype patching

[CelticMinstrel]

This introduces a way for custom terrains or damage types to be patched into pre-existing movetypes; previously the only way (as far as I know) to get this sort of effect would've been to use [base_unit] to make duplicates of all the unit types with the movetype you wanted to change. It uses the formula engine to allow you to set the new resistance/defence/cost base on the value of one or more resistances/defences/costs from the original movetype; for example, if you added a new "sonic" damage type, you could declare that the sonic resist level is equal to half the impact resist level for some movetypes.

Although the purpose is for adding custom damage type and terrain support to existing movetypes, this could in theory be used for any kind of tweaking of existing movetypes.

An example of the syntax (this goes inside [units]):

[damage]
    type=sonic
    default="(impact - 10)"
    smallfly="(impact / 2)"
[/damage]
[terrain]
    type=fire
    [defense]
        default="(unwalkable)"
        largefoot=30
    [/defense]
    [movement]
        default="(unwalkable)"
        largefoot=8
    [/movement]
    # [jamming] and [vision] subtags also supported here
[/terrain]

[gfgtdf]

I'm a little confised by your example: the type= in [terrain] must be a valid damagetype or is that just ranomly the case in your example?

[CelticMinstrel]

That's just coincidence. The type= in [terrain] should be a valid base terrain ID; the first thing I thought of was lava, but that already exists, so I went with creating a fire terrain.

[Elvish-Hunter]

One problem that I see with this patch is the use of the [damage] tag, which is already used for attack specials. Instead (to avoid confusion and future wmllint issues) I'd go for [damage_type], and replace type= with something like id= or name=.
The [terrain] tag, being already a DirectActionWML one, suffers of this issue as well. Maybe, if technically possible, support for the additional keys and values should be added to [terrain_type]?

[CelticMinstrel]

I considered adding it to [terrain_type] rather than making a separate tag. The main reason I chose to go this way is because I wasn't certain that the movetypes are guaranteed to be processed before the terrain types, though in my tests it did appear to happen that way. In the end I decided to put it in the same place as the damage type ones so as to have a more... unified syntax, I guess. But I could move it over to [terrain_type] if that's preferred. Are there any other opinions on this?

Changing tag names is a trivial change. I personally don't think it's much of an issue that the names are also used elsewhere, but if you think that's an issue, I'd be happy to change the tag names.

[irydacea]

We have actually deliberately moved away from shared tag names in different contexts having different semantics, in the past. [unit_type] and [terrain_type] used to be [unit] and [terrain], for example.

[CelticMinstrel]

I think there are still a few though (I think one of them is [teleport]). But okay - I'll update this soon.

[CelticMinstrel]

The syntax now looks like this:

[resist_defaults]
    id=sonic
    default="(impact - 10)"
    smallfly="(impact / 2)"
[/resist_defaults]
[terrain_defaults]
    id=flame
    [defense]
        default="(unwalkable)"
        largefoot=30
    [/defense]
    [movement]
        default="(unwalkable)"
        largefoot=8
    [/movement]
    # [jamming] and [vision] subtags also supported here
[/terrain_defaults]

Basically the same as before, just different tag-names and id= instead of type=.

[irydacea]

If you don't have anything to add then it looks ready to merge to me.

[irydacea]

Although, is it literally [resist_defaults]? I thought we were going with [resistance_defaults] since the definition counterpart is [resistance], not [resist].

[CelticMinstrel]

It's [resist_defaults], yes. I can change it if you want.

[irydacea]

zookeeper says it should be [resistance_defaults], so yes, please.