- Remove `randomMonotypeTeam` and use `randomTeam` for Monotype Random
Battle. This prevents having to maintain two functions, in addition to
removing duplicate code.
- Improve Monotype teams by preventing more than one of the same type
combination.
- Remove no longer needed Pichu-Spiky-eared check from
`randomDoublesTeam`.
While Slaking has a gimmick use with skill swap, gastro acid, simple ray, etc., in this random format it makes a battle basically a 5v6 battle, where you can Protect on its loafing around turns or make it switch, lowering offensive pressure and receiving more damage.
* Random Battle: Don't reject Swords Dance with no-sun Growth
This will allow Growth to be rejected first. Affects Victreebel.
* Implement fastPop function
fastPop is a generalization of sampleNoReplace. While sampleNoReplace
removes a random element from the array without regard to order, fastPop
allows for a specific element to be removed. This speeds up the removal of
items from the move pool in random battles in situations where it is
needed.
* Random Battle: Remove Weather Ball from pool if Sunny Day is rejected
Among the newly added rules, there are quite a few intended to enforce
compliance of CONTRIBUTING.md-blessed idioms, as well as ensure
safe usage of classes and constant bindings.
We are also now enforcing usage of early return in commands.js,
which has 100% compliance as of fd2c45c.
- Improve Flying types by making sure they have a second STAB if they
need it
- Revert bf0af09d7c and instead hardcode
the moveset modification for Aggron; Autotomize does have a benefit
with Heavy Slam
Now that nodejs/node#3072 is mostly fixed, we can finally start using
Node 4+ features.
This refactor:
- uses arrow functions where appropriate
Note that arrow functions still aren't used in Mocha, where `this`
is sometimes meaningful.
This also removes the need for .bind() nearly everywhere, as well
as the `self = this` trick.
- refactors Validator and Connection into ES6 classes
- no longer uses Array#forEach for iterating arrays
We strongly prefer for (let i = 0; i < arr.length; i++) because of
performance reasons. Most forEaches have been replaced with for..of,
though, which is 5x slower than the long-form loop but 2x faster
than forEach, which is good enough outside of most inner loops.
The only exception is tournaments, which is due for a more invasive
refactor soon anyway.
Crashlogger now supports passing in a dictionary of additional
information to report, so we no longer need to resort to making fake
errors.
The hadException parameter has now been removed entirely. I don't know
of a use case for it to be false.
