Kaphotics

Fixed the save detection issue, thanks for reporting! https://github.com/kwsch/PKHeX/commit/c3e0d5339cfafa27fdfbd8e58c6cf90745e20fe9 OT name and strings show up correctly on latest commits (was previously reported).

Fixed, thanks for reporting! https://github.com/kwsch/PKHeX/commit/4d91aad8765758e6cd6992444da4e5c89280bf78

Language is not stored in gen 1/2 files; the drop-down is only provided for nickname resetting purposes. PKHeX doesn't load anything from that drop-down.

VC games can trade from GS to RBY then can be imported to Gen7. Version for VC pkm is whichever game transferred it, as that value isn't stored in gen1/2 format. PKHeX detects your Charizard as being originated from an egg, as it's the only way the move is legal.

Would need research, and won't be editable within the GUI (in other words, I'm not implementing this in PKHeX even if someone documented it).

There's a bunch of missing locations for C/XD encounters due to the rebattling at another location. It doesn't really matter after transfer to Gen4+ (location is reset to Pal Park), but we can always add more location entries to the encounters file. https://github.com/kwsch/PKHeX/blob/0120263bd3d56603c703d91521ba62a3a1a6e61b/PKHeX.Core/Legality/Encounters/Data/Encounters3.cs#L416-L424 You can check the location ID by loading the pkm to tabs, then opening the batch editor, then selecting Met_Location from the dropdown. The location ID's value should be shown in a label above the textbox.

Click on the triangle next to the preview sprite. The program tells you why they are not legal. > PID and encryption constant were both re-rolled PID-IV relationships are a thing in gen3/4.

Careful, Gen3 has save block shuffling so absolute offsets won't indicate where the data is. Would need to know which save block & offset within block.

https://github.com/pret/pokeruby/blob/d9e59a388c7c4b2464769963b3d58980ce742f70/data/maps/events/IslandCave.inc IslandCave_MapObjects:: @ 838E674 object_event 1, MAP_OBJ_GFX_REGICE, 0, 8, 0, 7, 0, 3, 8, 0, 0, 0, 0, 0, 0, IslandCave_EventScript_15EF9D, 936, 0, 0 note the 'spawn' flag at the end should work for most legendary encounters SkyPillar_Top_MapObjects:: @ 838EE50 object_event 1, MAP_OBJ_GFX_RAYQUAZA, 0, 14, 0, 6, 0, 3, 8, 17, 0, 0, 0, 0, 0, SkyPillar_Top_EventScript_15F316, 773, 0, 0 ^ rayquaza ==== https://github.com/pret/pokeruby/blob/9ba9993be18af162239838cfefe23f535e291ac0/data/scripts/maps/CaveOfOrigin_B4F.inc https://github.com/pret/pokeruby/blob/d9e59a388c7c4b2464769963b3d58980ce742f70/data/maps/events/CaveOfOrigin_B4F.inc CaveOfOrigin_B4F_MapObjects:: @ 838D880 object_event 1, 248, 0, 9, 0, 10, 0, 3, 8, 0, 0, 0, 0, 0, 0, 0x0, 825, 0, 0 Possible that flag 825 has something to do with the Kyogre/Groudon trigger spawn, can't see any other reference though. CaveOfOrigin_B4F_MapCoordEvents:: @ 838D8A0 coord_event 9, 13, 3, 0, 0x409b, 0, 0, CaveOfOrigin_B4F_EventScript_15DDD7 15DDD7 is the map calling the Kyogre/Groudon event, looks like 0x409b (event constant) should be set to 0 to reset the event? https://github.com/pret/pokeruby/blob/9ba9993be18af162239838cfefe23f535e291ac0/data/scripts/maps/CaveOfOrigin_B4F.inc#L75 Edit: can confirm that setting the above constant to 0 allows you to rebattle (sprite doesn't show, but triggers the event when you stand in front of it)

PKHeX exposes the event flags but only previously documented event flag indexes are included. All 'custom' (ie not known) flag toggling must be done in the Research Tab. Only R/S have some flags documented. https://github.com/kwsch/PKHeX/blob/78a557c3cdaa6f48b42cc96df8ccb4d20b897937/PKHeX.Core/Resources/text/other/flags_rs.txt from the disassembly: https://github.com/pret/pokeruby/blob/c47c3abe65e0e0419b691f5d0b6ea93c7b972191/include/flags.h You can figure out what flag does what (ie respawning legends) by either looking at the game's disassembly (which flag ID is being checked in the event script) or you can do a before/after comparison in the research tab.

It's working as intended. PKHeX's 'rand' PID does not generate a PID-IV combination; it only generates a valid PID based on nature/ability/gender when appropriate (for older generations). The legality checker flags illegal data. If you would like to find a valid PIDIV, use RNG Reporter as there are many more things to consider than PID-IVs (such as encounter slots and possible nature/gender locks in the case of Colosseum/XD). RNG Reporter works fine as a standalone; I don't think it's a good use of my time replicating these features if they already work in another program.

PKHeX can edit event flags / variables in gen3, but not everything is documented.

thanks, fixed https://github.com/kwsch/PKHeX/commit/c2567864676e421b91b75d66ffbdea16e2f875f1

PKHeX checks for Espeon 7 frames after Umbreon. https://github.com/kwsch/PKHeX/blob/4b135902f3be2604596d95b93ca2bc1ecfeb45fc/PKHeX.Core/Legality/Checks.cs#L874-L903 Try generating RNGReporter frames with the TID/SID entered in

Thanks, updated in latest commit: https://github.com/kwsch/PKHeX/commit/4b135902f3be2604596d95b93ca2bc1ecfeb45fc

Fixed, thanks https://github.com/kwsch/PKHeX/commit/9c924727239951d08363cbf31935af52e53333fb

set by script files, not currently changeable set by script files afaik, not currently changable unable to replicate on current version; all ability changes are saved. I assume you are checking already captured pkm; the pkm file stores the current ability ID, not 0/1/2-Hidden. Capture something and you'll see the new abilities.

Should be resolved in the latest commit (by only writing the OT if it is modified). https://github.com/kwsch/PKHeX/commit/1a343ead85e4fa2e9006dfec2df7b7ac38c42e5d Thanks for bringing this to my attention

The game checks for the starter pikachu in party as follows: https://github.com/pret/pokeyellow/blob/793c715ba253e08d2807d04d128765ca305d6b15/engine/pikachu_status.asm#L1-L46 checks TID, OT, and species ID OT trash bytes got changed (padding zeroes overwrote the remaining spots)

Was fixed shortly after the last release: https://github.com/kwsch/PKHeX/commit/756f9bb8dc808ddee144a3959ad806cd5f2c2bc4 Ignore the error for now; I'll probably post a new version in the next few days.

In text_Char_zh.txt I see Ｑ near the very end. Looks like Ｚ：・Ｑ (4 characters) may be suspect. I'll try and investigate this more later, unless someone else figures it out before then

=IdentifierContains=1234 Was added back in February but isn't really documented: https://github.com/kwsch/PKHeX/commit/065795cdbea6a8277c35030f697de38b9de6f7a8

1->7 uses a special encoding table, I assume it will be updated when transporter is updated to support 2->7 (see jp_table and us_table in StringConverter.cs) https://github.com/kwsch/PKHeX/blob/e6f43ff629b83f25ae3e514f0d3f931c773a06e0/PKHeX.Core/PKM/StringConverter.cs#L584-L591 basically an array of 'transferred' characters that is accessed by the gen1 encoding value. Anyway, added 6 more jpn gen2 characters to the encoding table https://github.com/kwsch/PKHeX/commit/e6f43ff629b83f25ae3e514f0d3f931c773a06e0 no legality checks right now to check for characters not selectable for gen1; could be useful in weeding out gen1 origin encounters (pls lmk if there's any missing chars for the lookup table, I think I got them all?)

Thanks, fixed in latest commit! https://github.com/kwsch/PKHeX/commit/b201ded8e86f788a2b9059cb0fccf7635963274c For user ease, PKHeX maps both the uppercase and lowercase characters to the same value even though only one naturally exists in the character encoding table. There are other cases of this, as listed in the commit message. Flipped it to map back to the uppercase character not the lowercase.