Files meant to be served have been moved into
`play.pokemonshowdown.com/` and `pokemonshowdown.com/`.
We now have three directories for the three subdomains handled by this
repo:
- `pokemonshowdown.com/`
- `play.pokemonshowdown.com/`
- `replay.pokemonshowdown.com/`
Naming them after the subdomains will make it much easier to tell where
the files for each go.
The diff is probably useless; it'll be easier if you just look at the
new tree:
https://github.com/smogon/pokemon-showdown-client/tree/reorganize
The client Battle class API has been pretty old and crusty, so this
updates it to be saner.
The constructor now takes an options object. Any setting you'd want to
initialize with is now a constructor option, instead of needing to call
methods after the constructor.
(Deprecated settings `roomid` and `joinButtons` still need to be set
separately.)
The old callback system is removed. It's replaced with a subscription
system vaguely resembling `PSStreamModel`. Any callbacks only intended
to be used by the warstory generator are removed (anyone who wants to
write their own warstory generator should extend `BattleSceneStub`
instead).
Battles no longer start paused. You can still start them paused by
passing `paused: true` as an option.
Playback state tracking had a bunch of rearrangement:
- `playbackState` no longer exists; state should be directly read from
`paused`, `atQueueEnd`, `turn`, and `seeking`.
- `turn` is now initialized to `-1`. `-1` now means "we haven't reached
`|teampreview|` or `|start|` yet". Reaching those sets turn to `0`.
- "Fast forwarding" and "seeking" are now consistently named "seeking".
- `seeking` tracks seek state; changes from `fastForward`:
- `null` means not seeking (replaces `0`)
- `0` means seeking the start (replaces `0.5`)
- `Infinity` means seeking the end (replaces `-1`)
- `fastForward` deprecated and replaced with `seeking`
- `fastForwardTo()` deprecated and replaced with `seekTurn()`
- `resultWaiting` is removed (it's unused)
- The "activity queue" has been renamed the "step queue", which means
some renamed properties:
- `activityQueue` to `stepQueue`
- `activityStep` to `currentStep`
- `nextActivity()` to `nextStep()`
- new property: `atQueueEnd` to track if animation has caught up to the
end of the step queue (replaces checking `playbackState`)
- new property/option: `isReplay` - will automatically set `ended` when
reaching the end of a replay (stopping music and showing a message),
if the replay was saved before the end of the battle
- both replay players (`replay.pokemonshowdown.com` and downloaded
files) have been rewritten to use an observer system, instead of the
previous manual updating
- `reset(true)` has been renamed `resetStep()`
Similar to styles/STYLING.html and styles/hpbartest.html, test pages
prove to be more robust and convenient for testing than the unit
tests (which are already broken).
These pages are primarily intended to help with delivering #1369,
but can be used to test improvements to sprites across the board.
Instead of needing to support old protocol messages, we now introduce
BattleTextParser.upgradeArgs, which automatically upgrades them to new
protocol messages.
Fixes#1199
BattleTextParser.parseLine -> BattleTextParser.parseArgs
This makes it so Battle depends on BattleTextParser, rather than
BattleTextParser depending on Battle.
This is probably better, because someone is way more likely to want
BattleTextParser standalone, than to want Battle standalone.
...which I'm sure matters to literally no one but me, but whatever. I
think it makes more sense this way.
Previously, we used the `eval` hack to "import" our code into test
files. The biggest problem with that approach is that we don't get
line numbers.
Now, we're assigning relevant variables to globals in Node.js for
tests. It's ugly, but it works. There's no simple way to import local
variables only if we're in Node.
Ideally, we'd build this in two different ways: A .mjs file for Node,
and a .js file for the browser. Or maybe use UMD. I'll figure it out
later, I guess.
This spec file is, incidentally, Jest-compatible. I benchmarked and
Jest is noticeably slower right now, so I'll stick with Mocha, but
if we ever need Jest features, it'll be useful to be able to easily
switch.
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...)
Mostly, this involves removing `BattleLog.escapeHTML` from `battle.ts`.
All previous use-cases have been replaced with something like
`Tools.sanitizeName`.
Technically, the dependency remains for `|controlshtml|` and
`|fieldhtml|`, but these will be dropped for BattleRoom/GameRoom
separation, to be done in the Preact rewrite.
This splits battle-dex.ts up into:
- `battle-dex.ts`
- dex data access, misc tools
- `battle-log.ts`
- manipulating HTML, especially in battle logs
This turned out to be a pretty significant portion of what was
previously battle-dex.
I would prefer if the test would still test if a mega gets an item,
which is why Charizard-Mega-Y was picked. It's unlikely to be banned,
but is powerful enough to stay in OU.
A safer choice would be an Arceus, but there is no code yet that
automatically gives a correct item to formes (may be worth fixing).
