This should be a much nicer architecture than the old
`client-battle.js`.
In particular, much of the logic of choosing moves/switches has been
moved into a new `battle-choices.ts`, with `panel-battle.tsx` only
covering the UI.
Challenges with custom rules previously required bypassing the
console commands. Now you can just do them with:
/challenge USERNAME, gen8randombattle@@@teampreview
After a long time struggling to decide how to implement this, I ended
up unifying line parsing.
Advantage: No need to call `BattleTextParser.parseLine` every time you
want to inspect a line. It's parsed into args by `PS.receive` and
everything else gets tokens.
Disadvantage: Battle rooms need to reassemble the original line to put
in their history buffer (`battle.activityQueue`). The lines are getting
parsed twice, anyway, and reassembly is a small price to pay for how
readable everything else is now.
`learnsets-g6` has always been versioned because in Gen 6, it contained
START move order.
For instance, Clefairy in BW2 has the following level-up moveset:
- START: Pound
- START: Growl
- L4: Encore
- L7: Sing
- L10: Double Slap
If you catch a wild level-10 Clefairy, its moveset will be: Growl,
Encore, Sing, Double Slap. A level-10 wild Clefairy will always have
Growl and never have Pound, because the order of its first two moves
matters.
PS's regular learnsets file doesn't take this into account, so we
tracked a `learnsets-g6` file that did, but also needed to keep in sync
with new game updates.
Well, these are no longer necessary. We've updated to Gen 7 and now
Gen 8, and we've never had START ordering for any of them. Anyone who
wants START ordering for Gen 6 can find it here:
https://github.com/Zarel/Pokemon-Gen-6-Learnsets
For this repo, though, `learnsets-g6` is still around (used only by
PSdex), but it can now be automatically built from `learnsets` without
losing anything, and so it can finally be `.gitignore`d.
`style/STYLING.html` is now a guide of generic CSS classes that can be
used by bots and chat plugins.
CSS classes that can be used by bots and chat plugins are now in a new
`battle-log.css` (previously just a section of `battle.css`)
Several PS styling patterns (specifically, `message-log`, `option`, and
`blocklink`) have been refactored into CSS classes, so that they can
be used by bots and chat plugins (why yes, I do plan on using 2/3 of
them in the log viewer).
Past CSS has been super messy. This refactor tries to make it neater
by adhering to these rules:
- Instead of trying to use e.g. `.setmenu button` selectors (to save
`class=` on every individual list item), give up and just put
`.option` directly on list items. This drastically cuts down on all
the hacks necessary to have `.button` work inside `.setmenu`.
...That's it. That's the only change. It massively cuts down on CSS
complexity. It does slightly complicate the DOM, which I'm not a _huge_
fan of, but CSS unpredictability is nearly impossible to catch and
debug, so it's massively worth it.
Now that `pokemon.gender` matches what it says it does (genderless is
now 'N' and not ''), all the rendering code needs to be updated. I made
them all pixelated while I was at it.
`Battle#getPokemon` has always been a huge mess, due to being designed
to get Pokemon in a variety of situations with different levels of
incomplete information provided by a PO replay.
For context: we haven't supported PO replays in around 9 years.
So today, I finally tracked down all the current uses of `getPokemon`.
They are now four different functions:
1. `getSwitchedPokemon`
- Get or create a Pokemon when one switches in.
2. `rememberTeamPreviewPokemon`
- Create a Pokemon because it was revealed during Team Preview.
3. `getPokemon`
- Get a Pokemon that did something recently
4. `findCorrespondingPokemon`
- Find a Pokemon to track PP use for a switch-in option tooltip
They share basically zero code and should never have been the same
function in the first place.
Now that `getPokemon` is no longer a mess, `newPokemon` and the
`Pokemon` constructor can be rearranged and more strongly typed. One
fewer `Object.assign`!
The themes would not play because we were tracking what theme to set
to with BattleSound.bgmNum. When loading a new bgm, BattleSound.setBgm
will simply return if the existing bgm (BattleSound.bgm) is the same
as the one were trying to set the bgm to.
ensureMinEVs doesn't mutate template.id (template is immutable) so
there's no reason to continue checking it. While this is hardly a
huge efficiency boost the compactness of the previous code is hardly
worth preserving over it (though this whole block could be turned
into a method and then `return` could be used to retain the
compactness).
