bugBattle for Wesnoth - Bugs: bug #20719, next_scenario= not correctly read

Show feedback again

bug #20719: next_scenario= not correctly read

Submitted by:  Anonymissimus <anonymissimus>
Submitted on:  Sat Apr 6 19:01:50 2013  
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group:  None of the others
Status: Wont FixPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Release: 1.11.2-110-g90316ecOperating System: no matter

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)

Fri Aug 22 01:06:03 2014, comment #10:

I think we should add name= also to the things that get preserved from [scenario]. Especialy for the filenames of start-of-scenario saves this makes sense because i think it would be nice if those were saved before the scenario is generated.

Currently generate the scenario before we do the start-of-scenario save although we don't save the results from generation inside the save (except name).

Daniel <gfgtdf>
Project Member
Sun Aug 17 21:31:17 2014, comment #9:

Nothing to add, other than I wonder if 'won't fix' would be better due to the slight wml behavior changes.

SigurdFireDragon <sigurdfdragon>
Sat Aug 16 01:55:25 2014, comment #8:

still anything to say here? or should it be marked as 'invalid' ?

currently if scenario_generation=.. is used, it overwrites the whole [scenario] tag, only id= and [story] are preserved from the old [scenario].

Tue Jun 18 15:19:52 2013, comment #7:

I wouldn't mind just forgetting about this feature then. Showing it if and only if the map is not shrouded sounds okay.

Anonymissimus <anonymissimus>
Project Member
Thu Jun 13 17:04:35 2013, comment #6:

I did some checking on snapshot=.

In both 1.10 & 1.11, the minmap is not displayed for a save if shroud is on for the player, it is shown if it is off, regardless of the presence of the key.

In 1.10, snapshot=yes, causes buggy behavior, at least suppressing recall list from carrying over to next scenario, possibly more. snapshot=no seems to do nothing. Also, in 1.10 snapshot=yes only had effect in [scenario], not in [scenario][generator][settings] (just like next_scenario's 1.10 behavior)

In 1.11, snapshot=yes or no seems to have no effect anywhere.

I did a google search of wiki.wesnoth.org and snapshot= as a scenario key is not present.

This probably merit's it's own bug report.

SigurdFireDragon <sigurdfdragon>
Wed Jun 12 21:59:24 2013, comment #5:

Is it really not in the wiki ? Perhaps apply google on it. That key determines whether to show a "snapshot"of the map a scenario has before loading a savegame of that scenario. Perhaps the functionality is no longer present in current trunk due to a bug or whatever. The map snapshot was shown roughly in that area where (now, again) the leader image is shown. It must have had it at some spot since I know about it, I recall testing its effect.
So, snapshot=no did prevent showing this map snapshot, which is useful for shrouded and/or fogged scenarios.

Anonymissimus <anonymissimus>
Project Member
Wed Jun 12 19:55:19 2013, comment #4:

I agree with that.

I've looked, and it seems the only remaining key that could be moved is 'snapshot='. I can't figure out what this key does, & it's not in the wiki under [scenario]. Thus I'm unable to test where it is active. It's present in both places in TEG 10_Old_friends.cfg Any idea what it's for?

SigurdFireDragon <sigurdfdragon>
Thu Jun 6 16:57:14 2013, comment #3:

The original intent is pretty irrelevant I'd say. Important is what seems to be the best right now. And well, based on what wou write, we should perhaps declare the bug a feature and mention it in the wml syntax changes thread. (And move anything else left that makes sense also to [scenario][generator][settings] ?)

Anonymissimus <anonymissimus>
Project Member
Wed Jun 5 20:00:59 2013, comment #2:

After some investigating, I've found the following:
(summary & review)

1.10 reads only [scenario]next_scenario=
1.11 reads only [scenario][generator][settings]next_scenario=
Contradictions are ignored.

The commit that caused this change is:

Revision: 9d0ca55d9b46c77ef4a7a962641461313d0f943d
Author: Anja Keicher <therattigan@gmail.com>
Date: 8/20/2012 1:22:47 PM
Moved difficulty, current and next scenario info...

...to new carryover_info and game_data

The mainline campaigns having the key in both places is vague. Note that they also have name= in two places:
1.10 & 1.11 read only [scenario][generator][settings]name=

Any idea what was the original intent for where next_scenario should be in scenario's with scenario_generation=cave?

SigurdFireDragon <sigurdfdragon>
Sat Apr 6 20:14:23 2013, comment #1:

The problem can also be reproduced with HttT::17_Scepter_of_Fire by removing the [scenario][generator][settings]next_scenario= key/value. Thus, 1.11 apparently reads only this entry. It is redundant to [scenario]next_scenario=. What do we do if they contradict...? Did 1.10 read only [scenario]next_scenario= or both ? Both mainline campaign scenarios put it a both postions (the other scenario is SoF::4_Gathering_Materials.cfg).

Anonymissimus <anonymissimus>
Project Member
Sat Apr 6 19:01:50 2013, original submission:

The [scenario]next_scenario= information in the scenario 10_Old_friends.cfg in my campaign The_Earths_Gut @r18042 (checkout: http://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/The_Earths_Gut) is not correctly read and missing in the savefile. Thus, at the end of the scenario, the campaign ends (but should not). The exact same campaign version does not suffer from this problem under 1.10.6, so it must be a bug introduced since then. I'm pretty sure that it is a new engine bug. (The campaign targets both the development and stable BfW versions.)
The scenario in question uses the engine's underground generator, but a quick check with HttT::Sceptre of Fire shows that that scenario works.
The bug can be worked around by using [endlevel]next_scenario=, which is done in the next campaign revision (18043).
It also works to manipulate the savefile; I replaced at two places the value of next_scenario= from empty to the correct value 11t_Council and could use this fixed save to continue.
I didn't do any further investigation why it is exactly only this scenario where the problem is occurring. However, someone in my campaign's thread reported it as well.
I'm attaching a start-of-scenario save for this scenario. The first-turn autosave created from this start-of-scenario save should already show the missing values for next_scenario=, trying to jump to the next scenario with :n should fail.

Anonymissimus <anonymissimus>
Project Member


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

Attach File(s):

Attached Files
file #17688:  next_scenario.gz added by anonymissimus (22kB - application/x-gzip)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by vultraz (Updated the item)
  • -unavailable- added by gfgtdf (Posted a comment)
  • -unavailable- added by sigurdfdragon (Posted a comment)
  • -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 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Mar 19 00:26:32 2017vultrazOpen/ClosedOpen=>Closed
    Wed Feb 15 18:56:13 2017gfgtdfStatusNone=>Wont Fix
    Sat Apr 6 19:01:50 2013anonymissimusAttached File-=>Added next_scenario.gz, #17688
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup