bugBattle for Wesnoth - Bugs: bug #17527, Feeding ability doubles when ghast...

Show feedback again

bug #17527: Feeding ability doubles when ghast and necrophage are in same scenario

Submitted by:  None
Submitted on:  Wed Jan 19 01:52:03 2011  
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Units
Status: FixedPrivacy: Public
Assigned to: Anonymissimus <anonymissimus>Originator Email: -unavailable-
Open/Closed: ClosedRelease: 1.9.3
Operating System: Windows Vista

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

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


(Jump to the original submission Jump to the original submission)

Mon Oct 10 19:03:49 2011, SVN revision 51440:

manually redo r51290, r51291 and 51292 (event handler bug)
(fix for bug #18695 and bug #17527)

(Browse SVN revision 51440)

Anonymissimus <anonymissimus>
Project MemberIn charge of this item.
Mon Sep 26 20:19:50 2011, comment #7:

Fixed by r51290.

Anonymissimus <anonymissimus>
Project MemberIn charge of this item.
Mon Sep 26 18:59:51 2011, comment #6:

This should be considered fixed, now that patch #2851 is committed.

Silas Brill <brilliand>
Project Member
Sun Jul 31 07:06:16 2011, comment #5:

Patch submitted #2851.

Thonsew <thonsew>
Project Member
Fri May 6 12:23:14 2011, comment #4:

-Why didn't you go for the wml fix suggested ?
-I think we should not mark things "in progress" unless they're assigned to someone.
-The C++ fix suggested made sense to me and should be feasible. It's a rather important feature though and should be discussed.

Anonymissimus <anonymissimus>
Project MemberIn charge of this item.
Fri May 6 07:46:29 2011, comment #3:

I'm marking this "In Progress" because the fix shouldn't be considered final.

Still, for most practical purposes it should now work correctly. The only exceptions are situations in which a unit dies in the hands of a feeder, is stored by an unrelated event and unstored back later and dies again in the hands of a feeder on the same turn number as previously (regardless of whether it's the same scenario or not); in those situations feeding would not activate at all for the second kill. This would be most likely to happen as a result of another WML-driven ability using such a store/unstore mechanism.

Lari Nieminen <zookeeper>
Project Member
Fri May 6 07:36:41 2011, SVN revision 49397:

Sort of fixed bug #17527 (Feeding ability doubles) WML-side. The fix doesn't work in every imaginable situation though (the exceptions should be very rare), so a proper engine-side fix is still wanted eventually.

(Browse SVN revision 49397)

Lari Nieminen <zookeeper>
Project Member
Wed Jan 26 01:20:54 2011, comment #1:

Hmm, I got logged as Anonymous. Just claiming this as my submission...

Silas Brill <brilliand>
Project Member
Wed Jan 19 01:52:03 2011, original submission:

There's a long-standing flaw in the Feeding ability (effectively described at http://wiki.wesnoth.org/EventWML#A_Trap_for_the_Unwary) that recently got upgraded to a core bug by the introduction of the Ghast. If more than one different unit type with the Feeding ability from core are included in the same scenario, the effective benefits of the ability are multiplied by the number of unit types that are involved.

The simplest fix is to add the unit type to the macro, i.e.:


The Ghast and Necrophage would then need to have their {ABILITY_FEEDING} line changed to {ABILITY_FEEDING (Ghast)} and {ABILITY_FEEDING (Necrophage), respectively.

Ideally, this problem should be dealt with by a C++ fix, that is, adding an "id" attribute to the [event] tag that works similarly to the "id" attribute in [object]. This would fix all cases of the "trap," not just the event-in-ability case.



(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 thonsew (Posted a comment)
  • -unavailable- added by anonymissimus (Posted a comment)
  • -unavailable- added by zookeeper (Posted a comment)
  • -unavailable- added by brilliand (Posted a comment)

    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



    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon Nov 7 17:45:24 2011anonymissimusOpen/ClosedOpen=>Closed
    Mon Oct 10 19:17:39 2011anonymissimusStatusNone=>Fixed
    Mon Oct 10 16:43:54 2011anonymissimusStatusFixed=>None
    Mon Sep 26 20:19:50 2011anonymissimusStatusIn Progress=>Fixed
    Sun Sep 25 01:26:17 2011anonymissimusAssigned toNone=>anonymissimus
    Fri May 6 07:46:29 2011zookeeperStatusNone=>In Progress
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup