bugBattle for Wesnoth - Bugs: bug #21619, A better behavior for...

Show feedback again

bug #21619: A better behavior for defense_weight

Submitted by:  Eli Dupree <elvish_pillager>
Submitted on:  Sat Feb 8 16:36:32 2014  
Category: Feature RequestSeverity: 1 - Wish
Priority: 5 - NormalItem Group: WML
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Release: 1.11.8+devOperating System: Debian Linux

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


Sat Feb 22 04:55:34 2014, comment #1:

As a side note, I don't think the defense_weight of the Giant Scorpion is currently functioning at all. (And I don't see anything wrong with that - the preference for the poisoning attack functions as it should, and making it use the sting against zombies and such would be odd.)

Eli Dupree <elvish_pillager>
Sat Feb 8 16:36:32 2014, original submission:

Zero/nonzero defense_weight to determine whether an attack can be used on defense is fine, although now also doable using [disable]. This request is not about that; this request concerns the differences between different nonzero values (e.g. 1 vs 2).

By my reading of actions/attack.cpp 592-610, defense_weight has the following behavior for two attacks A and B:

If A comes before B, has higher defense_weight, and does more (average_damage * defense_weight) than B, then B will not be selected even if B has higher chance to kill.

I believe the "if A comes before B" part is a bug: notice how the first condition on line 605 is always false because of its ordering with 602. Without the bug, the behavior would be:

If A has the highest defense_weight among all attacks, then no other attack with lower (average_damage * defense_weight) will be selected.

This violates the "independence of irrelevant alternatives" principle. Imagine a unit with two attacks:

A: 2-5 melee, 1 defense_weight
B: 8-2 melee, 1 defense_weight

and is being attacked in melee by a unit with 2 HP. Obviously, it will pick A. But now suppose it has a third attack

C: 6-1 melee, 2 defense_weight

The "simple_rating" for this attack exceeds A, so A cannot now be chosen. However, it is less than B, so B is chosen! This clearly isn't what it should be doing.

So what should it be doing? Here are some use cases:
1) The sole mainline usage: Giant scorpions. For some reason, it should defend with its stinger even when the game considers that less advantageous, but not always. I'm not sure this is a desirable situation to use defense_weight - I recommend that better_combat should simply value poisoning more highly. If there is a thematic reason that it should favor the stinger even against units that can't be poisoned, I recommend the other attack be disabled completely on defense.
2) A UMC unit that has an [event]-based attack special that the game doesn't consider. Most attack specials are less important than killing the unit, and most such attack specials don't depend on the damage done. On the other hand, there are attack specials that depend on the damage done (e.g. "take the same amount of damage again in two turns"), and there are attack specials that would be desirable only in the case of a kill (e.g. Plague). As an add-on writer, I'd want to indicate any of those separately.

I recommend the following:
1) Make the code more consistent by replacing better_combat() with a single weight function that takes one attack. It would return the difference in CTK-CTBK times a large factor, plus difference in average-damage-plus-poison weighted by maxHP (so that that summand doesn't gain more influence just because the units have higher stats in general). (Side note: A fire dragon attacked by a goblin spearman currently values its own chance to die equally with its attacker's chance to die. CTK values should probably be multiplied by the unit value function.) Then better_combat() is simply "Which attack's weight is higher?"
2) For the new defense weight behavior to modify that weight function.
3) Since [disable] exists now in 1.11, for the defense_weight key and the attack_weight key to be deprecated in favor of a second attack special: [modify_weight].

As an attack special, the user could indicate whether it applies on offense (mostly a cosmetic effect), defense (a mechanical effect), or both.

It would have the following keys:
add_damage = number or lua function (attack acts as if it deals this much extra damage when choosing attacks)
multiply_damage = number or lua function (damage is multiplied by this much when choosing attacks)
multiply_kills = number or lua function (multiply chance to kill by this much when choosing attacks)

Any non-numerical keys would be interpreted as lua functions in the global namespace that take two units (the unit with the weapon and its opponent) and return a number.

Eli Dupree <elvish_pillager>


(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by elvish_pillager (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    No Changes Have Been Made to This Item
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup