Leaderboard

Keep in mind that this guide is for the 'main' Pokémon save type, regardless if it's played on emulator or imported using save manager. This applies to both 3DS and Switch. In the images below, Citra was used simply as a convenient way to show screenshots, do not be misled by it! Scenario 1: (can be retail or emulator, I'm just using Citra as an example) You load the game and it tells you it's corrupted, however PKHeX is able to load the save. Example What you should do: 1. Check the folder you import the save from. Your file in the folder MUST be named main (Look at the screenshot of the file folder above. Notice how my file is called main1? That's the mistake: it was incorrectly named.) 2. The files in the folder has to be exact. For 3DS: main MUST be the only file in that folder. For Switch: main MUST be in that folder. backup and poke_trade can be there, but isn't necessary. There cannot be other files in the same folder you import from, such as main.bak etc. 3. (Citra only) Also do not rename the folders that contain the main. The wonky numbers generated by Citra are the correct folder names. Changing them will screw it up. Scenario 2: Game says save is corrupted, and PKHeX is unable to load the save. Chances are, your dumped save file is indeed corrupted. Maybe there was an error with dumping the save -> redump the save, provided that you’re able to continue the game and it launches on your console. Perhaps there was an error when transferring save to PC via FTP -> if you were using FileZilla, change the setting to use binary transfer mode instead of ascii. If the steps above were not able to resolve the problem, load up an older copy of your save. Also make sure you're using latest version of PKHeX. Oh, ALWAYS keep a safe backup of your save in a completely differently folder, especially before any edits or transfers etc, so that if any corruptions occur, you always have a backup to revert to. PKHeX requires you to save in-game Note: IF you played on Citra, and used the Emulation > Save state (example below) You need to properly save the game, using the in-game menu. Open this spoiler for steps. Note - If the FTP transfer process indeed screwed up your save: For 3DS - Try using this. For Switch - There's no solution. The save is dead. The Switch encrypts the save, so missing a byte is fatal. Instances of people mucking up Notable case studies: Filezilla needing Binary Transfer Mode instead Game displays save as corrupted, cause it wasn't named correctly PKHeX won't read the save, as it is empty Changing names of Citra Folders messed up the save recognition User using emulation > save state View full tutorial

What I'll say is, use one of those free programs to check your SD card. You'll never really know if your SD is fake or bad until you check it. I'm not saying they intentionally sold you one, but sometimes stock get swapped and they wouldn't know either. Even so, the injecting of saves into the NAND resulting in NAND errors wouldn't be PKHeX's issue, but whatever save manager you're using. Any modified save wouldn't be causing NAND issues; at most the game wouldn't launch (saying save is corrupted) but the NAND would be fine.

Alright, thank you. I will try to post in more detail "guide" later today or tomorrow

I will try and get back to you after testing. For now, thank you for taking your time dealing with me.

Careful, Showdown might steal it.

So alot of people have been asking how I do animation swaps and stuff in my hacks, so I decided to post a tutorial. You will need: pk3DS (Latest Version) Ohana3DSRebirth (mariosonicds build) Step 1: Uncompress a/1/7/0 in pk3DS Step 2: Find the bin that contains the model that you want to use Step 3. Uncompress the bin in pk3DS, You should get a folder named ID_CM (ID being whatever number the file is) Step 4. Inside that folder you should see 9 bin files, copy the file named 0.bin Step 5. Find the bin the contains the animations you want to use, and uncompress it Step 6: You should get another folder named ID_CM that also has 9 bin files in it, overwrite the 0.bin in that folder with the one you copied Step 7: Pack the folder, you should now have a file named ID.CM Step 8. Rename the file to ID.BIN and replace the existing file Step 9. Repack the GARC Now you should have different animation ;). If you have any questions let me know!

Meaning 9 different scenarios (Wii, GameCube, emulator, each in PAL, NTSC and PAL60), of which 3 (the emulator ones) have only an academic purpose, while 6 are actually related to actual possible legit gameplay. I can help in a few months, but this is gonna be a LOT of work ? EDIT: PAL60 isn't supported, but NTSC 480p is. However, that should not be any different from 480i regarding timings, so we're down to NTSC/PAL on GC and Wii

Yeah all of this requires actual testing.

And let me throw another spanner into the gears while I'm at it: there may be differences between PAL and NTSC versions due to the 50/60Hz video modes, which affect timings. EDIT: I'm not sure whether the PAL version supports PAL60, but if it does, then it may be different from both PAL and NTSC.

CPU underclocking would be enough to cause weird timings. And the GC emulator may not play exactly by itself either. Then people will ask about Box emulated on PC running RS.. sigh.

There shouldn't be any difference. A Wii running in GameCube mode is virtually the same as a GameCube (same CPU architecture, underclocked to match the GameCube speed when running GameCube games).

Yeah, that was what I was concerned about. It'll make sense if the GameBoy Player attachment can emulate the ticks correctly, but I'm wondering if the GameCube can natively emulate the cpu ticks correctly. Would be amazing if someone can make a fresh save, catch a bunch a pokemon, and upload the save

Well, for what it's worth, so far, John GBA has been consistently producing Method 1 IVs for stationary encounters. As I've said in the other relevant topic: I've been playing this save on two emulators (VBA-M on PC, John GBA on Android), through Dropbox syncing, so I can actually test for differences. Indeed, if you think it's relevant, I still have an unawakened Snorlax with which I can test it out. I can capture it multiple times on both emulators and provide the resulting .pkm files. If needed, I can also inject my save into the real cartridge and do the same on GBA/SP and NDS, although restoring it multiple times to catch a meaningful sample would be a lot more work, and I assume the real cartridge behaviour is documented by now.

Yup, it would be okay as long as it doesn't get flagged

Thanks. If I don't get any flags in PKHex, I'm good enough to avoid having to double-check the IVs in RNG Reporter, right?

I don't know if it's associated with a specific emulator, but it's a known issue relating to emulators. Yeah, just double check the various entries of your stationary encounters.

This just prompted me to do a quick check-up of my recent Leaf Green playthrough on John GBA (Android). Apparently, all of my stationary Pokémon are legal. Is this a known problem with specific emulators? I occasionally play the same save on my computer, with the latest version of VBA-M (Windows x64), as I have them synced through Dropbox. I intend to write the save into my cartridge in the end and transfer any valuable Pokémon up to the current games, so should I be careful not to catch any stationary Pokémon in VBA-M, or at least double-check them?

@Narqui gosh no. I think you misunderstood the point of what I wanted to show you. That isn't what we're talking about. The problem isn't with the ROMs, rather the problem are with the emulators. They can't correctly emulate the CPU timings of NDS/GBA, and stationary encounters with Method 1 PIDIVs might end up as Method 2 or Method 4 IVs. The ROMs "aren't a copy made by good programmers". The ROMs are literally data dumped from the carts. It's the exact same data. It's not "recreations" made by programmers. However, your statement would apply to emulators. They decompile the data on the DS/GBA, and try to emulate the hardware limitations of these devices.

No, not completely. Read this:

Oh, thanks for repeating it. : D Thank you very much.

Kaphotics already explained to you earlier on: GBA/NDS will correctly assign stationary encounters with Method 1 IVs, However emulators cannot accurately assign the IVs from Method 1 in time, so the Pokemon will end up with Method 2 or Method 4 IVs. Method 2 or Method 4 IVs are incorrect for stationary encounters. So if you want to fix your Pokemon, assign Method 1 IVs to them.

Use RNGReporter to fix their IVs would be one way to do it. RNGReporter has a PID to IVs window. Using that will show the IVs (like the screenshot I posted earlier)

Because some are legal, and some are not. Certain encounters have certain PID restrictions (ie a Starter / Stationary encounter must be Method 1) while wild encounters can be Method 1/2/4. The method-1 only encounters are generated fast enough on actual hardware, but the emulator does not generate the pkm fast enough and gets interrupted, resulting in method 2 & 4. Wild encounters need to wait for a valid PID (nature/gender) which can also be interrupted by the screen needing to refresh.

Some emulators do not faithfully emulate the CPU timings present on the console, resulting in different PIDIVs sometimes. The PKM are not legal as they cannot be encountered on legitimate hardware. PKHeX is working correctly.

Finally, after taking pretty much forever, with the aid of @Saternoir, we are getting somewhere in regards to removing the background. I'm using this thread to detail the little progress we have done, so that we don't lose track of the methods. First of: SM - Garc A123 USUM - Garc A124 Containers format: Garc -> 0.bin (compressed LZ11) Mini format (BL) -> various ALYTs. The one of interest is 1.alyt. ALYT and Mini to be extracted and recompiled using Saternoir's fork of 3DSkit. At this point, using the garcs crash the system. It appears repacking the 1.alyt might be the cause. I've unpacked 0.bin, repacked it (without modifications), and compressed it, and the game works. However, the garc made by repacking the 1.alyt (without modifications) caused crashed.