bugBattle for Wesnoth - Bugs: bug #18695, lua files not correctly re-read on...

Show feedback again

bug #18695: lua files not correctly re-read on "back to turn 1"

Submitted by:  Anonymissimus <anonymissimus>
Submitted on:  Mon Sep 19 17:59:12 2011  
Category: BugSeverity: 5 - Blocker
Priority: 5 - NormalItem Group:  None of the others
Status: FixedPrivacy: Public
Assigned to: Anonymissimus <anonymissimus>Open/Closed: Closed
Release: 1.9.9, trunk r51228Operating System: win xp

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 Oct 10 13:11:48 2011, comment #19:

This needs re-fixing after token changes revert.

Anonymissimus <anonymissimus>
Project MemberIn charge of this item.
Mon Sep 26 13:19:53 2011, comment #18:

Also note that the whole thing had nothing to do with token stuff.

Anonymissimus <anonymissimus>
Project MemberIn charge of this item.
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 MemberIn charge of this item.
Sat Sep 24 15:50:45 2011, comment #16:

thonsew, I guess you don't mind, I want to give this a try.

Anonymissimus <anonymissimus>
Project MemberIn charge of this item.
Sat Sep 24 15:14:46 2011, comment #15:

Yes, after several iterations it seems obvious to me that r50853 is reponsible for this problem.

Anonymissimus <anonymissimus>
Project MemberIn charge of this item.
Fri Sep 23 21:13:35 2011, comment #14:

Sigurd: It is probably sufficient if you, for instance, create a patch from the changes I made in r50894 and apply that to an earlier revision. That should work up until the point when the lib dependencies were edited the last time before (when you should get conflicts).

Anonymissimus <anonymissimus>
Project MemberIn charge of this item.
Fri Sep 23 19:06:13 2011, comment #13:

I think I've been getting the same preload not always working issue.

The following always produces a bug for me on trunk or 1.9.9:

I start Wesnoth, go to MP, lauch a map with my add-on era for Custom Campaign, win the map (can just be by debug spawning an Ancient Lich next to the enemy and shooting him.)
Then, going back into MP, I go and launch the Custom Campaign map, it throws error "attempt to index global helper, a nil value" indicating that my preload event did not work.

If I then quit and reload the map, it will start working again.

I've tested all the way back to r50894 and it is still present.
Wanted to test if r50853 (necrophage/ghast feeding patch) was the cause, but because of build requirement/dependicies changes since then, my current setup can't get that revision to compile.

SigurdFireDragon <sigurdthedragon>
Fri Sep 23 14:16:17 2011, comment #12:

After lots of trials, strange enough, it seems that I can reproduce this bug only sometimes and only with Settlers of Wesnoth in local or networked mp, not with a minimized testcase I tried to create. I suspect that the cache may be involved. And yes, sometimes when I could reproduce it was with a pre-token-stuff binary.

Anonymissimus <anonymissimus>
Project MemberIn charge of this item.
Fri Sep 23 01:14:16 2011, comment #11:

Sorry for the spam, but gna.org's stylesheet makes the command appear truncated in my previous comment (it actually isn't; it's just a missing horizontal scrollbar):

svn co -r 10639 https://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/After_the_Storm

Ignacio R. Morelle <shadowmaster>
Project Administrator
Fri Sep 23 01:12:32 2011, comment #10:

My test case is my campaign After the Storm, which can be found in wesnoth-umc-dev. Assuming I didn't forget my subversion-fu, the following command should check it out at the revision before I patched a workaround on it:

The scenario in question can be accessed in debug mode with :cl; pick 09_The_Triad_part_2, and start moving units north until a sighted event triggers or you reach a tile with y coordinate < 32. The exact results of the sequence should change depending on whether you reloaded a previous turn save of the scenario or not; when the tag is recognized, skeletons and ghosts under the player's control will spawn during the dialogue.

Ignacio R. Morelle <shadowmaster>
Project Administrator
Fri Sep 23 00:46:08 2011, comment #9:

I can attest to this bug occurring in a similar fashion with Wesnoth 1.9.9; my custom WML tag [s9_area_spawns] implemented in a specific scenario as follows becomes invalid after reloading from any turn save/autosave.


The tag implementation:

An example use case:

Ignacio R. Morelle <shadowmaster>
Project Administrator
Thu Sep 22 22:06:54 2011, comment #8:

I was able to duplicate this bug on 1.9.9. Can you also duplicate it on 1.9.9? That would mean it is not due to my recent changes.

Thonsew <thonsew>
Project Member
Wed Sep 21 21:53:12 2011, comment #7:

I understand your frustration and I didn't intend to break so much.
I have downloaded your add-on and an currently working on the reload to turn 1 bug.

Thonsew <thonsew>
Project Member
Tue Sep 20 21:34:51 2011, comment #6:

Thanks for the long series of reports and tracking it down to the [event] tag.
As you can see in the patch previously the lua code wasn't shutting the t_token into lua at all. I have fixed that now.
I will still checkout your addon as it is sophisticated example of correct lua usage.


Thonsew <thonsew>
Project Member
Tue Sep 20 21:21:22 2011, SVN revision 51240:

Added support for t_token to lua code.
1. Created a t_token metatable along with support code for indexing, garbage collection, tostring, tonumber, comparison and concatenation.
2. Adjusted string comparison and lookup in lua code to work with either t_token or string.
This addresses in part bug #18631, bug #18695. Before this lua was treating all t_token as either tstrings or strings.

(Browse SVN revision 51240)

Thonsew <thonsew>
Project Member
Tue Sep 20 00:00:05 2011, comment #4:

Ah, yes.
The [event]name=peload first_time_only=no is not fired when loading a savegame (though it of course should). This explains all of the symptoms I reported in this bug and should be reproducible pretty idependently from this addon of mine.

Anonymissimus <anonymissimus>
Project MemberIn charge of this item.
Mon Sep 19 22:25:09 2011, comment #3:

Same happens when reloading a save, without restarting BfW.

Anonymissimus <anonymissimus>
Project MemberIn charge of this item.
Mon Sep 19 22:11:29 2011, comment #2:

Also, when I restart the same game without restarting BfW, I get very similar error messages about my custom tags not being supported although the definitely should be.

Anonymissimus <anonymissimus>
Project MemberIn charge of this item.
Mon Sep 19 18:02:29 2011, comment #1:

typo in the url:

Anonymissimus <anonymissimus>
Project MemberIn charge of this item.
Mon Sep 19 17:59:12 2011, original submission:

reproduced with "Settlers of Wesnoth", checkout url:

1. Start a local mp game.
2. Click a few times on "turn done".
3. Click "back to turn 1" from the menu.
4. Click "turn done" once.
Lots of "attempt to call global <some function from Settlers_of_Wesnoth/lua/main.lua> (a nil value)" pop up, despite they should have been correctly reloaded and compiled by the scenario code, so this looks like some reinitialization problem:
I know for sure it worked before the "token" stuff. Also, all bugs found with this addon are likely to be engine bugs.

Anonymissimus <anonymissimus>
Project MemberIn charge of this item.


(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 sigurdthedragon (Posted a comment)
  • -unavailable- added by shadowmaster (Posted a comment)
  • -unavailable- added by thonsew (Updated the item)
  • -unavailable- added by anonymissimus (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 11 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon Nov 7 17:52:30 2011anonymissimusOpen/ClosedOpen=>Closed
    Mon Oct 10 19:17:25 2011anonymissimusStatusNone=>Fixed
    Mon Oct 10 14:55:43 2011anonymissimusSeverity4 - Important=>5 - Blocker
    Mon Oct 10 13:11:48 2011anonymissimusStatusFixed=>None
    Mon Sep 26 13:19:53 2011anonymissimusStatusNone=>Fixed
    Sat Sep 24 15:50:45 2011anonymissimusStatusNeed Info=>None
      Assigned tothonsew=>anonymissimus
    Fri Sep 23 00:46:08 2011shadowmasterReleasetrunk r51228=>1.9.9, trunk r51228
    Thu Sep 22 22:06:54 2011thonsewStatusIn Progress=>Need Info
    Tue Sep 20 19:34:51 2011thonsewStatusNone=>In Progress
    Mon Sep 19 18:02:29 2011anonymissimusAssigned toNone=>thonsew
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup