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...
Mainly follow-up for 1deedc595, but also fixes a few bugs.
- BW/GSC/RBY - randomSet: fixed and renamed slot argument.
- BW - randomTeam: crashlogger relative path was set incorrectly.
- BW - randomTeam: PotD Magikarp and Delibird used outdated randomBattleMoves data format.
- RBY - randomTeam: builder was too reject-happy regarding weaknesses (counters prematurely updated).
An improvement of 130% more op/s is observed for RBY randomCCTeam,
with no significative performance regression for randomTeam in any gen.
- The lock starts even if the move is blocked by Protect, misses, or the
target is immune
- The lock ends without causing confusion whenever the move cannot be
executed
- When the lock ends normally, confusion begins even if the user is
already confused, and there is no indication that confusion has started
- In Gen 1 the duration is 3-4 turns
All this code was done before the main battle-engine was reworked to have exceptions for past gens.
Furthermore, due to how inheritance works, it was messing up team preview in Stadium formats.
All what was dealt with this code is now dealt with in battle-engine.js and all future gen 2 exceptions should be there.
Unlike battle-engine.js, old gens did not check if move.ignoreImmunity was
undefined/false in their getDamage functions, causing crashes when numbers
were passed in to the function.
hasMove was not tracking moves properly, instead only tracking new moves
added in the object instead of its entire moveset. Also, there was a
line of code that caused all moves to be flagged as rejected.
While move.affectedByImmunities was always a Boolean value to denote if
the move was affected by immunities, move.ignoreImmunity can be a Boolean
value if it ignores or is affected by all type immunities, but also can
act as an object such that !!move.ignoreImmunity[type] means it ignores
immunities of that type.
