Leaderboard

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

Sorry for the necropost, but I think I won't be the only one stumbling into this problem and searching got me to this thread, which doesn't have a clear (user friendly) answer to the issue. Problem is that project64 (and probably other n64 emulators) don't round up savefiles to full n64 savetype filesize. In the case of pokémon stadium 2, as Kaphotics stated, project64 creates a 0x1FF00 file (130816 bytes) while PkHex expects a 0x20000 file for (USA/INT) stadium 1 and 2 savefiles (131072 bytes). One can manually solve this manually with any hex editor or file padder. I went ahead and coded a simple app that will pad n64 savegames to the nearest savetype (depending on the input savefile). Originally I only intended to make it pad the stadium savegames, then I saw Japanese Stadium 1 (or stadium 0) uses a different savetype, so I went ahead and made a more general app that can work with any n64 savegames. Just drag and drop a savefile onto the .exe file and you will get a file with the "_pad" suffix added to it. n64savepad.zip