mirror of
https://github.com/smogon/pokemon-showdown.git
synced 2026-04-24 15:00:11 -05:00
624 lines
22 KiB
Markdown
624 lines
22 KiB
Markdown
Protocol
|
|
========
|
|
|
|
Pokémon Showdown's protocol is relatively simple.
|
|
|
|
Pokémon Showdown is implemented in SockJS. SockJS is a compatibility
|
|
layer over raw WebSocket, so you can actually connect to Pokémon
|
|
Showdown directly using WebSocket:
|
|
|
|
ws://sim.smogon.com:8000/showdown/websocket
|
|
or
|
|
wss://sim.smogon.com/showdown/websocket
|
|
|
|
Client implementations you might want to look at for reference include:
|
|
|
|
- pickdenis' chat bot (Ruby) -
|
|
https://github.com/pickdenis/ps-chatbot
|
|
- Quinella and TalkTakesTime's chat bot (Node.js) -
|
|
https://github.com/TalkTakesTime/Pokemon-Showdown-Bot
|
|
- Nixola's chat bot (Lua) -
|
|
https://github.com/Nixola/NixPSbot
|
|
- the official client (HTML5 + JavaScript) -
|
|
https://github.com/Zarel/Pokemon-Showdown-Client
|
|
|
|
The official client logs protocol messages in the JavaScript console,
|
|
so opening that (F12 in most browsers) can help tell you what's going
|
|
on.
|
|
|
|
Client-to-server messages
|
|
-------------------------
|
|
|
|
Messages from the user to the server are in the form:
|
|
|
|
ROOMID|TEXT
|
|
|
|
`ROOMID` can optionally be left blank if it's the lobby, or if the room
|
|
is irrelevant (for instance, if `TEXT` is a command like
|
|
`/join lobby` where it doesn't matter what room it's sent from, you can
|
|
just send `|/join lobby`.)
|
|
|
|
`TEXT` can contain newlines, in which case it'll be treated the same
|
|
way as if each line were sent to the room separately.
|
|
|
|
A partial list of available commands can be found with `/help`.
|
|
|
|
To log in, look at the documentation for the `|challstr|` server message.
|
|
|
|
|
|
Server-to-client messages
|
|
-------------------------
|
|
|
|
Messages from the server to the user are in the form:
|
|
|
|
>ROOMID
|
|
MESSAGE
|
|
MESSAGE
|
|
MESSAGE
|
|
...
|
|
|
|
`>ROOMID` and the newline after it can be omitted if the room is lobby
|
|
or global. `MESSAGE` cannot start with `>`, so it's unambiguous whether
|
|
or not `>ROOMID` has been omitted.
|
|
|
|
As for the payload: it's made of any number of blocks of data
|
|
separated by newlines; empty lines should be ignored. In particular,
|
|
it should be treated the same way whether or not it ends in a
|
|
newline, and if the payload is empty, the entire message should be ignored.
|
|
|
|
If `MESSAGE` doesn't start with `|`, it should be shown directly in the
|
|
room's log. Otherwise, it will be in the form:
|
|
|
|
|TYPE|DATA
|
|
|
|
For example:
|
|
|
|
|j| Some dude
|
|
|c|@Moderator|hi!
|
|
|c| Some dude|you suck and i hate you!
|
|
Some dude was banned by Moderator.
|
|
|l| Some dude
|
|
|b|battle-ou-12| Cool guy|@Moderator
|
|
|
|
This might be displayed as:
|
|
|
|
Some dude joined.
|
|
@Moderator: hi!
|
|
Some dude: you suck and i hate you!
|
|
Some dude was banned by Moderator.
|
|
Some dude left.
|
|
OU battle started between Cool guy and Moderator
|
|
|
|
For bandwidth reasons, five of the message types - `chat`, `join`, `leave`,
|
|
`name`, and `battle` - are sometimes abbreviated to `c`, `j`, `l`, `n`,
|
|
and `b` respectively. All other message types are written out in full so they
|
|
should be easy to understand.
|
|
|
|
Four of these can be uppercase: `J`, `L`, `N`, and `B`, which are
|
|
the equivalent of their lowercase versions, but are recommended not to be
|
|
displayed inline because they happen too often. For instance, the main server
|
|
gets around 5 joins/leaves a second, and showing that inline with chat would
|
|
make it near-impossible to chat.
|
|
|
|
Some outgoing message types
|
|
---------------------------
|
|
|
|
`USER` = a user, the first character being their rank (users with no rank are
|
|
represented by a space), and the rest of the string being their username.
|
|
|
|
####Room initialization
|
|
|
|
`|init|ROOMTYPE`
|
|
|
|
> The first message received from a room when you join it. `ROOMTYPE` is
|
|
> one of: `chat` or `battle`
|
|
|
|
`|users|USERLIST`
|
|
|
|
> `USERLIST` is a comma-separated list of `USER`s, sent from chat rooms when
|
|
> they're joined.
|
|
|
|
####Room messages
|
|
|
|
`||MESSAGE` or `MESSAGE`
|
|
|
|
> We received a message `MESSAGE`, which should be displayed directly in
|
|
> the room's log.
|
|
|
|
`|html|HTML`
|
|
|
|
> We received an HTML message, which should be sanitized and displayed
|
|
> directly in the room's log.
|
|
|
|
`|uhtml|NAME|HTML`
|
|
|
|
> We recieved an HTML message (NAME) that can change what it's displaying,
|
|
> this is used in things like our Polls system, for example.
|
|
|
|
`|uhtmlchange|NAME|HTML`
|
|
|
|
> Changes the HTML display of the `|uhtml|` message named (NAME).
|
|
|
|
`|join|USER` or `|j|USER`
|
|
|
|
> `USER` joined the room.
|
|
|
|
`|leave|USER` or `|l|USER`
|
|
|
|
> `USER` left the room.
|
|
|
|
`|name|USER|OLDID` or `|n|USER|OLDID`
|
|
|
|
> A user changed name to `USER`, and their previous userid was `OLDID`.
|
|
|
|
`|chat|USER|MESSAGE` or `|c|USER|MESSAGE`
|
|
|
|
> `USER` said `MESSAGE`. Note that `MESSAGE` can contain `|` characters,
|
|
> so you can't just split by `|` and take the fourth string.
|
|
|
|
`|:|TIMESTAMP`
|
|
|
|
`|c:|TIMESTAMP|USER|MESSAGE`
|
|
|
|
> `c:` is pretty much the same as `c`, but also comes with a UNIX timestamp;
|
|
> (the number of seconds since 1970). This is used for accurate timestamps
|
|
> in chat logs.
|
|
>
|
|
> `:` is the current time according to the server, so that times can be
|
|
> adjusted and reported in the local time in the case of a discrepancy.
|
|
>
|
|
> The exact fate of this command is uncertain - it may or may not be
|
|
> replaced with a more generalized way to transmit timestamps at some point.
|
|
|
|
`|battle|ROOMID|USER1|USER2` or `|b|ROOMID|USER1|USER2`
|
|
|
|
> A battle started between `USER1` and `USER2`, and the battle room has
|
|
> ID `ROOMID`.
|
|
|
|
####Battle messages
|
|
|
|
`|player|PLAYER|USERNAME|AVATAR`
|
|
|
|
> Appears when you join a battle room. `PLAYER` denotes which player it is
|
|
> (`p1` or `p2`) and `USERNAME` is the username. `AVATAR` is the player's
|
|
> avatar identifier (usually a number, but other values can be used for
|
|
> custom avatars).
|
|
|
|
|gametype|GAMETYPE
|
|
|gen|GENNUM
|
|
|tier|TIERNAME
|
|
|rated
|
|
|rule|RULE: DESCRIPTION
|
|
|
|
> Additional details when you join a battle room. `GAMETYPE` is one of
|
|
> `singles`, `doubles`, or `triples`; `GENNUM` denotes the generation of
|
|
> Pokémon being played; `tier` is the format; and `rule` appears multiple
|
|
> times, once for each clause in effect. `rated` only appears if the battle
|
|
> is rated.
|
|
|
|
|clearpoke
|
|
|poke|PLAYER|DETAILS|ITEM
|
|
|poke|PLAYER|DETAILS|ITEM
|
|
...
|
|
|teampreview
|
|
|
|
> These messages appear if you're playing a format that uses team previews.
|
|
> `PLAYER` is the player ID (see `|player|`) and `DETAILS` describes the
|
|
> pokemon. `|teampreview` commonly appears after `|rule` tags instead of
|
|
> immediately after the pokemon list.
|
|
>
|
|
> The format for `DETAILS` is described in `|switch|`, although not
|
|
> everything may be revealed. In particular, forme is sometimes not
|
|
> specified (so Arceus would appear as `Arceus-*` since it's impossible
|
|
> to identify Arceus forme in Team Preview).
|
|
|
|
`|request|REQUEST`
|
|
|
|
> Gives a JSON object containing a request for a decision (to move or
|
|
> switch). To assist in your decision, `REQUEST.active` has information
|
|
> about your active Pokémon, and `REQUEST.side` has information about your
|
|
> your team as a whole.
|
|
|
|
`|inactive|MESSAGE` or `|inactiveoff|MESSAGE`
|
|
|
|
> A message related to the battle timer has been sent. The official client
|
|
> displays these messages in red.
|
|
>
|
|
> `inactive` means that the timer is on at the time the message was sent,
|
|
> while `inactiveoff` means that the timer is off.
|
|
|
|
`|start`
|
|
|
|
> Indicates that the game has started.
|
|
|
|
`|win|USER`
|
|
|
|
> `USER` has won the battle.
|
|
|
|
`|tie`
|
|
|
|
> The battle has ended in a tie.
|
|
|
|
######Major actions
|
|
|
|
In battle, most Pokémon actions come in the form `|ACTION|POKEMON|DETAILS`
|
|
followed by a few messages detailing what happens after the action occurs.
|
|
|
|
A Pokémon is always identified in the form `POSITION: NAME`. `POSITION` is
|
|
the spot that the Pokémon is in: it consists of the `PLAYER` of the player
|
|
(see `|player|`), followed by a letter indicating the given Pokémon's
|
|
position, counting from `a`.
|
|
|
|
In doubles and triples battles, `a` will refer to the leftmost Pokémon
|
|
on one team and the rightmost Pokémon on the other (so `p1a` faces `p2c`,
|
|
etc). `NAME` is the nickname of the Pokémon performing the action.
|
|
|
|
Battle actions (especially minor actions) often come with tags such as
|
|
`|[from] EFFECT|[of] SOURCE`. `EFFECT` will be an effect (move, ability,
|
|
item, status, etc), and `SOURCE` will be a Pokémon. These can affect the
|
|
message or animation displayed, but do not affect anything else. Other
|
|
tags include `|[still]` (suppress animation) and `|[silent]` (suppress message).
|
|
|
|
`|move|POKEMON|MOVE|TARGET`
|
|
|
|
> The specified Pokémon has used move `MOVE` at `TARGET`. If a move has
|
|
> multiple targets or no target, `TARGET` should be ignored. If a move
|
|
> targets a side, `TARGET` will be a (possibly fainted) Pokémon on that
|
|
> side.
|
|
>
|
|
> If `|[miss]` is present, the move missed.
|
|
>
|
|
> `|[anim] MOVE2` tells the client to use the animation of `MOVE2` instead
|
|
> of `MOVE` when displaying to the client.
|
|
|
|
`|switch|POKEMON|DETAILS|HP STATUS` or `|drag|POKEMON|DETAILS|HP STATUS`
|
|
|
|
> A Pokémon identified by `POKEMON` has switched in (the old Pokémon, if
|
|
> still there, is switched out).
|
|
>
|
|
> `DETAILS` is a comma-separated list of all information about a pokemon
|
|
> visible on the battle screen: species, shininess, gender, and level. So it
|
|
> starts with `SPECIES`, adding `, shiny` if it's shiny, `, M` if it's male,
|
|
> `, F` if it's female, `, L##` if it's not level 100.
|
|
>
|
|
> So, for instance, `Deoxys-Speed` is a level 100 non-shiny genderless
|
|
> Deoxys (Speed forme). `Sawsbuck, shiny, F, L50` is a level 50 shiny female
|
|
> Sawsbuck (Spring form).
|
|
>
|
|
> `POKEMON|DETAILS` represents all the information that can reliably identify
|
|
> a pokemon in a game. If two pokemon have the same `POKEMON|DETAILS` (which
|
|
> will never happen in any format with Species Clause), you usually won't be
|
|
> able to tell if the same pokemon switched in or a different pokemon switched
|
|
> in.
|
|
>
|
|
> The switched Pokémon has HP `HP`, and status `STATUS`. `HP` is specified as
|
|
> a fraction; if it is your own Pokémon then it will be `CURRENT/MAX`, if not,
|
|
> it will be `/100` if HP Percentage Mod is in effect and `/48` otherwise.
|
|
> `STATUS` can be left blank, or it can be `slp`, `par`, etc.
|
|
>
|
|
> `switch` means it was intentional, while `drag` means it was unintentional
|
|
> (forced by Whirlwind, Roar, etc).
|
|
|
|
`|swap|POKEMON|POSITION`
|
|
|
|
> Moves already active `POKEMON` to active field `POSITION` where the
|
|
> leftmost position is 0 and each position to the right counts up by 1.
|
|
|
|
`|detailschange|POKEMON|DETAILS|HP STATUS` or
|
|
`|-formechange|POKEMON|SPECIES|HP STATUS`
|
|
|
|
> The specified Pokémon has changed formes (via Mega Evolution, ability, etc.)
|
|
> to `SPECIES`. If the forme change cannot be reverted (Mega Evolution or a
|
|
> Shaymin-Sky that is frozen), then `detailschange` will appear; otherwise,
|
|
> the client will send `-formechange`.
|
|
>
|
|
> For the `DETAILS` format, see the documentation for `|switch|`.
|
|
|
|
`|cant|POKEMON|REASON` or `|cant|POKEMON|REASON|MOVE`
|
|
|
|
> The Pokémon `POKEMON` could not perform a move because of the indicated
|
|
> `REASON` (such as paralysis, Disable, etc). Sometimes, the move it was
|
|
> trying to use is given.
|
|
|
|
`|faint|POKEMON`
|
|
|
|
> The Pokémon `POKEMON` has fainted.
|
|
|
|
######Minor actions
|
|
|
|
Minor actions are less important than major actions. In the official client,
|
|
they're usually displayed in small font if they have a message. Pretty much
|
|
anything that happens in a battle other than a switch or the fact that a move
|
|
was used is a minor action. So yes, the effects of a move such as damage or
|
|
stat boosts are minor actions.
|
|
|
|
`|-fail|POKEMON|ACTION`
|
|
|
|
> The specified `ACTION` has failed against the `POKEMON` targetted. The `ACTION`
|
|
> in question can be a move that fails, or a stat drop blocked by an ability
|
|
> like Hyper Cutter, in which case `ACTION` will be `unboost|STAT`, where `STAT`
|
|
> indicates where the ability prevents stat drops. (For abilities that block all
|
|
> stat drops, like Clear Body, `|STAT` does not appear.)
|
|
|
|
`|-damage|POKEMON|HP STATUS`
|
|
|
|
> The specified Pokémon `POKEMON` has taken damage, and is now at
|
|
> `HP STATUS` (see `|switch|` for details).
|
|
>
|
|
> If `HP` is 0, `STATUS` should be ignored. The current behavior is for
|
|
> `STATUS` to be `fnt`, but this may change and should not be relied upon.
|
|
|
|
`|-heal|POKEMON|HP STATUS`
|
|
|
|
> Same as `-damage`, but the Pokémon has healed damage instead.
|
|
|
|
`|-status|POKEMON|STATUS`
|
|
|
|
> The Pokémon `POKEMON` has been inflicted with `STATUS`.
|
|
|
|
`|-curestatus|POKEMON|STATUS`
|
|
|
|
> The Pokémon `POKEMON` has recovered from `STATUS`.
|
|
|
|
`|-cureteam|POKEMON`
|
|
|
|
> The Pokémon `POKEMON` has used a move that cures its team of status effects,
|
|
> like Heal Bell.
|
|
|
|
`|-boost|POKEMON|STAT|AMOUNT`
|
|
|
|
> The specified Pokémon `POKEMON` has gained `AMOUNT` in `STAT`, using the
|
|
> standard rules for Pokémon stat changes in-battle. `STAT` is a standard
|
|
> three-letter abbreviation fot the stat in question, so Speed will be `spe`,
|
|
> Special Defense will be `spd`, etc.
|
|
|
|
`|-unboost|POKEMON|STAT|AMOUNT`
|
|
|
|
> Same as `-boost`, but for negative stat changes instead.
|
|
|
|
`|-weather|WEATHER`
|
|
|
|
> Indicates the weather that is currently in effect. If `|[upkeep]` is present,
|
|
> it means that `WEATHER` was active previously and is still in effect that
|
|
> turn. Otherwise, it means that the weather has changed due to a move or ability,
|
|
> or has expired, in which case `WEATHER` will be `none`.
|
|
|
|
`|-fieldstart|CONDITION`
|
|
|
|
> The field condition `CONDITION` has started. Field conditions are all effects that
|
|
> affect the entire field and aren't a weather. (For example: Trick Room, Grassy
|
|
> Terrain)
|
|
|
|
`|-fieldend|CONDITION`
|
|
|
|
> Indicates that the field condition `CONDITION` has ended.
|
|
|
|
`|-sidestart|SIDE|CONDITION`
|
|
|
|
> A side condition `CONDITION` has started on `SIDE`. Side conditions are all effects
|
|
> that affect one side of the field. (For example: Tailwind, Stealth Rock, Reflect)
|
|
|
|
`|-sideend|SIDE|CONDITION`
|
|
|
|
> Indicates that the side condition `CONDITION` ended for the given `SIDE`.
|
|
|
|
`|-crit|POKEMON`
|
|
|
|
> A move has dealt a critical hit against the `POKEMON`.
|
|
|
|
`|-supereffective|POKEMON`
|
|
|
|
> A move was super effective against the `POKEMON`.
|
|
|
|
`|-resisted|POKEMON`
|
|
|
|
> A move was not very effective against the `POKEMON`.
|
|
|
|
`|-immune|POKEMON`
|
|
|
|
> The `POKEMON` was immune to a move.
|
|
|
|
`|-item|POKEMON|ITEM`
|
|
|
|
> The `ITEM` held by the `POKEMON` has been changed or revealed due to a move or
|
|
> ability. In addition, Air Balloon reveals itself when the Pokémon holding it
|
|
> switches in, so it will also cause this message to appear.
|
|
|
|
`|-enditem|POKEMON|ITEM`
|
|
|
|
> The `ITEM` held by `POKEMON` has been destroyed, and it now holds no item. This can
|
|
> be because of an item's own effects (consumed Berries, Air Balloon), or by a move or
|
|
> ability, like Knock Off. If a berry is consumed, it also has an additional modifier
|
|
> `|[eat]` to indicate that it was consumed. This message does not appear if the item's
|
|
> ownership was changed (with a move or ability like Thief or Trick), even if the move
|
|
> or ability would result in a Pokémon without an item.
|
|
|
|
`|-ability|POKEMON|ABILITY`
|
|
|
|
> The `ABILITY` of the `POKEMON` has been changed due to a move/ability, or it has
|
|
> activated in a way that could not be better described by one of the other minor
|
|
> messages. For example, Clear Body sends `-fail` when it blocks stat drops, while
|
|
> Mold Breaker sends this message to reveal itself upon switch-in.
|
|
>
|
|
> Note that Skill Swap does not send this message despite it changing abilities,
|
|
> because it does not reveal abilities when used between allies in a Double or
|
|
> Triple Battle.
|
|
|
|
`|-endability|POKEMON`
|
|
|
|
> The `POKEMON` has had its ability surpressed, either by a move like Gastro Acid, or
|
|
> by the effects of Mummy.
|
|
|
|
`|-transform|POKEMON|SPECIES`
|
|
|
|
> The Pokémon `POKEMON` has transformed into `SPECIES` by the effect of Transform
|
|
> or the ability Imposter.
|
|
|
|
`|-mega|POKEMON|MEGASTONE`
|
|
|
|
> The Pokémon `POKEMON` used `MEGASTONE` to Mega Evolve.
|
|
|
|
`|-activate|EFFECT`
|
|
|
|
> A miscellaneous effect has activated. This is triggered whenever an effect could
|
|
> not be better described by one of the other minor messages: for example, healing
|
|
> abilities like Water Absorb simply use `-heal`, and items that are consumed upon
|
|
> use have the `-enditem` message instead.
|
|
|
|
`|-hint|MESSAGE`
|
|
|
|
> Displays a message in parentheses to the client. Hint messages appear to explain and
|
|
> clarify why certain actions, such as Fake Out and Mat Block failing, have occurred,
|
|
> when there would normally be no in-game messages.
|
|
|
|
`|-center`
|
|
|
|
> Appears in Triple Battles when only one Pokémon remains on each side, to indicate
|
|
> that the Pokémon have been automatically centered.
|
|
|
|
`|-message|MESSAGE`
|
|
|
|
> Displays a miscellaneous message to the client. These messages are primarily used
|
|
> for messages from game mods that aren't supported by the client, like rule clauses
|
|
> such as Sleep Clause, or other metagames with custom messages for specific scenarios.
|
|
|
|
I'll document all the message types eventually, but for now this should be
|
|
enough to get you started. You can watch the data sent and received from
|
|
the server on a regular connection, or look at the client source code
|
|
for a full list of message types.
|
|
|
|
######Action requests
|
|
|
|
These are how the client sends the player's decisions to the server. All
|
|
requests except `/undo` can be sent with `|RQID` at the end. `RQID` is
|
|
`REQUEST.rqid` from `|request|`. Each `RQID` is a unique number used to
|
|
identify which action the request was intended for and is used to protect
|
|
against race conditions involving `/undo` (the cancel button).
|
|
|
|
If an invalid request is sent, the game will replace the missing or
|
|
erroneous request with a valid choice, which is usually the first usable
|
|
move.
|
|
|
|
`|/team ORDER`
|
|
|
|
> Chooses the team order. Numbers not listed are displaced to the back by swapping
|
|
> them with the number that took their place. For example `/team 25` sets the team
|
|
> order from default to 253416.
|
|
|
|
`|/move NUMBER TARGET`
|
|
|
|
> Uses your active Pokémon's `NUMBER`th move on `TARGET` Pokémon. `NUMBER` is usually
|
|
> a number ranging from 1 to 4 (although it can range up to 24 in Custom Games where
|
|
> Pokémon can have that many moves).
|
|
>
|
|
> `TARGET` is optional and only needs to be specified for single target moves in
|
|
> doubles/triples formats. Moves with `TARGET` specify which position they are trying
|
|
> to use the move on as a number wherein the opposing Pokémon are positive integers
|
|
> counting up from `1` starting on the right. Ally Pokémon targets are negative
|
|
> integers counting down from `-1` starting on the left.
|
|
>
|
|
> If `mega` is added as a final parameter, the Pokémon will Mega Evolve if possible.
|
|
|
|
`|/switch NUMBER`
|
|
|
|
> Switches the active Pokémon with the `NUMBER`th Pokémon on the team. In cases where
|
|
> a Pokémon is KOed, their replacement is also chosen with `/switch`. This should
|
|
> correspond to a non-active, non-fainted Pokémon, which means `NUMBER` should be
|
|
> between 2 and 6.
|
|
|
|
`|/choose ACTION,ACTION,ACTION`
|
|
|
|
> For doubles/triples formats, decisions are sent for all team positions in the same
|
|
> line separated by commas. `ACTION` can be any of the following: `move`, `switch`,
|
|
> `shift`, `pass`.
|
|
>
|
|
> `move` and `switch` use the same syntax as their respective commands explained above
|
|
> except without the `/`. In triples, `/choose shift` requests to `|swap|` the current
|
|
> outside Pokémon to the middle team position. pass is used to indicate that the Pokémon
|
|
> in that slot is not performing an action, for instance, because the Pokémon is fainted
|
|
> and you have no non-fainted Pokémon to replace it with, or because the Pokémon is not
|
|
> fainted while you are switching in replacements for fainted Pokémon. For example,
|
|
> `/choose move 1 2,move 4 -1,pass` will have the leftmost Pokémon attack the opponent's
|
|
> middle Pokémon with its first move, the middle Pokémon will attack its ally to the
|
|
> left with its fourth move, and the third team slot is empty.
|
|
|
|
`|/undo`
|
|
|
|
> Attempts to cancel the last request so a new one can be made.
|
|
|
|
####Global messages
|
|
|
|
`|popup|MESSAGE`
|
|
|
|
> Show the user a popup containing `MESSAGE`. `||` denotes a newline in
|
|
> the popup.
|
|
|
|
`|pm|SENDER|RECEIVER|MESSAGE`
|
|
|
|
> A PM was sent from `SENDER` to `RECEIVER` containing the message
|
|
> `MESSAGE`.
|
|
|
|
`|usercount|USERCOUNT`
|
|
|
|
> `USERCOUNT` is the number of users on the server.
|
|
|
|
`|nametaken|USERNAME|MESSAGE`
|
|
|
|
> You tried to change your username to `USERNAME` but it failed for the
|
|
> reason described in `MESSAGE`.
|
|
|
|
`|challstr|CHALLSTR`
|
|
|
|
> You just connected to the server, and we're giving you some information you'll need to log in.
|
|
>
|
|
> If you're already logged in and have session cookies, you can make an HTTP GET request to
|
|
> `http://play.pokemonshowdown.com/action.php?act=upkeep&challstr=CHALLSTR`
|
|
>
|
|
> Otherwise, you'll need to make an HTTP POST request to `http://play.pokemonshowdown.com/action.php`
|
|
> with the data `act=login&name=USERNAME&pass=PASSWORD&challstr=CHALLSTR`
|
|
>
|
|
> `USERNAME` is your username and `PASSWORD` is your password, and `CHALLSTR`
|
|
> is the value you got from `|challstr|`. Note that `CHALLSTR` contains `|`
|
|
> characters. (Also feel free to make the request to `https://` if your client
|
|
> supports it.)
|
|
>
|
|
> Either way, the response will start with `]` and be followed by a JSON
|
|
> object which we'll call `data`.
|
|
>
|
|
> Finish logging in (or renaming) by sending: `/trn USERNAME,0,ASSERTION`
|
|
> where `USERNAME` is your desired username and `ASSERTION` is `data.assertion`.
|
|
|
|
`|updateuser|USERNAME|NAMED|AVATAR`
|
|
|
|
> Your name or avatar was successfully changed. Your username is now `USERNAME`.
|
|
> `NAMED` will be `0` if you are a guest or `1` otherwise. And your avatar is
|
|
> now `AVATAR`.
|
|
|
|
`|formats|FORMATSLIST`
|
|
|
|
> This server supports the formats specified in `FORMATSLIST`. `FORMATSLIST`
|
|
> is a `|`-separated list of `FORMAT`s. `FORMAT` is a format name with one or
|
|
> more of these suffixes: `,#` if the format uses random teams, `,,` if the
|
|
> format is only available for searching, and `,` if the format is only
|
|
> available for challenging.
|
|
> Sections are separated by two vertical bars with the number of the column of
|
|
> that section prefixed by `,` in it. After that follows the name of the
|
|
> section and another vertical bar.
|
|
|
|
`|updatesearch|JSON`
|
|
|
|
> `JSON` is a JSON object representing the current state of what battles the
|
|
> user is currently searching for.
|
|
|
|
`|updatechallenges|JSON`
|
|
|
|
> `JSON` is a JSON object representing the current state of who the user
|
|
> is challenging and who is challenging the user.
|
|
|
|
`|queryresponse|QUERYTYPE|JSON`
|
|
|
|
> `JSON` is a JSON object representing containing the data that was requested
|
|
> with `/query QUERYTYPE` or `/query QUERYTYPE DETAILS`.
|
|
>
|
|
> Possible queries include `/query roomlist` and `/query userdetails USERNAME`.
|