They fixed it so that ignoring the item allows other moves to be used. However, using another move, even one that isn't part of the moveset, before you've locked yourself into a move, locks you into that move until move selection happens again. For example, a Choice Specs Oricorio choosing to use Hurricane turn 1 but getting outsped by a Quiver Dance has it use Quiver Dance, then Hurricane fails (even if it doesn't know Quiver Dance). If it does know Quiver Dance it becomes locked into it, otherwise it can choose any move for use since the Choice lock breaks at move selection if you don't have that move anymore.
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.
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.
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`.
This is a surprisingly minor refactor considering how many files it
touches, but most of this is only renames.
In terms of file renames:
- `tools.js` is now `sim/dex.js`
- `battle-engine.js` is now `sim/index.js` and its three classes are
in `sim/battle.js`, `sim/side.js`, and `sim/pokemon.js`
- `prng.js` is now `sim/prng.js`
In terms of variable renames:
- `Tools` is now `Dex`
- `BattleEngine` is now `Sim`
- `BattleEngine.Battle` is now `Sim.Battle`
- `BattleEngine.BattleSide` is now `Sim.Side`
- `BattleEngine.BattlePokemon` is now `Sim.Pokemon`
Presumably because of Dancer's existence, attempting to use another move
besides the Choice-locked move now results in the move being used but
failing immediately, with no PP loss. This applies even during Magic
Room, etc.
- Doom Desire/Future Sight now calculate accuracy when hit, not when
the move is used
- Doom Desire/Future Sight are now limit 1 per defender slot, not 1
per attacker slot
- Doom Desire/Future Sight in gen 4 and earlier now have their damage
calculated on use, rather than on hit
- Doom Desire/Future Sight in gen 4 and earlier now deal typeless
damage, and are not subject to STAB, weakness, resistance, or
immunity
- Doom Desire/Future Sight in gen 4 and earlier now can't critical
hit
- Doom Desire is now Physical in gen 3
