bugBattle for Wesnoth - Bugs: bug #20604, [object][effect]apply_to=variation...

Show feedback again

bug #20604: [object][effect]apply_to=variation only works correctly once for each unit

Submitted by:  Ignacio R. Morelle <shadowmaster>
Submitted on:  Sat Mar 9 08:49:45 2013  
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Units
Status: FixedPrivacy: Public
Assigned to: J Tyne <jamit>Open/Closed: Closed
Release: 1.11.1+svn r56459Operating System: Debian wheezy

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

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


Sat Mar 9 21:21:41 2013, comment #3:

Guess I overlooked this case or thought it was not working before my revisions. (There are some other corner cases that were not handled well before I started making changes. I have not fixed them yet because a real fix takes more significant changes.)

J Tyne <jamit>
Project MemberIn charge of this item.
Sat Mar 9 21:17:17 2013, SVN revision 56464:

Find the base unit type before applying a variation [effect].

Fixes bug #20604.

(Browse SVN revision 56464)

J Tyne <jamit>
Project MemberIn charge of this item.
Sat Mar 9 08:52:12 2013, comment #1:

Note: the commit I had to skip while bisecting is r56067. It seems irrelevant for the bug, so r56062 is probably the correct culprit.

Ignacio R. Morelle <shadowmaster>
Project Administrator
Sat Mar 9 08:49:45 2013, original submission:

In current Wesnoth trunk r56459, [object][effect]apply_to=variation only works correctly once for each affected unit.

This is bug most notably results in the unit's baseframe not being updated anymore after the first variation-affecting object is applied.

I am attaching a WML snippet with example code that creates a unit with a given variation and applies objects to it in succession to transform it to various variations accepted by its unit type (in this case, a Walking Corpse).

This works mostly fine [1] on Wesnoth 1.11.1 and earlier (including 1.10.x), but on current trunk the unit remains with the baseframe and stats for the first variation applied via [object]. If the unit is initially spawned with a variation set with the variation= attribute under [unit] directly, it will get stuck with that variation's baseframe and stats instead and ignore any subsequent variation-affecting objects.

Using git bisect to test various builds, I found revision 56062 (by jamit) to be the culprit, but I am not completely sure what the changes involved are, and probably won't investigate the issue any further since the unit/unit_type code has always been too dense for my taste. I am not completely sure whether this is the correct commit either, since I had to skip one commit that wouldn't compile at all while bisecting.

[1] NOTE: on all aforementioned versions there is a glitch with the unit's portrait in [message] actions. This is not relevant to this bug report and I will probably file a separate bug later.

Ignacio R. Morelle <shadowmaster>
Project Administrator


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

Attach File(s):

Attached Files
file #17413:  variation_object_sequence_test.cfg added by shadowmaster (1kB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by jamit (Posted a comment)
  • -unavailable- added by shadowmaster (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



    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat Mar 9 21:21:41 2013jamitStatusNone=>Fixed
    Sat Mar 9 08:49:45 2013shadowmasterAttached File-=>Added variation_object_sequence_test.cfg, #17413
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup