Crystal Headbutt Heracross incorrectly reported as illegal

[oleombruni]

Describe the problem A Heracross caught in Azalea Town via Headbutt is incorrectly reported as illegal in the latest version of PKHeX (20210406).

To Reproduce Play an English version of Pokémon Crystal with a TID ending in 5 (I used a female trainer with TID 25505). This results in the following Headbutt Azalea Town map:

Headbutting the two valid starred trees will result in drawing from the "high-encounter" pool, which in Crystal contains a level 10 Heracross. Any Heracross caught in this way is flagged as illegal in PKHeX.

I've included in this zip file both the .pkm file of an incorrectly-reported Heracross and the save file in which it was caught. The save file contains three Heracross (two caught in the tree circled in the screenshot above, the other caught in the other valid tree) along with a Spearow and Aipom caught from the same trees, which are instead correctly marked as legal.

Expected behavior The described Heracross should be reported as legal.

Additional context This is the complete legality information provided by PKHeX for the provided .pkm file:

Invalid: Could not find a tree for Crystal headbutt encounter that matches OTID.
===

Valid Move 1: Learned by Level-up.
Valid Move 2: Learned by Level-up.
Valid Move 3: Learned by Level-up.
Valid Move 4: Learned by TM/HM.

Valid: Nickname does not match another species name.
Valid: Current level is not below met level.
===

Encounter Type: Wild Encounter Headbutt, Special (Heracross)
Location: Azalea Town
GameVersion: C
PID Type: None
Other match(es):
Invalid: Could not find a tree for Crystal headbutt encounter that matches OTID.

[kwsch]

PKHeX uses a list of possible tree coordinates to build a possibility list for the location.

https://github.com/kwsch/PKHeX.EncounterSlotDumper/blob/50c53d6b33983a12606a3a6a414ec7e738cad7b8/Resources/gen2/trees.json#L191

Will have to double check the list to see if all trees are in it. It's manually entered, and there have been errors in the past 😅

[oleombruni]

Yeah I checked and the affected trees are already in the list, in the case of TID ending in 5 they are (25,11) and (35,12). I'm going to check if the same behavior occurs with other TIDs.

[oleombruni]

It appears that only the TIDs ending in 5 have this problem, and only in Azalea Town (Heracross caught in Route 42 or 44 are flagged as valid, while Route 33 doesn't have valid Headbutt trees for TIDs ending in 5).

[kwsch]

https://github.com/kwsch/PKHeX/blob/f8a2bb3229c41faad3715b7cddc7914c7bc074ec/PKHeX.Core/Legality/Encounters/EncounterSlot/EncounterSlot2.cs#L45

10 bits for regular, 10 bits for rare.

0x3DF:

11110 11111

Indicates that an ID of *5 would not be able to get one of the rare trees.

Per your attached screenshot, the row of 4 trees have the coordinates:

{ "X": 24, "Y": 11 },
{ "X": 25, "Y": 11 },
{ "X": 26, "Y": 11 },
{ "X": 27, "Y": 11 },

These trees give the Rare slots for:

9
2
4
7

The first row of trees give 1 for all, [28-33,4] give 0-3,8/9, and the row at 12 give 036813. No 5; so the calculation yields the same value we see in PKHeX.

I fiddled with the website to see how the ID=>Index mapped, and it looks like things are off by 1. A TID of 0 yielded the first top-left tree, 1 yielded the second, 2 yielded the 3rd... so it wasn't just an off-by-one.

I saw in the website, it was biasing each of the X/Y coordinates with 4.

I'll have to check player coordinates in RAM to see if the assumption of the map's top-left being (0,0) is actually true or not. The disassembly calls GetFacingTileCoord when obtaining the tree tile position. If things are indeed biased by 4 for each coordinate, will just need to re-run the dumper.

[kwsch]

For reference: coordinates in G2Map:

[oleombruni]

Interesting, so that website has the coordinates biased by 4. I can pretty much assure you that the trees marked by the website are the correct ones, as I often use Heracross in my Crystal playthroughs and I always referred to that website to catch one in Azalea Town. I just tried changing the last number of my TID right now and I found Heracross in the trees marked by the website every single time (and every single Heracross is marked valid by PKHeX, except the ones caught with TID ending in 5, you can find the save here).

[kwsch]

Looks like the game converts player coordinates (0 indexed) to padded coordinates, and uses the padded coordinates in the calculation (rather than the unpadded).

https://github.com/pret/pokecrystal/blob/5db892782adaa5bb5a3e4cd6fa06565764bd1fb0/engine/overworld/player_object.asm#L74-L84

https://github.com/pret/pokecrystal/blob/e791c5392b19f589c51afd98666d19e778278847/home/map.asm#L1778-L1788

Assumedly this helps in preventing underflow, since no maps are >200, so pad by 4? Heh. Guess I'll have to re-generate the tree permit bits.