File paths are recorded into the game preferences up to a (currently
hardcoded) limit of 6 and opening or saving maps adds or bumps existing
entries to the top. We may allow users to change the MRU limit in
Advanced Preferences in a later commit.
Adds two translatable strings.
In order to fit file paths in the menu without filling up the whole
screen sideways, we use only the file names for now. Because identical
file names could prove to be an actual issue later, I intend to look
into ellipsizing paths correctly in a later step.
(Note that I'm piggybacking on the crummy submenu support we already had
in the themable UI so that this can be safely backported to 1.12. It's
decidedly not optimal usability-wise, but it'll have to do for now.)
Now the list is split between active and inactive packagers, and we also
list SDK maintainers (aquileia, loonycyborg).
Also restored alphabetical order, fixed comments and names, and added
aquileia, ancestral, mattsc, and vincent_c.
http://gna.org/bugs/?23674
We don't want to use the units and gold stored in the global variables if we already get them from normal carryover becasue that results in having them twice.
This only seems to happen when Use Map Settings is enabled. Using
faction_lock in that case forces the "Custom" faction selection, which
offers all possible leaders from all factions and doesn't override the
recruit lists.
faction_from_recruit would limit the faction selection to Loyalists in
1.10, thus ensuring all leaders are Loyalists with Use Map Settings on,
but that doesn't seem to work right now either. It shouldn't matter for
this scenario anyway as long as the recruit lists are the ones defined
here rather than the faction's.
This makes it so the grid and its children are only displayed when the
client has mod access to the sever, rather than keeping them visible at
all times and graying them out when not available.
Apparently, when this is the case, the number key is not included at
all, rather than set to zero, when the Lua table containing the attack
information is retrieved.
An old add-on triggered a wmliterator crash with this comment:
#>>>> !!!!! REMOVE THIS AFTER TEST !!!!! <<<<#
The traceback showed that the crash came from the lua-stripping
code, which interprets "<<" as the start of a lua string. But below
it is code to remove quoted strings, and it doesn't crash, even
though there are cases where authors forgot to close a quote.
Two key differences stood out in the otherwise similar second
code: only looking for the endquote string in the text after
beginquote, and testing that endquote was less than 0, not -1.
Changing both gets the loop to terminate. Making it search the
text only after "beginquote+2" means that ">>" will no longer
be found, giving endquote a value of -1. But -1 is not less than
-1, so that must be changed to " < 0" to close the loop.
