Mechanically refactor code which uses PRNG#random for booleans to use
PRNG#randomChance instead.
Take advantage of the following properties:
random(x) < y is equivalent to randomChance(y, x)
random(x) <= y is equivalent to random(x) < (y + 1), i.e. randomChance(y + 1, x)
random(x) >= y is equivalent to !(random(x) < y), i.e. !randomChance(y, x)
random(x) > y is equivalent to random(x) >= (y + 1), i.e. !randomChance(y + 1, x)
random(x) === 0 is equivalent to random(x) < 1, i.e. randomChance(1, x)
!random(x) is equivalent to random(x) === 0, i.e. randomChance(1, x)
Boolean(random(x)) is equivalent to random(x) > 0, i.e. !randomChance(1, x)
This commit should not change behaviour. In particular, PRNG#next is
called the same number of times with the same number of parameter as
before this commit, and PRNG#next's results are interpreted in the same
way as before this commit.
Latest research (http://www.smogon.com/forums/posts/7625046/) shows that although Z-Synthesis bypasses Heal Block, using Z-Copycat to copy Synthesis does not. (Z-Copycat on a damaging move does of course turn into a damaging Z-Move.)
pokemon.moveset is now pokemon.moveSlots, which is at least slightly
clearer about what it's doing (tracking move state, mainly PP).
Mostly, this gives a consistent naming scheme for `move` (a Move
object) vs `moveSlot` (a MoveSlot object).
This also refactors a lot of existing `moveSlot` accesses to be modern,
including using `for...of`.
We are now tracking source effects for switch actions, if they're
initiated by effects such as U-turn or Baton Pass. This will lead
to better messages client-side.
Previously, if we wanted to test if A was either 'B' or 'C', we would use
the pattern:
A in {B:1, C:1}
I actually don't know how common this pattern is; I just started using
it because I was tired of typing `A === 'B' || A === 'C'` all the time.
I never really liked it, though; the `:1` part made it kind of
blatantly a hack.
I did some testing and `['B', 'C'].includes(A)` is overall faster.
(A switch statement is around 20x faster still, but who wants to type
that much code?)
Anyway, the new standard is
['B', 'C'].includes(A)
Something something progress!
Random team generation scripts are no longer in scripts.js, but instead
in a new file random-teams.js.
The scripts are now also no longer run from inside battles, but in a
new team generator object. This makes it easier for external scripts
to generate random teams by running Dex.generateTeam(format).
PS's rule table has been renamed from banlistTable, and works a bit
differently now. It's a Map instead of an object now, and the keys
work a bit differently.
The original banlistTable was designed to store bans, and later
additions shoved rules and then unbans in there. The new table is
designed to support all of these.
* Random Battle: Add possibility for Fly-Z or Bounce-Z
This involves adding Fly to some Flying Pokemon without a good Flying
STAB. (This also makes sure Fly is not their only STAB, and only exists
with setup.)
* Update scripts.js
Armaldo is far too slow to utilize Swords Dance well, and only works on
dedicated Rain teams (which are very uncommon in Randoms).
Update item selection for Substitute and Reversal in combination.
