bugBattle for Wesnoth - Bugs: bug #20659, error message when mother unit,...

Show feedback again

bug #20659: error message when mother unit, child unit and _initial.cfg in same folder

Submitted by:  Anonymissimus <anonymissimus>
Submitted on:  Tue Mar 26 23:02:37 2013  
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group:  None of the others
Status: InvalidPrivacy: Public
Assigned to: J Tyne <jamit>Open/Closed: Closed
Release: 1.11.2+svn@r1.11.2+svn@r56594Operating 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.


Mon Jul 1 19:11:19 2013, comment #5:

All right. So there's some stuff to do for me in my addon and nothing more for you I conclude. The bug can be flagged invalid.

Anonymissimus <anonymissimus>
Project Member
Mon Jul 1 05:40:15 2013, comment #4:

OK, I think I have this figured out.

First off, you can get this message without [base_unit]; all you need is an _initial.cfg file with content of the form {./Master_of_Alchemy.cfg}. As far as I can tell, this is intentional. At least, I see no indication of an attempt to prevent files from being included twice. (I don't see how something else is being suggested in the documentation, so I don't know what -- if anything -- to change there.) If there is no _main.cfg, then the files in the directory are listed, _initial.cfg is moved to the front of the list, _final.cfg is moved to the end, then all of those files are processed in order, regardless of what is in each file (barring a fatal syntax error, of course).

So why were no errors logged in 1.10? I added the warning in r56093 (between 1.11.1 and 1.11.2). The duplicates were merely silently ignored before.

The revision that made the _initial.cfg hack unnecessary was r56092, also between 1.11.1 and 1.11.2. So 1.11.1 and lower need _initial.cfg, while 1.11.2 and higher do not.

You might want to review your remaining _initial.cfg's -- if any are still including files in the same directory of _initial.cfg, then those files are being included twice. (You might want to move those files into a subdirectory so the normal processing skips them.)

J Tyne <jamit>
Project MemberIn charge of this item.
Tue Apr 2 15:34:20 2013, comment #3:

If the reason why I had to put that explicit loading in there was a bug in the first place, I don't mind removing it. However, I should know some BfW version from when on it has been save to guard the explicit loading by #ifver, since 1.10.x probably still has that error. (same addon version for stable and dev BfW versions)

Anonymissimus <anonymissimus>
Project Member
Tue Apr 2 04:49:35 2013, comment #2:

One part of this I can address off the top of head: The files are read in alphabetical order, but the [base_unit] tag is not processed until after all files have been read. (The processing used to depend somewhat on the order the files had been read, but that processing was still after everything had been read. Really no reason to require the base unit to be defined first -- much like scenarios do not need to be defined before a campaign can declare which scenario is first.)

It will still be some time before I get to sit down and analyze what is happening (for this and the other bug reports). I'll also look into why I don't see a changelog entry for the more robust [base_unit] handling. ("Oops, I forgot"?)

J Tyne <jamit>
Project MemberIn charge of this item.
Tue Mar 26 23:15:33 2013, comment #1:

The "Master of Alchemy" is the "mother unit"/base unit in my previous post, the child unit it tries to base upon that is "Aiglathing Level Three" in this case, the folder in question is /units/dwarves/

Anonymissimus <anonymissimus>
Project Member
Tue Mar 26 23:02:37 2013, original submission:

Since some change, error messages of the form
20130326 23:35:23 error config: Multiple [unit_type]s with id=Master of Alchemy encountered
show up when loading units under the following conditions:
-A cfg file defining a unit using [base_unit], and the unit it is based upon, are in the same folder.
-An _initial.cfg file is in this folder as well, with content of the form

The purpose of this _intial.cfg file was/is to ensure the mother unit has already been read at the point when the child unit is read, so that the reference is resolved. Probably an error did occur at some spot otherwise. This error no longer happens if I remove the _initial.cfg. (Which is bit strange, since IIRC the files are read in alphabetical order.)
As I understand the documentation of _initial.cfg (http://wiki.wesnoth.org/PreprocessorRef), it should work so that the referenced files aren't read a second time.
The behavior can be observed with my add-on @revision 17925, checkout: http://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/The_Earths_Gut
Just start anew into the first scenario and look in stderr.
So some change to base_unit resolving seems bad, or _initial.cfg doesn't work like it should.

Anonymissimus <anonymissimus>
Project Member


(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 (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 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat Jul 6 00:31:28 2013jamitStatusNone=>Invalid
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup