move.zPowered is renamed move.isZPowered. It's now documented in JSDoc
exactly how it differs from move.isZ.
This commit includes several minor refactors to Z-move mechanics,
including a bug fix: Z-boosted called Weather Ball is now correctly
typed.
The types Template, Move, Ability, and Item are now read-only. This
should guard against accidental writing to types that shouldn't be
written to.
A new type, ActiveMove, has been introduced. Like it sounds, it's
used for moves that are currently actively being used. A lot of
attributes that are only relevant to active moves, such as
`hasBounced`, are now only available on ActiveMove, not on Move.
ActiveMoves are mutable, unlike Moves.
getMoveCopy has been renamed getActiveMove, to better reflect its
role. `isCopy` has been deprecated, and distinguishing Moves from
ActiveMoves is now done by `typeof move.hit === 'number'` where
necessary.
ActiveMoves now internally track which hit of a multihit move
they're on, in move.hit, so move.hit doesn't need to be manually
incremented by Triple Kick and Parental Bond anymore.
move.hasParentalBond has been replaced by a more generic
move.multihitType.
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.
Rooms now have their logging abstracted into their own file, which also
allows the rest of rooms.js to be simplified by a decent margin.
This is in preparation for using Redis as a backing for scrollback log
storage, which will give us a lot more RAM to work with.
My newest newest plan is actually to locally cache room scrollback, and
only read battle logs from Redis. This will make chatroom-joining
faster.
Ladder is now a subclass of Matchmaker, and all the APIs previously
attached to Matchmaker are now directly available in Ladder.
In addition, all functions that take a formatid are now of the form
`Ladders(formatid).function(other arguments)`
TODO: Reverse polarity; it makes more sense for Matchmaker to be
a subclass of Ladder. Fortunately, this wouldn't involve API changes.
I'm not really sold on "TeamValidatorAsync" as a class name or file
name, so I'm open to suggestions.
The long-term plan is to put TeamValidator in sim/ but this is in three
commits because I really want the right file to retain blame history.
BattleRoom is now GameRoom, a slightly more abstract room type capable
of holding any of a number of possible roomgames. Currently, battles
are the only such roomgame, but any future roomgame could possibly use
it.
Differences between ChatRoom and GameRoom:
- GameRooms start at the left, ChatRooms start at the right
- GameRooms have chat on the right, and a game area on the left, with a
view area at the top left and a controls area at the bottom left
- GameRooms retain all their logs, ChatRooms only retain the latest 100
lines
- GameRooms expire after 40 minutes of inactivity or 10 minutes of zero
online users (configurable in the future)
- GameRooms are guaranteed to have an associated game, while ChatRooms
may or may not
* Sockets: fix Sockets.killWorker not disconnecting connections
* Sockets: fix unit tests
- Fix crash when constructing mock sockets in certain cases
- Properly prevent workers from writing to stdout
- Fix race conditions in workers-related tests that were causing false
positives
* Tests: mock workers now more closely imitate sockets' workers
This helps catch cases where messages are being sent in the wrong order
to the workers, e.g. messages sent to sockets that no longer exist.
If a child process dies in a way that it can't recover from, the main
process now exits, to prevent loops of 'Error: channel closed'
thousands of times a second, filling up the error log and making it
hard to track down the real error.
