theSLAYER

Don’t modify any immutables, and these files + their tracker will work: (modifying the immutables will break the tracker)

Accordingly to this, scale was locked besides the ones stated otherwise (Pikachu being an example; it wasn’t locked, but is forced to generate a one 140 and above)

I’m assuming you’re referring to a few titled “hex extracted” in the event gallery. It was found that the wondercards within owned distributor carts had a small bit of extra detail that the game ignores when receiving the beacon (due to the set on the wondercard) or overwrites. I cant recall what specifically, but I think the one example is date recorded. In any case, hex extracted is for archival purposes only. You could use the regular ones in Event Gallery, or the ones already preprogrammed into PKHeX

Keep in mind that you are using a ROM hack, the game could have restarted due to the fact that the modified save isn't compatible. Try using this method with a vanilla unmodded game first. That should help reduce any noise that could cause issues with the modification process.

@Dyctinna PKHeX can directly edit dsv save files, just make sure the emulator is closed. And don't rename the file or change the extension. PKHeX can export back to dsv, just overwrite the original dsv file. And if it remains a dsv, won't have to try to import back into Desmume, the next load will automatically load the dsv (provided it is in the right spot) Also don't use state saves. Use the in-game menu to save the game, and when you load the save, just mash through the title screen sequence. ____ For future reference, if you are trying to modify a save and trying to import into Desmume (in this case, I believe the size is actually for dsv but you've renamed it to sav, so Desmume got confused), used the AUTO (from imported save data).

was the Latias caught on console or emulator?

I'm able to replicate; spin trades led to Link Trade (NPC) Gen V Also, Gen IV is correct

Are you using FTP to transfer the save to your computer? The data is truncated to a weird degree. When I shifted your data, it partly showed up correctly, but became truncated again down the line. This can be explained by the FTP setting being incorrect.

Could be, but I don't use that emulator, won't know for sure. What you could do is export the save file, and see if PKHeX can read it. (Note, PKHeX isn't meant to work with ROM hacks, but if all you've done is randomization, then it should work)

I can think of another place: form arguments. Usage may slightly vary and the info isn't useful for the game once evolved, but relevant to hack checking. Like it keeps track of how much damage was done to Galarian Yamask. How many time the Hisuian Basculin used the recoil move to evolve. Technically speaking, the HOME tracker is trash bytes within the respective games, as they don't use it nor reference it, and it was written from an external program. But we know it is important as it is used and tracked by HOME. Pal parking causes trash bytes too, and I don't remember where those trash are written to. In any case, PKHeX allows you to go through each extra byte, which may or may not hold undocumented data. PKHeX should have everything documented but it is more future proofing, in case the location becomes used in the future I don't recall if it happens in newer games, but absolutely happens in older games during evolution. In Gen 5, I traded a English captured unevolved mon to be evolved in a Korean game. IIRC that resulted in Korean species names and English trash bytes. A scenario I vaguely remember but never actually tried was hatching an egg (from a trainer with a long OT) into a different save (using a trainer with a short OT), and that resulted in trash bytes in OT. Not sure which generation this applied to, tho. I'm not sure. I think "captured unevolved Pokemon within it's own game" are fine, but anything evolved may bear a potential for trash bytes, and everything else is probably a case by case basis. I think some transfer up clear trash bytes anyway so maybe look into that first (not transfers between Switch and HOME games). You probably should clear Trash bytes in OT/Nickname first, then worry about how they may get applied. Or better yet, just gen something that would have had it's trash byte cleared upon transfer (but in that scenario you'll likely be missing a legit HOME tracker) Not sure. If it's clearing, then unlikely?

It should be fine. But keep in mind when you go online, the injected one will get replaced by the current one

I believe I am done

Your description is right, nuke the files, nuke the logs. @Forer all you can do is add all the changelog manually into every upload.

Took a cursory glance. Seems like you’re trying to put Gen 1 retail events into a Gen 1 VC save. That’s a no-no. There is no legitimate way to transfer save between VC and retail cart. In this instance, Bulbapedia’s documentation is not false, you just misunderstood what you’re reading and did something incorrect; you are doing something impossible and PKHeX is screaming at you, cause you’re at fault. Edit: just to be clear, there are scenarios that PKHeX can’t perform meaningful validation on Gen 1/2 events, as those are so old and easily faked, and the documentation from Bulbapedia would not be enough for PKHeX to implement proper validation. But in this case, you're doing something beyond that.

If I’m not mistaken you could, I’ve done stuff like that before. But as a warning there could be *some* effect. After all, international releases tend to revise glitches from the Japanese version, so it any glitch affected flags or event constants, you may be bringing the incorrectly set flag or constant into your English game. TL;DR: It is possible, but keep in mind the process could have effects on gameplay. Do it at your own risk.

I’m not too sure but probably related to loading the PCD and PGT manually

If you want to see the album entry in-game, import the PCD. If you want to receive the gift in-game, import the PGT. Import it in whichever combination, based on what you want.

Make sure you already have the black crystal raids (6-7 star, not dark type) unlocked. You *may* need to advance your clock by a day. Then open your map, look for the 7 star raid. It’ll be black + had concentric radiating pulsating circles around it. Here’s a static image. The typing will change depending on what you’re battling.

Or get a friend to generate it for you in the appropriate game. All mons sent in from the correct game (caught in LA, sent from LA) will get assigned a tracker.

The forced shiny isn’t applicable to every encounter; some encounter scenarios (and not all) can “force” a generated PID to be shiny. Basically in scenarios like that, the shiny determination is separate from the PID generation process, and the “force shiny” will modify any calculated PIDs in a while that would result a shiny PID. One example would for SWSH overworld encounters. If shiny = true, it will modify the PID as mentioned above. Off the top of my head, can’t think of a scenario for applicable for BDSP

IIRC non-event eggs are sufficiently random and lack correlation. Depending on the game caught in. Try generating one caught in Emerald, and one caught in Sword’s dynamic adventures, as examples.

Another way is to play the modified ROM on an emulator. See what game is loaded and what save is being shown. After all, maybe for a particular type of cart with a particular type of ROM, it’s possible that there more than one save. I mean, you evidently *could* reflash, but maybe the save is stored differently then expected. For that game, what is the name of the save extracted using the program, and how many saves do you get? (I want to determine the hex address of the save and then ask you to use a hex editor to extract everything after that point; I don’t want any ROM data to be accidentally extracted and sent)