Currently the |request API response includes the active pokemon moves & data about pokemon on the side.
Excerpt from https://github.com/smogon/pokemon-showdown/blob/master/sim/SIM-PROTOCOL.md
In building on top of this I'd like to look up data about what the move(s) and/or pokemon are for the AI to make decisions on. For example their types, damage or whatever. There are a few ways that come to mind:
- I parse the pokemon-showdown data files & lookup move data myself (from Golang reading typescript is pretty awful)
- the simulator / binary could include an extra tool for returning data (eg. `pokemon-showdown data move lightscreen` or `pokemon-showdown data pokemon raichu`) -- running OS commands from another language is somewhat awful, but this is probably the most backwards compatible and easiest solution
- I look up the data in another source like https://pokeapi.co/ using the information I'm given
This one is the most obvious, but the problem here is the pokemon & moves name(s) as given in `details` `ident` & `id` do not map directly to names that the pokeapi uses. For example 'lightscreen' is understood in the pokeapi as 'light-screen'
200: https://pokeapi.co/api/v2/move/light-screen
404: https://pokeapi.co/api/v2/move/lightscreen
Given the data I have I could make some guesses at the name as understood by PokeAPI, or I could in theory keep a data set mapping names between the two systems perhaps dynamically form a mapping by reading all moves & pokemon from PokeAPI on startup. However this seems a bit silly when both systems share the same 'num' IDs for pokemon & moves which look to be valid across multiple platforms .. which seems infinitely nicer.
Examples:
https://github.com/smogon/pokemon-showdown/blob/master/data/moves.ts (move 113 -> lightscreen)
https://github.com/PokeAPI/pokeapi/blob/master/data/v2/csv/moves.csv (move 113 -> light-screen)
https://bulbapedia.bulbagarden.net/wiki/Ledian (note #166)
https://pokeapi.co/api/v2/pokemon/166 (also Ledian)
https://github.com/smogon/pokemon-showdown/blob/master/data/pokedex.ts (ledian -> 116)
Although interestingly serebii disagrees listing 116 as horsea https://www.serebii.net/pokemon/nationalpokedex.shtml though perhaps I'm just looking at the wrong page or something.
The simulator could add these 'num' fields to replies so that moves / pokemon can be looked up in an external source(s) without faff. As the change only adds some data to existing replies the change should be backwards compatible assuming existing clients discard extra data rather than explode.
eg.
This would make it much easier to integrate using the simulator in to other larger systems :)
Excerpt from https://github.com/smogon/pokemon-showdown/blob/master/sim/SIM-PROTOCOL.md
Code:
"moves": [
{
"move": "Light Screen",
"id": "lightscreen",
"pp": 48,
"maxpp": 48,
"target": "allySide",
"disabled": false
},
],
[...]
{
"ident": "p2: Ledian",
"details": "Ledian, L83, M",
"condition": "227/227",
"active": true,
"stats": {
"atk": 106,
"def": 131,
"spa": 139,
"spd": 230,
"spe": 189
},
"moves": [
"lightscreen",
"uturn",
"knockoff",
"roost"
],
"baseAbility": "swarm",
"item": "leftovers",
"pokeball": "pokeball",
"ability": "swarm"
},In building on top of this I'd like to look up data about what the move(s) and/or pokemon are for the AI to make decisions on. For example their types, damage or whatever. There are a few ways that come to mind:
- I parse the pokemon-showdown data files & lookup move data myself (from Golang reading typescript is pretty awful)
- the simulator / binary could include an extra tool for returning data (eg. `pokemon-showdown data move lightscreen` or `pokemon-showdown data pokemon raichu`) -- running OS commands from another language is somewhat awful, but this is probably the most backwards compatible and easiest solution
- I look up the data in another source like https://pokeapi.co/ using the information I'm given
This one is the most obvious, but the problem here is the pokemon & moves name(s) as given in `details` `ident` & `id` do not map directly to names that the pokeapi uses. For example 'lightscreen' is understood in the pokeapi as 'light-screen'
200: https://pokeapi.co/api/v2/move/light-screen
404: https://pokeapi.co/api/v2/move/lightscreen
Given the data I have I could make some guesses at the name as understood by PokeAPI, or I could in theory keep a data set mapping names between the two systems perhaps dynamically form a mapping by reading all moves & pokemon from PokeAPI on startup. However this seems a bit silly when both systems share the same 'num' IDs for pokemon & moves which look to be valid across multiple platforms .. which seems infinitely nicer.
Examples:
https://github.com/smogon/pokemon-showdown/blob/master/data/moves.ts (move 113 -> lightscreen)
https://github.com/PokeAPI/pokeapi/blob/master/data/v2/csv/moves.csv (move 113 -> light-screen)
https://bulbapedia.bulbagarden.net/wiki/Ledian (note #166)
https://pokeapi.co/api/v2/pokemon/166 (also Ledian)
https://github.com/smogon/pokemon-showdown/blob/master/data/pokedex.ts (ledian -> 116)
Although interestingly serebii disagrees listing 116 as horsea https://www.serebii.net/pokemon/nationalpokedex.shtml though perhaps I'm just looking at the wrong page or something.
The simulator could add these 'num' fields to replies so that moves / pokemon can be looked up in an external source(s) without faff. As the change only adds some data to existing replies the change should be backwards compatible assuming existing clients discard extra data rather than explode.
eg.
Code:
{
"move": "Light Screen",
"id": "lightscreen",
"num": 113,
"pp": 48,
"maxpp": 48,
"target": "allySide",
"disabled": false
},
[...]
{
"ident": "p2: Ledian",
"details": "Ledian, L83, M",
"condition": "227/227",
"active": true,
"num": 166,
[...]This would make it much easier to integrate using the simulator in to other larger systems :)
Last edited by a moderator:
yep that will help. The only concern I'd then have is around version mismatch if the showdown version I'm using as a lib and the published files differ - though this is really only an issue if data is removed from the data files between versions, as otherwise I'd still find the information I'm looking for when I search it. Thanks Zarel.