Fix special accuracy/power values

[encukou]

Reported by Eevee on 2009/11/24 00:15:17 +0000 · Migrated from Redmine issue 124

---

Power is sometimes 0 or 1. Accuracy is sometimes 0. It’s not entirely clear what these are supposed to mean, especially when there are already multiple other places to specify ‘special damage’ or ‘no accuracy check’ or whatever.

Redmine metadata:
Updated on: 2011/02/26 03:36:21 +0000
Start date: 2009/11/24
Relations:
    relates #317

---

Comment by Eevee from 2010/04/13 19:28:44 +0000

Target version: 9 ⇨ 8

---

Comment by Eevee from 2010/04/13 20:03:07 +0000

category_id: None ⇨ 6

---

Comment by Eevee from 2010/04/13 20:03:53 +0000

Target version: 8 ⇨ 2010 Q3

---

Comment by eric the espeon from 2010/04/15 17:02:40 +0000

Would putting “variable” (maybe a shorter word would be better) or something like that with a link to exactly how the power is calculated make sense for things like Grass Knot? And for self/field targeting moves — or n/a makes more sense as an acc value imo.

---

Comment by Eevee from 2010/04/15 17:11:42 +0000

Yeah, the idea was pretty much to just figure out when it should be “n/a” and when it should be “varies”. I would assume 1 means varies and 0 means no damage, and 0% accuracy means no accuracy check, but I haven’t actually checked that. If that’s the case, this is really just a display bug.

The move effect, of course, always explains how the power is calculated.

---

Comment by En-Cu-Kou from 2010/09/03 13:26:34 +0000

For power, 0 means “no damage”. This can be checked easily:

[m for m in moves if (m.power == 0) ^ (m.damage_class.name == 'None')] == []

1 means varies (just hand-checked); IDK if any other values mean ‘varies’ as well but it’s unlikely.

The following I did not check throroughly:
As far as accuracy goes, the value doesn’t matter at all. It can be 100% (Struggle) or 0% (Pain Split) – the game code probably doesn’t check it at all. But when it’s 0%, it’s a sign that the move effect will ignore accuracy. Rendering 0% as “n/a” would make sense.
The “Rolls Accuracy” flag doesn’t matter either. See for example Swift or Pain Split, where veekun’s flag text and move effect text currently contradict each other ().
What actually matters is the move effect, the other places are most likely leftovers from previous generations (I assume the flag is ripped from the ROM?).

---

Comment by Eevee from 2010/09/12 23:17:46 +0000

So, without ridiculously complicating the schema, the following seems to be sort of more correct:

• NULL accuracy should mean “doesn’t roll accuracy”. 0 accuracy should mean “never hits”.
• NULL power should mean “power varies”. 0 power should mean “no damage”.

The uses of NULL are a bit different, but in both cases they mean “the usual system doesn’t apply”.

BTW, we found out the “rolls accuracy” flag is actually about Mirror Move. Durp. So it’s completely irrelevant to this.

Then the Web side can render NULL accuracy as “—” or something, NULL power as “varies” or something, and everything else verbatim. Good?

---

Comment by En-Cu-Kou from 2010/09/13 04:05:09 +0000

Wouldn’t it be better to keep it how it is in the ROM? I think the pokédex library should stay “close to the metal”.
Advantages:

• Ease of checking against any other resource: The 1 for “power varies” is pretty much everywhere.
• Keeping the ripping script cleaner: The UI will need special-casing either way; why not just have one place where the code is complicated? (I’m not familiar with the ripping script, I don’t even know if there is one, but there might be some uses of the raw data, and introducing NULLs will complicate them without simplifying anything else.) Related to that:
• Poor NULL is abused enough as it is. Why give it two new meanings, which have to be explained somewhere? The current system is good. Used everywhere, pretty standard and non-intrusive (I’m quite surprised you’ve only discovered it now, after making pokédexes since RBY).

The special-case numbers don’t matter, the game doesn’t seem to check them. The reason for the 1 for “power varies” is most likely that in Red and Green there was no Physical/Special/Other category, and the game needed to know what’s damaging and what’s not. Encoding the fact that the game doesn’t check the number into the database sounds iffy.

Besides, how would you find the moves that should have Accuracy set to NULL? Struggle, for example, doesn’t roll accuracy, but is listed as 100%.

Keep it simple.

---

Comment by Eevee from 2010/09/13 10:32:52 +0000

The database should reflect the data, not whatever whim Game Freak had about how to store it themselves. The inconsistency between 0% and 100% accuracy is exactly one of the reasons why; how on earth am I supposed to fix the UI when the data is bogus?

It’s not just the UI that would be complicated here; it’s anyone else building a UI, too. Crazy data problems should be solved in the data. If it ever needs redumping, well, we can do that pretty easily.

---

Comment by En-Cu-Kou from 2010/09/14 12:26:48 +0000

If “the database should reflect the data”, there are still problems – mainly because there’s only one NULL in SQL but many special cases in Pokémon. Solving that problem by arbitrarily assigning one to be NULL and the other to be a special-valued integer leaves the problem only half-solved; and what’s worse, there’s no room for future updates to the model.

And there sure are possible updates.
There are variable-power moves that do have a reasonable number in that column: from Facade, Bug Bite, Brine, etc. to Rollout, Spit Up or Punishment. Why don’t those get special treatment?
I wanted to suggest going all the way by having min_power and max_power (that would even allow queries like “power can be ≥ 80”) – but it wouldn’t work either. There are more flavors to “power varies”. It can be that only the base power varies and the usual damage formula is used (Hidden Power, Facade, Magnitude), or that some other formula is used (Sonicboom, Bide, Psywave, Fissure).

That brings us to four special cases now (no damage, variable BP with default, variable BP with no default, and variable without BP, in addition to the “normal” case). Game Freak’s data merges two, you suggest using NULL for one and GF’s representation for all others.

Moving away from move power: For moves that don’t roll accuracy, are you planning to remove the distinction between moves marked 0% and 100%? Are you sure there’s no significance to that distinction? I’m reasonably sure it doesn’t matter in battle mechanics, but that’s it. There’s some data there, and after your efforts of both preserving original flavor texts and making them usable I find it hard to believe you’d want to just erase it.

And, are you planning to set Shedinja’s Base HP to NULL? That one doesn’t use the standard formula either.

…

It’s a question of the scope of the project.

Smogon’s damage formula page has a clear distinction between moves that use base power (in the frst table) and those that use a different formula (listed at the very end). It ignores the “BP=1/BP=reasonable number” distinction altogether. That doesn’t make it a bad page. It has a “human” feel to it – somebody’s prepared the data, looked at all the fine points, categorized and explained everything.
If veekun was like that, I would not trust it. That “human” feel tells me that there will be errors in the numbers somewhere, because it’s just not ripped straight from the game. The reason I use veekun is because it has the raw data that nobody’s played with; it leaves the interpretation to the reader. I go to Smogon beause it has high-quality explanations of the special cases, fine points and general mechanics.
It’s perfectly okay if you want to let veekun have some of that “human” aspect, but please don’t lose the machine precision in the process.
Stick to having data straight from the game in the database, and leave the interpretation to the UI. Or add a flag/column to make it clear that this column contains research-based, “unofficial” data.
Defining the project this way would, at least, help make it more objective than a vague, subjective “the database should reflect the data”.

(Disclaimer: Those are, of course, my opinions. You’re the one steering veekun.)

---

Comment by En-Cu-Kou from 2010/10/03 07:26:48 +0000

I guess Nintendo solved most of this for us, 101 accuracy should be NULL. Still, be careful about the power.

Anyway, in the same spirit, berry_flavors has a lot of zero rows that should probably just be removed.

---

Comment by En-Cu-Kou from 2010/10/03 09:10:23 +0000

Also item costs should be NULL when the shops don’t take the item.

---

Comment by En-Cu-Kou from 2010/10/03 14:24:53 +0000

And the gender rate should be NULL for genderless species.

---

Comment by Eevee from 2010/10/07 01:59:14 +0000

Target version: 2010 Q3 ⇨ —

---

Comment by Eevee from 2010/10/08 08:00:27 +0000

Assignee ⇨ —

---

Comment by Zhorken from 2011/02/26 03:36:21 +0000

Sooo I’ve fixed #317 without actually changing anything in the db, so whenever this side of the issue does get fixed, remember to update spline-pokedex too.

[CatTrinket]

Oh. I fixed this a while back. Weird power is always null and we determine whether to display * or — based on damage class. (And weird accuracy has been null ever since B/W.)