Abilities are sometimes checked at locations other than a unit's
current location. If the checked location is adjacent to the unit's
location, then (before this fix) the unit could affect itself as an
adjacent unit.
Lite has the same dimensions of the H18 menu button, which is unused
and moved to attic. Since all uses of lite were menus, I reassigned
them to use the current H20 menu image.
When pangoize detects an old-style color spec, it prints a message that it needs a "manual fix." Unfortunately, the old markup used decimal values while pango uses hexadecimal, and authors were left to do the conversion themselves.
My modification not only does the hex conversion, it provides pango code ready to copy and paste into the line.
Going over this:
rgb =: First step is to turn the original regular expression into a regex object. The one change is that later on, wmllint turns non-pango "<" and ">" into "</>", so I have the regex match those too, in case we are dealing with a file that has already been through wmllint before.
if rgb: Having turned the original search into a regex object, we are ready for an if test again.
r, g, b =: We need Python to recognize these strings as numbers.
if > 255: At least one old campaign ("A Sortie") has color specs that include values over 255. Given the impossibility of deciphering what color the author may have intended, I think the proper thing to do is to print an error pointing to the problem.
else: This, of course, is the normal case.
hexed: Here we convert our numbers to hexadecimal, and back into a string. Because numbers up to 15 will only have one hex digit and we need two, we will leave a "0" when we remove the "0x" prefix; then we take the last two characters, lopping off the zero from the numbers greater than 15 that already have two digits.
print: The new error message. With the regex object, we can cite the color spec specifically, not just refer to it as being "in line". And at the end is pango code, ready to copy and paste.
The misguided authors who put userdata/ in their paths cause problems not just for non-Windows users, but fellow Windows users who chose not to put userdata in the install directory. This error can be removed by an approach similar to that just used to purge backslashes:
* if 'userdata': A basic filter to cut down the number of lines being run through complicated regex speeds up performance.
* while: It is possible, though rare, for a line to contain more than one path with userdata. Points about the regex: a) We continue to use precomment, though it would be well to correct commented-out old paths also, lest they mislead any more UMC writers. b) In case you're wondering why I made one 'data/' string optional, there's a set of add-ons in 1.4 that use "userdata/campaigns" instead of "userdata/data/campaigns". c) The '[ac]' at the end is something of an artifact of the time before I excluded comments, but it provides another safety measure insuring that the string is actually a value.
* regex object: This splits precomment into groups. Notes: a) Some authors begin with an unnecessary "../", might as well get rid of it as well. (As far as I can tell, this prefix has no effect anywhere I've seen it used, but I'd want to be positive that it ALWAYS does nothing before having wmllint replace it everywhere.) b) The first two groups have been made non-capturing; we will not need to refer to them. c) For reporting to stdout, group(1) is extended to the next '/', though this part of the match is optional, to insure that there's no way to get trapped in a while loop.
* precomment: Here, we reconstruct precomment based on the regex object, except we simply drop what's outside group(1).
* print: In case designers don't get the point from seeing the elimination logged in stdout, I include an all-caps admonition against "userdata/". This is a really irritating bug.
* This code was inserted before the reconstruction of lines[i] from precomment and comment.
The task is to replace Windows backslashes in paths, without indiscriminately replacing backslashes in legitimate use as escapes (or bridge terrain).
Breaking this down:
* "no-syntax-rewrite": I don't think this is really necessary, but I will follow the practice of the hack_syntax section.
* if lines[i].lstrip().startswith("#"): Excludes lines that are only comments or defines.
* precomment: Originally, I simply excluded "#" during the while statement, but I realized that this could wrongly mistake a Pango color code (or old-style markup for green) as a comment. I now look for whitespace before "#", and rewrote this section to operate on precomment rather than the whole line.
* comment: Simply going with the second field would exclude the separator itself, so I use len.
* if '\\': Technically, this code worked going straight to the while statement, but running every line through the complicated regex made it sluggish. Faster to make sure the line meets a simple filter first.
* while: It is possible, though very uncommon, that a line could contain more than one file path. Looking at the regex test: a) Match the backslash itself, then be on the lookout for a character used to set apart a file path from other text. By excluding these, we ensure that there is an unbroken chain from the backslash to the file extension. b) Then we have a list of file extensions, bracketed on the left by a period and the right by \b, to make sure they do not coincidentally match a string. These are the file types that might be referenced by a value (for instance, translation files are not referred to directly, so their extensions are not included). As a practical matter, EVERY instance in the wild I know of involves png, not counting one commented-out path in an ancient campaign. c) File extensions can include capitals, particularly on Windows, where the effects of DOS unicase linger. So we make the search case-insensitive.
* regex object: This splits the line into groups. The differences from the regex used in the while statement: a) We also look for a non-pathbreaking string to the left of the backslash as well as the right. This means that group(1) will match the entire file path except the extension. b) The \b boundary has been made a non-consuming look-ahead assertion, to simplify future references to the regex object and its groups.
* fronted: The regex object, except all backslashes in group(1) are replaced by frontslashes.
* precomment: Here, we simply reconstruct precomment with the modified regex object.
* print: Besides reporting the substitution to stdout, I include a plea for cross-platform compatibility.
* lines[i]: Now it's time to rebuild the whole line.
