Here's the rationale for these additions:
* There is so much focus on wmllint's role in conversion, that many people may not think of it as a validator also (I didn't). So often, stumped authors ask in the forums about problems that would have been fixed or pointed out if they'd run wmllint. I want to encourage awareness of wmllint as a validator.
* Folded a line to fit normal 80-width CLI.
* Help contained no mention of this rather redundant option.
* How many people don't realize that ESR's long introduction is there?
* Some users may not understand why they're being dumped back to wmllint's help.
I used "inconsistency" for the actual variable name, because "known" seems more likely to be accidentally reused.
I pondered whether to allow the scenario check to go forward, but decided to just make a clean break.
Note that this does not prevent any of the information-gathering for the consistency check, just the check itself.
Why would you want to use this option? Of course, you should run the consistency check at some point. But if you simply want to recheck if you've fixed all the bugs in your campaign, you might not want to have wmllint slog through data/core again.
According to the introduction, stringfreeze does *not* suppress the warning, and the code bears this out.
I wonder how often this option is actually used.
I realized that as it stood, my dictionary would linger, bad if wmllint were being run on multiple campaigns. A special unwho keyword, 'all', clears the dictionary.
Now that we see how the whopairs are recognized, we can see that the magic comment accepts a comma-separated list, for macros that deal with more than one character.
We also see that if it is necessary to remove a character who leaves the party, this can be done with another entry prefixed by double minuses.
The "recognize" magic comment only covers one scenario; but what about macros that are used in many scenarios?
This new magic comment creates dictionary pairs of macros with the characters they are associated with. If this is not yet clear, hopefully the following commits will show the full picture.
Rather than overwhelming users with verbiage, I will hide most of my explanation unless it's asked for. My message is still not particularly brief, but it's no longer insanely long.
groggy: The ifdef_stack = [None] assignment made wmllint crash upon nested
#if blocks. The following block of wml should suffice to let it crash. The
inner #endif deletes the data about encountered #ifs.
...
#ifver WESNOTH_VERSION >= 1.11.0
#ifhave ~add-ons/UMC_Music_Book_1/_main.cfg
[binary_path]
path=data/add-ons/UMC_Music_Book_1
[/binary_path]
#endif
#else
#ifhave ~add-ons/UMC_Music/_main.cfg
[binary_path]
path=data/add-ons/UMC_Music
[/binary_path]
#endif
#endif
...
Rather than automatically putting the soundpath in the first frame, we collect a list of begin= keys and their locations. When it's time to convert, we check to see if any of those begin times match with the sound time, and if so, put sound in that [frame]. Only if there is no match do we default to the first frame, and we log a message noting the lack of a match.
Some [sound] tags include a sound_miss key as well. To preserve this data, I created two new variables to capture the sound_miss= and time= values, and use them to fill out the SOUND:HIT_AND_MISS macro. Because the macro is inserted before [frame] instead of after, 'if soundpath' needs to be moved up before the insertion so that the macro ends up under [attack_anim], rather than in the middle of [attack].
It's probably obvious what I tried to do. Unfortunately, only the first string works.
I also added another "and not" condition, to keep the same file from getting multiple entries in is_main.
After my last change, I noticed a puzzling failure by wmllint to convert a weapon special. This special was among some attributes that followed the [frame] sequence. It seems that Python does not wait for the earlier code block to complete before running the new one, and those lines aren't passed through the new block because they've been deleted and stashed in 'postframe'. When they're spewed back out, the new block has already passed those lines by.
I was relieved to find that this was not an issue introduced by my change, but an existing one. When I ran the original wmllint on the file, I found that the special= line got deleted, without being replaced by the [special] tags and macro. The latter is supposed to appear when wmllint hits the [/attack] tag, but never triggers because [/attack] has been changed to [/attack_anim].
Moving this code block up, so that abilities and specials are transformed before the [frame] lift (and 'postframe' stash), appeared to fix the problem. Hopefully, it won't cause a new on to show up.
This code block was actually producing some horrendous output, because key values were not reset to defaults at the closing [/attack] tag, even though many units have more than one attack. Also, the conversion was done when the first [frame] tag was encountered, although most authors put the [sound] block after [frame]s. So, what would typically happen is this:
* The first attack would be converted, usually without a soundpath. If there were any attributes after the [frame] sequence, the result would be non-functional, as the comment introducing this wmllint block warned (and wmllint would crash with an assertion error if "name=" happened to be one of them).
* Subsequent attacks would be converted, inheriting the sound and [attack_filter] from the soundpath and attackname of the *first* attack.
To fix these issues, I did the following:
* In order to do the conversion at a later stage, after the soundpath would normally have been picked up, the variable 'converting' was changed from a 0/1 value to a line index position.
* This enables the opportunity to move post-[frame] lines, for which purpose the new variables in_frame and postframe are created. When encountered, these lines are deleted and appended to postframe.
* When we get to [/attack], we still look to see if we are converting. If so, we go ahead with the replacement of lines[i], before the index position gets changed. Then we carry out the conversion that was originally carried out at the first [frame], using lines[converting] to do it at the same place.
* The lines in postframe are fed back in reverse order before the new closing [/attack] tag.
* Values are cleared to defaults, ready for the next [attack].
* It is no longer true that the frame sequence has to go last in [attack], so that part of the comment can be deleted.
First, the newline is added to "description = " rather than "new_line = ". But description was only changed if it didn't begin with a quotemark, meaning that those that *did* start with a quote weren't getting a newline.
Second, new_line was supposed to inherit indentation through "leader(syntactic)", but the line had already been stripped before "syntactic", in "fields = ".
