bugBattle for Wesnoth - Bugs: bug #18713, Creating a WML event handler...

Show feedback again

bug #18713: Creating a WML event handler inside another and firing it immediately afterwards does not work

Submitted by:  Ignacio R. Morelle <shadowmaster>
Submitted on:  Thu Sep 22 03:47:00 2011  
Category: Feature RequestSeverity: 3 - Normal
Priority: 5 - NormalItem Group: WML
Status: FixedPrivacy: Public
Assigned to: J Tyne <jamit>Open/Closed: Closed
Release: 1.8.6, 1.9.8, 1.9.9Operating System: Debian 6.0

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

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


Sun Nov 3 19:59:02 2013, comment #4:

Fixed: http://git.io/9Q8TCg

J Tyne <jamit>
Project MemberIn charge of this item.
Mon Sep 26 13:28:37 2011, comment #3:

Changing to feature request, since the behavior is and was intended.
Added events (also ones that may be added via [unit_type][event]
and menu items) are not active until the current event call stack has finished.
Another workaround which is supposed to work (untested) is this though:
since name=foobar is created and fired in different call stacks then.
It is afaik also guaranteed that the 2 events of the same type are executed directly after each other and in the order in which they appear in the scenario.

Anonymissimus <anonymissimus>
Project Member
Mon Sep 26 13:17:16 2011, SVN revision 51290:

refactored when (and when not) buffering of added events is done (fix for bug #18695 and bug #18737)

The reason for the bug was that buffering was acivated and deacticated at wrong times.
Events added (or removed) during the current event call stack do not have effect until the base
event has run out. The code previously to adding the [event]id= feature
behaved this way and it is now (again) this way. Although it's still
not exactly clear to me why this buffering is done, adding event
handlers which were just added during the current call stack already to
the active ones (FR bug #18713) would require modifying the array of active
handlers withint the same loop where we are iterating over it, which
is always a problematic thing, and this in an area where every mistake
quickly results in fatal wml engine bugs...

This should be subject to further testing with scenarios featuring
complicated event structure envolving custom events, [fire_event]s,
event ids and removing of events.

The reason for me not being able to reproduce with my testcase was that
I didn't have shroud enabled. ;)
The reason for me being able to reproduce only sometimes was (I think) that
originally, buffering was initialized with random data so it sometimes
delayed the preload event and sometimes it worked correctly.

(Browse SVN revision 51290)

Anonymissimus <anonymissimus>
Project Member
Thu Sep 22 20:37:30 2011, comment #1:

Confirmed that this also affects 1.8.

Ignacio R. Morelle <shadowmaster>
Project Administrator
Thu Sep 22 03:47:00 2011, original submission:

In the mainline test scenario, the following code addition, which should result in an empty map with no units after all other prestart event handlers have been processed, will not work as expected in practice, as the handler for "foobar" appears to not be effective until the parent handler that introduces it is finished:

The following will work:

So will this, by firing the "foobar" event from a different, later handler:

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):

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 jamit (Updated the item)
  • -unavailable- added by anonymissimus (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 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Nov 17 18:06:17 2013jamitOpen/ClosedOpen=>Closed
    Sun Nov 3 19:59:02 2013jamitStatusNone=>Fixed
    Fri Jul 19 02:39:44 2013jamitAssigned toNone=>jamit
    Mon Sep 26 13:28:37 2011anonymissimusCategoryBug=>Feature Request
    Thu Sep 22 20:37:30 2011shadowmasterRelease1.9.8, 1.9.9=>1.8.6, 1.9.8, 1.9.9
    Thu Sep 22 20:33:34 2011shadowmasterRelease1.9.9=>1.9.8, 1.9.9
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup