This makes it so a regular build will rebuild battle text, instead of
requiring a full build.
battle text is under active development, so this is pretty useful,
even if conceptually, text is purely a graphical thing and not actually
needed by headless battles.
This will probably be our last data sync, until I work out a new solution
for rebuilding learnsets-g6 without needing an old copy, so learnsets-g6
can be gitignored.
The reason an old copy is currently needed is because it was written back
when learnsets-g6 contained data on the order same-level moves were learned
(most pokemon have a lot of L1 moves, and the order is relevant for which
moves are kept and which moves are replaced if you catch the pokemon at
medium-low level.)
This information isn't present in learnsets.js, so learnsets-g6.js needs to
preserve that information from older copies of learnsets-g6.js.
This has of course been entirely irrelevant for years, because we never
encoded learnset order data in gen 7 in the first place. But the code for
doing so stayed around...
These files are now autogenerated by the build scripts, and depend
on files not even present on GitHub anyway.
(The minidex is a database of height/width for PS's animated GIF
sprites, for use by the animation engine. It also contains dex numbers
for use by pokemon icon spritesheets.)
Weather uses both 'activate':
The mysterious strong winds weakened the attack!
and 'upkeep':
The sandstorm is raging.
So keeping them on the same message type is complicated. PS already
uses `|upkeep|` to mark the beginning of the residual phase, so this is
a good name for this message type.
For now, only upkeep messages happening during the residual step are
here - Hail, Sandstorm, and Uproar. Messages that happen at other
times, such as Attract's "[POKEMON] is in love with [TARGET]!" remain
as "activate".
Unfortunately, the `loadRemoteData` trick we used to load data no
longer works. The new trick is to load asynchronously, and defer
initialization to `onload`.
This isn't a really serious CAPTCHA, somebody specifically targetting
Showdown will evade it. However, it is an obstacle for blind people,
so an alternative text-only CAPTCHA was introduced.
Supporting it actually turns out to be very simple, so we might as
well. In practice, we probably want to never use this feature
for broadcast messages - I don't think I want it in replays.
It could still be nice for stuff like /roomsettings, though.
Probably the most controversial change here is that I have a max line
length limit, currently set to 140 columns. Lines that set up a
string buffer, lines involving regexes, and the text parser's replace
chains are excluded from the limit.
PS has otherwise been moving towards a line length limit, it just
hasn't been linter-enforced yet. I worry about contributors being
annoyed by it, especially since it's not like it's handled
automatically by Prettier or something.
Oh well, it's set to "warning" so Travis won't yell about it.
Out of 12 issues found:
3 bugs:
- duplicate property - caught a bug in Gen 1 Light Screen
- duplicate property - caught a bug in Gen 1 Reflect
- unused variable - caught a bug in type animations
7 harmless but good for code quality:
- unused variable - harmless but good for code quality
- unused variable - harmless but good for code quality
- unused variable - harmless but good for code quality
- unused variable - harmless but good for code quality
- duplicate case - harmless but important for code quality
- unused variable - harmless but good for code quality
- unused variable - harmless but important for code quality
2 not-bugs that had to be worked around:
- unused variable - used for an `eval` trick, had to use a workaround
- unused variable - used for readable destructuring
I think on balance, LGTM does more good than bad. Catching bugs early
is worth some amount of hassle.
(Also like half these problems are problems tslint could catch if I
actually bothered to set it up...)
