Skip to content

Add XD Encounters, Encounter Conditions, Locations, Location Areas, Encounter Methods, and a few more things#1446

Open
notblisy wants to merge 4 commits intoPokeAPI:masterfrom
notblisy:xd-trades-encounters-conditions
Open

Add XD Encounters, Encounter Conditions, Locations, Location Areas, Encounter Methods, and a few more things#1446
notblisy wants to merge 4 commits intoPokeAPI:masterfrom
notblisy:xd-trades-encounters-conditions

Conversation

@notblisy
Copy link
Copy Markdown
Contributor

The goal of this PR is to add all the encounter locations, conditions, and items for Pokemon obtainable in Pokemon XD: Gale of Darkness.

This is a fair bit larger than Pokemon Colosseum, as there's 82 Shadow Pokemon in this game, plus a few extra gift Pokemon.

I sourced my data from:

For the encounters, I added the usual:

  • Locations
  • Location_Areas
  • Encounter_Slots
  • Encounters
  • Pokemon_items

In addition to all the relevant prose for these.

On top of that, I've added a new encounter method:

  • Pokespot

This is a unique way to catch wild Pokemon in XD, where you leave a snack out for a Pokemon, and one of 3 different Pokemon can come to eat it. Then you get to do a wild battle and capture.

During my time modeling XD, I noticed that while there IS an NPC-Trade option in encounter_methods.csv, this doesn't allow us to note WHICH Pokemon the player would have to trade. So, I added a new encounter condition called:

  • trade

Then, in encounter_condition_values.csv I would describe both the NPCs name and Pokemon to trade them.

An example is that for a larvitar, duking wants a wooper. So I have the encounter condition value id set to:

  • 112,15,trade-duking-wooper,0

Encounter conditions seem to be rarely used so far in the API, but I think they are a great way to add specificity to encounters like trades or gifts outside of just locations. I hope this was okay to add!

@notblisy
Copy link
Copy Markdown
Contributor Author

I think that for encounter condition value map I might have put the wrong value? Is 0
Or 1 what it needs to be for the condition to be true?

@Naramsim
Copy link
Copy Markdown
Member

Hi! Thanks for the PR! I see where you want to go but I don't think adding a new encounter method is a good long term solution. We should expand the current npc-trade encounter method to take into account other details, such as which pokemon to trade in and to which npc. It's fine to model it first and then add the data in later.

Let's take an example. https://www.serebii.net/sunmoon/ingametrades.shtml A machop that is traded for a Spearow in Alola. We have this info here: https://pokeapi.co/api/v2/pokemon/66/encounters (search for npc-trade):

encounter_details: [
  {
    chance: 100,
    condition_values: [ ],
    max_level: 9,
    method: {
      name: "npc-trade",
      url: "https://pokeapi.co/api/v2/encounter-method/36/"
    },
    min_level: 9
  }
  ],
max_chance: 100,
version: {
  name: "sun",
  url: "https://pokeapi.co/api/v2/version/27/"
}

We should expand the details in the condition_values list, I think. So it's better to use the encounter method npc-trade, add new encounter conditions trade-in-pokemon and trade-to-trainer. Then add the encounter_condition_values. It's a huge job.

Or, we could re-think the mechanism for trading, trading is not really encountering a pokemon.

I think these are the two options we have:

  • do as we always did, using the npc-trade and not having the required conditions such as the trader and the pokemon to trade
  • implement and discuss together the best logic expanding from my thoughts above.

@Naramsim
Copy link
Copy Markdown
Member

I think that for encounter condition value map I might have put the wrong value? Is 0
Or 1 what it needs to be for the condition to be true?

It should be 1

@notblisy
Copy link
Copy Markdown
Contributor Author

notblisy commented Mar 25, 2026

Hi! Thanks for the PR! I see where you want to go but I don't think adding a new encounter method is a good long term solution. We should expand the current npc-trade encounter method to take into account other details, such as which pokemon to trade in and to which npc. It's fine to model it first and then add the data in later.

Let's take an example. https://www.serebii.net/sunmoon/ingametrades.shtml A machop that is traded for a Spearow in Alola. We have this info here: https://pokeapi.co/api/v2/pokemon/66/encounters (search for npc-trade):

encounter_details: [
  {
    chance: 100,
    condition_values: [ ],
    max_level: 9,
    method: {
      name: "npc-trade",
      url: "https://pokeapi.co/api/v2/encounter-method/36/"
    },
    min_level: 9
  }
  ],
max_chance: 100,
version: {
  name: "sun",
  url: "https://pokeapi.co/api/v2/version/27/"
}

We should expand the details in the condition_values list, I think. So it's better to use the encounter method npc-trade, add new encounter conditions trade-in-pokemon and trade-to-trainer. Then add the encounter_condition_values. It's a huge job.

Or, we could re-think the mechanism for trading, trading is not really encountering a pokemon.

I think these are the two options we have:

* do as we always did, using the `npc-trade` and not having the required conditions such as the trader and the pokemon to trade

* implement and discuss together the best logic expanding from my thoughts above.

Hi, maybe I am misunderstanding, but is this not what I did? The new encounter method I added is for pokespot pokemon, not trades.

For the trades I added encounter a new encounter condition, and then 4 new values which describe which trainer to trade with and which pokemon to send them.

I think leaving NPC-Trade as an encounter method is fine. Just append them with encounter conditions to let the players know what Pokemon they should have on hand for a trade, and which NPC to speak to if they have a name.

We have the mechanism to add such details, in my opinion it's useful information to have, and encounter_conditions are the perfect way to support this.

I don't mind going back and documenting which NPCs and trainers in conditions for a separate PR. I have to do it later anyway, there's a lot of trades missing. I planned on making a few issues today for missing encounters.

Also, I don't think trade-in-pokemon, as in, trading in from another game or transferring from an older game is within scope of this idea. I was just looking at encounter conditions for the NPC-Trade encounter methods.

@jemarq04
Copy link
Copy Markdown
Contributor

I think adding an encounter condition for the Pokemon needed to trade is not a bad idea, but if a change like that is done for these encounters then a new PR should definitely be made for previous ones. While Duking is an easy enough character to recognize, not every trainer with trades in-game will have a name at all so I think a condition like that is not easily scaled.

Personally, I think that the API is not equipped to give precise information on how trade Pokemon are received (i.e. which location/NPC/Pokemon to trade) so leaving the encounter method simply as npc-trade with no conditions isn't unreasonable. If we make changes to it in the future, that can be its own larger PR.

@notblisy
Copy link
Copy Markdown
Contributor Author

notblisy commented Mar 25, 2026

I think adding an encounter condition for the Pokemon needed to trade is not a bad idea, but if a change like that is done for these encounters then a new PR should definitely be made for previous ones. While Duking is an easy enough character to recognize, not every trainer with trades in-game will have a name at all so I think a condition like that is not easily scaled.

Personally, I think that the API is not equipped to give precise information on how trade Pokemon are received (i.e. which location/NPC/Pokemon to trade) so leaving the encounter method simply as npc-trade with no conditions isn't unreasonable. If we make changes to it in the future, that can be its own larger PR.

A few things--

  1. I think encounter conditions are the perfect use case for mentioning what Pokemon you need to bring with you, personally. It'd be trade-[X-Pokemon]. To me it's no different than the conditions for X-item or X-caught-articuno, who is right before my trades. I don't really think this is out of scope for encounter conditions. There's some pretty niche stuff in there.

  2. Locations for the trade is set up fine, it's a typical encounter. We would specify which location_area, like dukings house, to trade at. To me this is no different than how a gift Pokemon works, no? You go to Dukings house to get plusle in Colosseum, for example. There's just no condition of trading him a pokemon to do it.

  3. I agree that all previous trades should have this condition met, however, there are basically no previous trade encounters documented. I made an issue here: Missing Trade Encounters #1451

We would really only have to add conditions for the gen 7 trades, so to me this isn't as big of a deal as it seems to have to add these requirements.

I am amenable to removing the NPC name from the condition, Duking is one of very few named NPCs who you'd trade with. Jasmine is another in HGSS.

If I did this it'd look like:

  • 112,15,trade-wooper,0

Does that sound acceptable?

@jemarq04
Copy link
Copy Markdown
Contributor

If I did this it'd look like:

* 112,15,trade-wooper,0

Does that sound acceptable?

I think this makes sense to me - @Naramsim what do you think?

@Naramsim
Copy link
Copy Markdown
Member

Hi, I think my previous comment stemmed from the facts that I do not yet fully grasp the difference between encounter methods and encounter conditions. It seemed to me that these aren't linked, but instead thanks to the encounter_condition_value_map they are. I tried to understand a bit more the schema and now i'm putting together the pieces.

Does it make sense to have the encounter condition listed as npc-trade, with the added npc- prefix?

And in the encounter_condition_prose.csv I'd remove the exclamation mark from the added line.

  • 112,15,trade-wooper,0
    Does that sound acceptable?

I think it is.

@notblisy
Copy link
Copy Markdown
Contributor Author

o

Encounter conditions links to encounter value maps, and encounter value map links to encounters.

They are basically little extra things you need to do to fulfill an encounter. Like a swarm or a slot 2 in the DS for a gengar in DPPt, etc.

I'll make the change to remove dukings name.

I don't think it makes sense to have it say NPC-Trade. it would then say NPC trade as location and then npc-trade-wooper as a condition. For me reading it as trade-wooper makes more sense when parsing the info. It's just the action that you take.

- Ho-Oh in colosseum actually two encounter conditions I made for XD Pokemon (complete mt. battle, catch all shadows) so I added those to it.

- Removed trainer name from the trade encounter condition as we discussed
@notblisy
Copy link
Copy Markdown
Contributor Author

notblisy commented Mar 26, 2026

removed duking and hordels name from the encounter condition values. I also added two conditions to ho-oh in Colosseum. I didn't make new ones-- I just tagged it with entries 113 and 114 which I made for XD, but also happen to be conditions for Ho-Oh.

edit: also removed the !

@jemarq04
Copy link
Copy Markdown
Contributor

Alrighty, I'll start a full review soon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants