Battle for Wesnoth - Bugs: bug #18695, lua files not correctly re-read on... [Gna!]

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

Group

Main
- Main
- View Members
- Search
Homepage
Docs
- Browse
- Submit
- Edit
- Digest
- Export
- Search
Support
- Browse
- Reset to all open ones
- Submit
- Digest
- Export
- View Statistics
- Search
Mailing Lists
Source Code
- Use Subversion
- Browse Sources Repository
Bugs
- Browse
- Reset to all open ones
- Submit
- Digest
- Export
- View Statistics
- Search
Tasks
- Browse
- Reset to all open ones
- Submit
- Digest
- Export
- View Statistics
- Search
Patches
- Browse
- Reset to all open ones
- Submit
- Digest
- Export
- View Statistics
- Search
News
- Browse
- Atom Feed
- Submit
- Manage

Show feedback again

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

Submitted by:	Anonymissimus <anonymissimus>
Submitted on:	Mon 19 Sep 2011 05:59:12 PM UTC

Category:	Bug	Severity:	5 - Blocker
Priority:	5 - Normal	Item Group:	None of the others
Status:	Fixed	Privacy:	Public
Assigned to:	Anonymissimus <anonymissimus>	Open/Closed:	Closed
Release:	1.9.9, trunk r51228	Operating System:	win xp

Add a New Comment (Rich Markup):

You are not logged in

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

( Jump to the original submission)

Mon 10 Oct 2011 07:03:49 PM UTC, 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>
Mon 10 Oct 2011 01:11:48 PM UTC, comment #19: This needs re-fixing after token changes revert.	Anonymissimus <anonymissimus>
Mon 26 Sep 2011 01:19:53 PM UTC, comment #18: Also note that the whole thing had nothing to do with token stuff.	Anonymissimus <anonymissimus>
Mon 26 Sep 2011 01:17:16 PM UTC, 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>
Sat 24 Sep 2011 03:50:45 PM UTC, comment #16: thonsew, I guess you don't mind, I want to give this a try.	Anonymissimus <anonymissimus>
Sat 24 Sep 2011 03:14:46 PM UTC, comment #15: Yes, after several iterations it seems obvious to me that r50853 is reponsible for this problem.	Anonymissimus <anonymissimus>
Fri 23 Sep 2011 09:13:35 PM UTC, 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>
Fri 23 Sep 2011 07:06:13 PM UTC, 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 23 Sep 2011 02:16:17 PM UTC, 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>
Fri 23 Sep 2011 01:14:16 AM UTC, 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>
Fri 23 Sep 2011 01:12:32 AM UTC, 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>
Fri 23 Sep 2011 12:46:08 AM UTC, 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. stderr: The tag implementation: [event] name=preload first_time_only=no [lua] code = << function spawn_loyal_player_unit(type_id, loc_x, loc_y) -- Inelegant, I know, but put_unit() invokes a code path -- where animate= doesn't have a meaning. wesnoth.fire("unit", { x = loc_x, y = loc_y, side = 1, type = type_id, upkeep = "loyal", animate = true, }) end function wesnoth.wml_actions.s9_area_spawns(cfg) local num_skels = cfg.skeletons or 1 local num_ghosts = cfg.ghosts or 1 local locs = wesnoth.get_locations(cfg) for i = 1, num_skels do if #locs == 0 then return end local r = safe_random(string.format("1..%d", #locs)) local x, y = locs[r][1], locs[r][2] spawn_loyal_player_unit("Skeleton", x, y) table.remove(locs, r) end for i = 1, num_ghosts do if #locs == 0 then return end local r = safe_random(string.format("1..%d", #locs)) local x, y = locs[r][1], locs[r][2] spawn_loyal_player_unit("Ghost", x, y) table.remove(locs, r) end end >> [/lua] [/event] An example use case: [s9_area_spawns] x=34-41 y=29-31 [not] [filter] [/filter] [/not] [not] terrain=Q,X,^X [/not] {QUANTITY skeletons 3 2 2} {QUANTITY ghosts 1 1 1} [/s9_area_spawns]	Ignacio R. Morelle <shadowmaster>
Thu 22 Sep 2011 10:06:54 PM UTC, comment #8: Anonymissimus, 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>
Wed 21 Sep 2011 09:53:12 PM UTC, comment #7: Anonymissimus, 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>
Tue 20 Sep 2011 09:34:51 PM UTC, comment #6: Anonymissimus, 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. Thanks.	Thonsew <thonsew>
Tue 20 Sep 2011 09:21:22 PM UTC, 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>
Tue 20 Sep 2011 12:00:05 AM UTC, 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>
Mon 19 Sep 2011 10:25:09 PM UTC, comment #3: Same happens when reloading a save, without restarting BfW.	Anonymissimus <anonymissimus>
Mon 19 Sep 2011 10:11:29 PM UTC, 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>
Mon 19 Sep 2011 06:02:29 PM UTC, comment #1: typo in the url: http://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/Settlers_of_Wesnoth	Anonymissimus <anonymissimus>
Mon 19 Sep 2011 05:59:12 PM UTC, original submission: reproduced with "Settlers of Wesnoth", checkout url: htts://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/Settlers_of_Wesnoth 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: [event] name=preload first_time_only=no [lua] code=<< wesnoth.dofile "~add-ons/Settlers_of_Wesnoth/lua/main.lua" >> [/lua] [/event] 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>

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

Attach File(s):


Comment:

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.

Please enter the title of George Orwell's famous dystopian book (it's a date):

Follow 11 latest changes.

Date	Changed By	Updated Field	Previous Value	Replaced By
Mon 07 Nov 2011 05:52:30 PM UTC	anonymissimus	Open/Closed	Open	Closed
Mon 10 Oct 2011 07:17:25 PM UTC	anonymissimus	Status	None	Fixed
Mon 10 Oct 2011 02:55:43 PM UTC	anonymissimus	Severity	4 - Important	5 - Blocker
Mon 10 Oct 2011 01:11:48 PM UTC	anonymissimus	Status	Fixed	None
Mon 26 Sep 2011 01:19:53 PM UTC	anonymissimus	Status	None	Fixed
Sat 24 Sep 2011 03:50:45 PM UTC	anonymissimus	Status	Need Info	None
		Assigned to	thonsew	anonymissimus
Fri 23 Sep 2011 12:46:08 AM UTC	shadowmaster	Release	trunk r51228	1.9.9, trunk r51228
Thu 22 Sep 2011 10:06:54 PM UTC	thonsew	Status	In Progress	Need Info
Tue 20 Sep 2011 07:34:51 PM UTC	thonsew	Status	None	In Progress
Mon 19 Sep 2011 06:02:29 PM UTC	anonymissimus	Assigned to	None	thonsew

Show feedback again