encukou/test-0 — Issue #76: Add 'evolution' and 'trading' as move methods in Pokémon search
Author: encukou
Created: 2011-11-03 19:28:52+00:00
State: open
Labels: feature, high-priority, involved, lists and searches

**Reported by [Eevee](http://bugs.veekun.com/users/1) on 2010/05/17 15:26:19 +0000 · Migrated from [Redmine issue 271](http://bugs.veekun.com/issues/271)**

---

Tricksy but seems more correct.

Evolution should also look for moves on any *prior* evolution.

Trading is more complicated:

- The current behavior is to find any moves in any selected version. This is sort of useless. The semantics should be that it’s actually possible to get all the moves, somehow, on at least one of the selected versions, at the same time.
- With ‘trading’ enabled, trading between compatible games should also be considered legitimate, which would *almost* restore the current sematics but actually guarantee that it can happen—i.e., acknowledge that Gen II can’t trade with Gen III.

Both should be subject to other method constraints. When both are checked, trading and then evolving should also work.

Tricky case from EnCuKou: it’s impossible to have a Ralts with Encore and Body Slam, because Encore is only available as a Gen IV egg move, and Body Slam is only available as a Gen III tutored move, and you can’t trade from Gen IV to Gen III. Some evolution can probably be thrown in here to make it more convoluted.

More testcases or pseudo-methods welcome. Would it ever be an issue that evolution is one-way?

Addendum: It sounds like I’m going to have to actually build instructions for how to get a Pokémon with moves X Y Z W.

Redmine metadata:
Updated on: 2010/10/08 08:01:03 +0000
Start date: 2010/05/17
Relations:
relates #628
duplicated #334

---

**Comment by [En-Cu-Kou](http://github.com/encukou) from 2010/05/17 16:48:29 +0000**

The bug description doesn’t mention one big change: if you’re taking my tricky case into account, it means we’re searching for movesets, not for individual moves. Consider making it selectable (any of these moves/all of these moves/all at the same time)? Also think about the current “only these/any with the same effect” option (a very scary thought)…

Anyway, since it’s full movesets, the usual constraints will apply to egg moves, e.g. Tentacool can’t have both Rapid Spin (egg move from Squirtle via Kabuto) and Mirror Coat (egg move from Corsola) together. Basically, a breeding chain finder is a prerequisite here.

Note that this also applies to single moves, as some egg moves are/have been unobtainable: Magcargo can’t get Heat Wave (at least according to old veekun breeding chain finder); yet the current search finds it.

* * * * *

Don’t forget ‘Sketch’ as pseudo-method (\#205).

And event moves would be very nice to have – after all, you do have data about a species called Arceus that you can’t get in-game…

* * * * *

Minisummary from IRC:

If searching by learn-method, and Heart Scale ≠ Level-Up, evolution being one-way matters (e.g. Arcanine’s Extremespeed). This HS/Level-up distinction would be nice to have.
Also, there maybe might be pokémon that learn different moves at same level in different versions, so they can only learn one of those even if you can trade both ways. (Again not a problem if Heart Scale is cheap)
And there’s no Heart Scale in RBYGSC. There is Stadium 2 that can act similarly, but not everybody has an N64.

---

**Comment by [En-Cu-Kou](http://github.com/encukou) from 2010/05/18 08:00:30 +0000**

Also, it might be important that a pokémon can only learn 4 moves: the move-induced evolutions can’t keep four egg moves (unless one is the one they evolve by). Not sure if this is relevant to any current pokémon, but even if not it would be something to check for in new generation =\> better to take care of it now.

* * * * *

Proposed solution:

* Stage 1: Add the ‘evolution’ method directly to the database.
Yes, I know redundancy in tables is not a good thing, but this would serve good purpose IMO. It would make the database much more usable without the Python coding around it, which was IMO one of the reasons for CSV (?).
It would be easy to get a query with only false positives (sans Sketch). This means that move search would work okay-ish right now.
Also I’d add `pokedex check`, which would check the integrity (and add/remove bad/missing values, if asked); `pokedex setup` should call it.

* Stage 2: Whip up a moveset legality checker. I can’t imagine doing this in SQL, so we’d probably want to take the list from the previous stage and go through the pokémon one by one.
Probably base it on some state-space traversal algorithm. This looks like an interesting problem :)

---

**Comment by [Sanky](http://bugs.veekun.com/users/19) from 2010/05/18 08:47:57 +0000**

Don’t forget that you can’t trade (or migrate) Pokémon with HMs onto Gen IV. I think the only situation this matters in is Dive.

---

**Comment by [Sanky](http://bugs.veekun.com/users/19) from 2010/05/18 08:52:12 +0000**

Disregard that, because there’s a move tutor now (I’ve been out of the loop). Still worth mentioning when you search by game, though.

---

**Comment by [magical](http://bugs.veekun.com/users/11) from 2010/05/19 00:41:26 +0000**

Redundancy :/

The reason for using csv is to be database-agnostic.

---

**Comment by [Eevee](http://bugs.veekun.com/users/1) from 2010/05/19 01:25:50 +0000**

Ummmmm I’m not really a fan of un-normal data without a good reason. Suddenly I’d have to keep evolution and other moves in sync, which sucks in the case of errors.

---

**Comment by [Eevee](http://bugs.veekun.com/users/1) from 2010/08/17 01:59:51 +0000**

Project: veekun-incoming ⇨ spline-pokedex

---

**Comment by [Eevee](http://bugs.veekun.com/users/1) from 2010/08/26 01:51:44 +0000**

Who on Earth thought this would ever happen in Q2?

Someday! Maybe after I figure out what Q3 will even be.

category_id: None ⇨ 17
Target version: 2010 Q2 ⇨ —

---

**Comment by [Eevee](http://bugs.veekun.com/users/1) from 2010/10/08 08:01:03 +0000**

Assignee ⇨ —