So if a Prankster-mon chooses in two successive turns an attacking move and an Status move,
and this Pokémon is encored into the attacking move before the Status move proceeds,
the attacking move will be used and it won't affect a Dark-type target.
Often, you just need a random item in an array. Throughout Pokemon
Showdown's code, there are many instances of the following pattern:
let randomThing = things[this.random(things.length)];
Make this code easier to read by factoring the indexing into the
PRNG#sample function:
let randomThing = this.sample(things);
Run the following sed script to refactor lots of code to use sample:
s/\([a-zA-Z0-9.]\{1,\}\)\[this\.random(\1\.length)\]/this.sample(\1)/
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.
Often, you just need a random boolean. Throughout Pokemon Showdown's
code, there are many creative ways of requesting random booleans. For
example:
if (this.random(10) < 3) {
if (this.isWeather(['sunnyday', 'desolateland']) || this.random(2) === 0) {
let shiny = !this.random(1024);
if (uberCount > 1 && this.random(5) >= 1) continue;
if (!this.random(3)) ability = ability1.name;
} else if ((ability === 'Iron Barbs' || ability === 'Rough Skin') && this.random(2)) {
if (typeof secondary.chance === 'undefined' || this.random(256) <= effectChance) {
if (accuracy !== true && this.random(256) > accuracy) {
Enable these methods to converge by introducing the PRNG#randomChance
function. It accepts a probability and returns true with that
probability.
Run the following sed script to refactor many common patterns to use
randomChance:
s/this\.random(\([0-9]\{1,\}\)) >= \([0-9]\{1,\}\)/!this.randomChance(\2, \1)/g
s/this\.random(\([0-9]\{1,\}\)) < \([0-9]\{1,\}\)/this.randomChance(\2, \1)/g
s/this\.random(\([0-9]\{1,\}\)) === 0/this.randomChance(1, \1)/g
s/!this\.random(\([0-9]\{1,\}\))/this.randomChance(1, \1)/g
The sed script takes advantage of the following properties:
random(x) < y is equivalent to randomChance(y, x)
random(x) >= y is equivalent to !(random(x) < y), i.e. !randomChance(y, 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)
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.
Battle#getRelevantEffectsInner performs a lookup for the base species of
every Pokemon with ModdedDex#getEffect, then invokes callbacks. The
lookup is expensive, and callbacks very rare. In fact, there are only
ever two callbacks: one for Arceus (SwitchIn) and one for Silvally
(SwitchIn).
Instead of an expensive ModdedDex#getEffect lookup for the callbacks,
put the callbacks directly on the Pokemon's Template object.
On my machine, this commit speeds up Pokemon Showdown's tests by 20%.
Methodology: With and without this commit, I ran mocha four times with
zsh' 'time' builtin, dropped the first result, and averaged the wall
times:
mocha times before this commit:
18.20s user 0.33s system 118% cpu 15.704 total
17.91s user 0.34s system 118% cpu 15.454 total
18.11s user 0.33s system 118% cpu 15.558 total
mocha times after this commit:
15.58s user 0.33s system 122% cpu 13.028 total
15.32s user 0.33s system 121% cpu 12.890 total
15.56s user 0.32s system 121% cpu 13.068 total
Hardware:
Mid 2012 MacBook Pro
2.6 GHz Intel Core i7
Software:
Node v9.0.0
macOS 10.10.5
I originally thought this would have to be hardcoded, but actually this
can be coded slightly less hardly than expected!
Getting a Blissey with Present + Heal Bell in Gen 2 works like this:
- Teach Smeargle Present + Heal Bell
- Breed Present + Heal Bell into Snubbull
- Chainbreed Present + Heal Bell into Blissey
The main issue is that checking chainbreeding is very hard, so PS
mostly just takes the stance of "chainbreeding multiple moves is
probably impossible; hardcode exceptions".
BUT! BUT!!!!
Instead of hardcoding this exact move combination, we can actually
just hardcode the fact "the first step of chainbreeding is always legal
if the first father is Smeargle". Which I did and it works!
A battle's inputLog is now stored separately from the output log. It's
not an exact log of inputs, but rather just a collection of the inputs
that resulted in the battle: a default choice expands to the choice
that was actually used, and the starting seed is logged whether or not
it was explicitly passed into the battle stream.
Fixes#4348Fixes#3201
This contains a lot of minor refactors, but the main thing that's going
on here is that battle stream writes have been streamlined to be a lot
easier for others to use.
We even support:
./pokemon-showdown simulate-battle
which provides a stdio interface for anyone using any programming
language to simulate a battle.
`Sim.construct` no longer exists. Battles are now constructed directly
with `new Battle()`. Parameters other than formatid are now passed as
`options`.
As far as I can tell, `curly, multi-line, consistent` does everything I
want; there's no reason to keep around a validate-conditionals rule.
Which is probably good, since eslint is deprecating the API for this,
anyway. The nice thing about not relying on deprecated APIs is that now
you can lint PS with `eslint` rather than needing to memorize
command-line switches.
Process Manager is now lib/process-manager.js
It's been entirely rewritten to reflect what I think a process manager
API should look like.
In particular, there are now two Process Managers, QueryProcessManager
and StreamProcessManager.
Pass QueryProcessManager a pure-ish query function (sync or async) that
takes a JSON value and returns a JSON value, and PM.query() will
execute that function in a subprocess, and return a Promise for its
return value.
StreamProcessManager is the same idea: Pass it a function to create an
ObjectReadWriteStream, and PM.createStream() will create a stream in a
subprocess and return a stream connected to it.
Now, seeds are passed as arrays, rather than needing to pass an entire
PRNG object. In addition, they're now passed in the options object,
instead of as a separate argument.
This is done mostly so the Miracle Eye can be rewritten with a custom
seed, which requires fewer turns and should overall be faster. Which
was in turn done because a Miracle Eye timed out on Travis CI earlier.
Overall, the speed increase is pretty negligible, so this is mostly
just about improving the test API.
