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.
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).
Corrects all of the following
Gen 2: lasts 2-3 turns
Gen 3: can't hit Ghosts
Gen 4: can hit Ghosts, stops immediately when the user falls asleep or
becomes frozen
Gens 2-6: Stops immediately when the user is prevented from moving
BattlePokemon#runImmunity is now two functions, runImmunity and
runStatusImmunity.
The split is helpful because: 1. NegateImmunity only applies to type
immunities, and 2. Immunity only applies to status immunities and
Ground immunities.
Ground immunities are now entirely handled hardcoded in isGrounded.
This overall doesn't have a noticeable impact on performance, but
it makes certain things behave more predictably, and correctly
shows the ability activation for Levitate, so I assume that means it's
a net positive. I hope I at least improved readability...
