Kaphotics

I've added something to sort the database when it initially loads, via the program settings. Try it out on the bleeding edge build -- https://projectpokemon.org/home/files/file/2445-pkhex-development-build/ The existing logic would sort by the slot identifier string; when viewing dumped pkm files, would be based on the filename. Slots in save files would be named after their box/slot & save file, matching the order in the save file. The new "Identifier" option replicates that behavior. The new "SpeciesForm" will just order by Species->Form->Identifier. I have more than 100k files for my database; sorting them slows down the loading of the database, hence why the default option is disabled. Try to rely on the search options & advanced filters more than visually scrolling

Outside of the PKHeX program is not controlled by PKHeX. You can sort your folders however you want. In Windows's File Explorer, you can click on the column titles to change the sort order.

Refer to the timestamp at the top of PKHeX's window, indicating the version is from May. Palkia was captured in July. Palkia is not a persistently-available Pokémon in GO. PKHeX's database (as of May) does not have any entries for future availability. It's legal with current-date legality databases, which will come in a future PKHeX update (probably in a few hours, actually).

The required .NET Framework version hasn't changed since 2017, so a download from 2018/9 won't really do you any good

Already reported and fixed, will be fine in the next release. https://github.com/kwsch/PKHeX/commit/7ee60d9e98ea6902733e40435c78de1f9e5da876#diff-5f2545732600db97b50b7bc2a2214cbc60c4689ce5a887f144930dae611e52d4

The dumping logic adds in the swarm slots after the base slots are dumped; issue is, there are two "Dark Cave" tables with the same ID, and the "First()" call returns the high-leveled dark cave instead of the low level one where the swarm is present for. https://github.com/kwsch/PKHeX.EncounterSlotDumper/blob/8f3a5ce58f3318fd3a6ce8732d97445f29526df7/Gen4/Dumper4.cs#L292-L298 https://github.com/kwsch/PKHeX.EncounterSlotDumper/blob/8f3a5ce58f3318fd3a6ce8732d97445f29526df7/Gen4/Dumper4.cs#L702-L746 I need to check if there's any other instance where a parent location ID has multiple tables, then ensure that the correct table gets the correct swarm mutations to slot0/1/etc. edit: just marill and dunsparce have multiple tables/location. Need to have a small workaround and redump Resolved on latest commit: https://github.com/kwsch/PKHeX/commit/fc03076093dbafb1bd9741b99d8d3570043aaa82

fixed on latest

Already behaves fine on the latest commits; was fixed before any of this was reported.

PKHeX calculates stats for whatever the regular mainline game stats should be. The game doesn't always store the calculated stats in all formats. For generation 3, boxed PKM data is stored without stats, so withdrawing in-game will cause the game to re-calculate, and depositing via PKHeX will discard whatever stats are calculated. PKHaX exists to skip some user-convenience logic like stat calculation and ability list narrowing. Use responsibly.

Already been reported and fixed. Either wait for the next release or use the dev testing build in the meantime.

Probably not a clean installation (dll should not be present).

If only there were told built in to the program...

Was an error log saved next to the executable? PKHeX requires writing to the disk for settings / etc. If it's unable to do so, it could be why it's failing. The program could be blocked by antivirus or blocked in general, or the external drive could be readonly, can't tell if no error report is saved.

Best way is to check the Pokémon's data using PKHeX's legality checker. It's better than the official online-checker in 99.999999% of all cases.

If only a sticky was posted. https://projectpokemon.org/home/forums/topic/40006-issues-with-pkhex-read-this-first-swsh-update/

> BulkImporter.BulkImporterPlugin.AddToBoxesButtonClick This isn't PKHeX. Go ask whoever made your plugin.

Thanks, fixed in latest commit: https://github.com/kwsch/PKHeX/commit/0e9d0886a9f9a7efda7bf329ee20f3e0ef4b2895

length is 1 byte too small?

The uploaded save file contents is all zero. There's nothing in the file. Saving twice only applies to gen3/4 due to the wear protection flipflopping which save is the most recent.

> Pokemon Light Platinum PKHeX does not support ROM Hacks.

As previously mentioned, this is not a bug with PKHeX, rather the VC->7 transporting logic by the official methods. They copy the VC PP, and do not update it to the new maximum PP or heal the PP when it is set into the box. This can be "fixed" by just healing the pkm in-game. PKHeX is correctly flagging them as not-legal, because depositing a PKM into the box in-game should automatically heal the PP, but transporter forgets.

The game didn't make those changes; it's protecting itself against random bitflips that may yield a corrupt game state. Changing a value is fine, but you have to update the checksum so the game doesn't freak out.

Checksums exist to detect if things are corrupted. If things are corrupted outside of the game's control, it wipes the data.