Also move mods/ to data/mods/
This makes PS more monorepo-like. The intent is to further separate
the sim and the server code, but without fully committing to splitting
the repository itself.
We now support `./pokemon-showdown start` in addition to
`./pokemon-showdown`. I'm not clear which I want to be the default
yet.
Back when this code was introduced, the TLDs were relatively short,
with only two outliers: .museum and .travel.
Since then, a generic TLD system was introduced which opened
registration of top level domains. The number of TLDs registered this
way exceeds 1 200, with the longest TLDs having 18 characters.
Parsing longer TLDs for emails shouldn't cause practical issues, as
e-mail syntax is unusual enough. In fact, in the older versions, this
code was buggy as it linked example@example.exa in
example@example.example, not noticing that there should be a word
bounary.
A lot of complexity in a chat formatter link regular expression is to
support links with parentheses in them. This commit introduces a test of
this to avoid accidentally breaking this functionality.
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!
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.
The client now interprets `rel="noopener"` to mean "check links for
interstice whitelist", and bypasses the interstice if it's not there.
This is is the best approach for [[google links]] to bypass the
interstice, while not whitelisting all of Google because Google
redirects are not generally trustworthy.
This mainly adds support for parenthetical spoilers:
(parenthetical spoiler: these)
They'll be useful for closing any other autoclosing spans in the
future, but currently spoiler is the only one.
This new version supports significantly more client chat formatting
than before, and is more readable.
Also new: the `code` formatting now uses basically the same system as
Markdown, where you can use as many `` ` `` in a row as you want as
your delimiter.
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
