Cass

On a PLA save, if the batch editor is used to edit all of the mons across boxes, the dex catch count updates to indicate new mons are caught with the current number in the boxes. This happens even if the mons themselves should not be updated, and happens on the most recent version (2/14/2022). I noticed this after doing a batch edit then having Laventon update 99 dex entries at once For example, if the dex says I have caught 5 decidueyes and I currently have 2 in my boxes, doing a batch edit updates the dex to say I now have caught 7 decidueyes. I have tested this batch editing a few different variables (GVs, TID/SID, CurrentLevel) and the issue still happens with them all. I also tried making an edit that would not change anything (I updated my TID to be itself) and the bug happened making the non-edit too. FWIW, the batch editor also said that a change was made even when it wasn't. This isn't a big issue to me personally but wanted to report the bug for you guys, thanks for all the great work as usual!

If I understand you correctly then, a TID/SID of 00000/00000 is impossible (makes sense, you also said that before ) HOWEVER, you could have one or the other be zero (such as 12345/00000 or even 00000/12345). Have I got that straightened out?

Wanted to revisit this, after another update to both pkhex and BDSP, the issue still exists. I doubt it has anything to do with pkhex, the game has more than its share of bugs! What I was wondering is, is it possible the TID/SID RNG now exclude 00000 as an option for either? Not sure why the change would be made, it doesn't seem like a lot of benefit could come from it. At that point the game being unable to handle it just has to do with the normal sloppy bugs this game seems plagued by, rather than pkhex introducing an ID that's out-of-range. Is pkhex able to change an ID to a number out of range? Obviously it's coded to revert an OOR ID to the max (e.g. pkhex would change 99999 to 65535) but would a hex editor be able to do that? or would the game itself revert the ID to the max?

Well however it does, it's just odd to me if the game has suddenly decided that 00000 isn't an acceptable value, when it's been with us all these years. @Kaphotics mentioned above that the game doesn't 'like' an all-zero ID, but the number is definitely within range

So with that SID/TID, you can play the game AND view the trainer card? Weird that the trainer card is dependent on the SID that isn't even displayed...

This seems very similar to my issue, which involves setting ONLY the SID to zero, with values in the TID. It also doesn't seem to effect pks caught while my ID is set as #####/00000, they are caught and assigned the ID without issue. Also, I can start the game and play it just fine, only problem I am seeing is display of trainer card. Has this always been the case, or is this new with BDSP?

Not sure if this is where this goes, but I found an issue with displaying the trainer card. If you edit SID to have a value of zero, the trainer card fails to display. I have tested this a few different ways (and on the latest pkhex release) and this seems to be what causes the issue. Attached is a screenshot of what happens when you try to view the trainer card after setting SID to zero.

Thanks so much for the new version, always impressed how quickly y'all are able to get the latest game supported I wanted to report a quirk where, when the TID/SID are edited, there is a glitch displaying the trainer card from the menu. I've attached an example of the screen when this is done (the game also more or less crashes when the trainer card is selected). Screenshot from yuzu ofc, but this happens on switch as well, and both with/without day 1 patch. Keep up the great work!

I was playing stadium and ended up with prize Hitmonlee (attached). This Hitmonlee was transferred to Yellow, then to Crystal which is why it's .pk2. I also have already removed its Normal Box, but that's what it was holding. Two questions about this mon: 1. Double Kick and Meditate are flagged as illegal, even though this is a mon that can be obtained in a legal manner (not here to argue about the legitimacy of emulation, so let's just say it's theoretically possible). Is this deliberate or an oversight? 2. As far as I can see, there is no way to identify this mon as being obtained by clearing round 1 of gym leader castle. Theoretically if I were to clear castle a second time and obtain a second prize mon, what would tell Crystal that it was obtained in round 2 instead? At first I thought OTTID, but those are both 02000, STADIUM. Could it be that Crystal assumes the first prize mon is round 1, and the second is round 2? This question of course addresses whether or not the transferred mon holds a Normal or Gorgeous box. Thanks for the thoughts! 106 - HITMONLEE - 266C.pk2

Yeah I thought I could remedy that by changing the hex digits in HxD, then uploading and then saving from PKHeX after verifying checksums, but it doesn't seem to work Either the changes do not take effect (date remains unchanged) or the HOF data is wiped. Unless I missed a step, this seems like it should work

Makes sense why checksums exist, but I am not clear on why editing four hex digits (two in HOF and two in the backup HOF) is beyond the game's control, especially when the digits I used to replace represent actual dates. I would understand why the game would corrupt if I changed the month to 13 or something, but I don't get why a correct edit made this difference. Also, is there a better way to edit this that I'm just not aware of

Old topic, I know, but came across it while editing a Gen 5 HOF. I've isolated the place where date is encoded in the hex, but when I change the hex (in HxD), my HOF data is erased when I start the game. I have also tried uploading and saving the save file from pkhex, but to no avail. Any thoughts as to why this issue occurs, or how to prevent it? All I am doing is changing the year and month, not the date or h/m/s Thanks!

Quick update to this: Gen 4: Updated both Plat and HG using the HoF extractor from this site, and then uploaded/downloaded each file with PKHeX before starting the files in emulator. Platinum updated properly, correcting both the main and backup portions of the .sav and displaying HoF correctly in-game. For the HG file, not only did the edits not display correctly in-game, but the save data corrupted if I attempted to correct the backup portion of the .sav before uploading/downloading with PKHeX. Gen 5: HoF data still corrupted after correcting the backup in the .sav, then uploading/downloading with PKHeX.

Hmm, I tried uploading to and exporting from PKHeX, and the same result occurred in B2 and in Plat (HoF is corrupted). When I tried with Emerald, however, it worked just fine! My only theory is that altering both the main and backup in HxD is to blame, as Gen 3 savs don't have the backup for HoF data. How is the "backup" portion of the DS save files updated? Using that information, would it make sense to fix the checksum by uploading a file where only the main save has been edited, then performing a save in-game to update the backup and checksums?

I was messing around on a B2 file using HxD, specifically in the Hall of Fame data block (offset starts @ 74000). After changing some PIDs and species, I booted the file and the changes presented correctly. Then I decided to update the HoF backup data (offset 75800) with the same information, but when I booted the file I was given the "HoF data is corrupted" message. Anyone know why this is? Or why editing the backup specifically caused this to occur? Information on how exactly the save file backups work on DS games is useful/interesting to me. Also, I tried this same thing on a Plat and Emerald save file, and got the same results. That is, edits that were made to the main HoF file were reflected in-game, but the HoF data corrupted once I edited the backup hex data.