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.

Doing a playthrough of Green (JP) and got an illegal flag on this Golem (Invalid: Ingame Trade OT has been altered) Of course, there is no ingame Graveler/Golem trade in Green, but there is one in JP Blue. Is that how the flag has shown up? Even then, why would it flag a Golem anyway? Isn't a mon like Farfetch'd that's IGT only... 076 - ゴローニャ - E207.pk1

That makes sense to me given that it is PRNG. Not to mention there's no real use in testing to make sure ALL 4 bil combinations are possible, it seems a bit much. Thanks for the help anyway!

I suppose this is a limit of my understanding. I am thinking about TID/SID generation as if it is an RNG where, given enough iterations, 00008/00000 would eventually be produced (even with roughly 4.3bil possibilities). Is it in fact the case that there is only a limited number of TID/SID combinations, and the seed determines which frame those combinations appear? Also I have experienced what you mentioned with other mons from Colo, in that pkhex doesn’t mark them illegal even with 00008/00000. Without Esp/Umb, I would not have even detected this problem! PS cool number indeed, I may just say to hell with legality and keep it anyway!

Oh wow great knowledge! I have a couple follow ups then: is it the case that RNGReporter programming is limited within some definition of a “practical” frame range for generation? If I were to boot up a GameCube or emulation of Colosseum and let it run forever at the point of TID generation, would it just generate forever or eventually hit some sort of limit as it is a PRNG? I generally use Dolphin, so state/frame checkpoints are not unreasonable. Also, I would be curious if there has been any research about Nintendo’s own legality checker and whether or not it considers a PID x TID mismatch based on origin game. As a follow up to that, if there IS an actual coded limit to TID/SID generation, wouldn’t that be a useful legality inclusion for pkhex as far as an origin game x TID/SID mismatch? If there IS NOT such a limit, wouldn’t it then be better to remove that legality check altogether and base it instead on whether or not Esp and Umb match properly? PS the 00008 for me is superstition and consistency! I rolled it in my very first game playthrough so it’a a bit of nostalgia I like to take with me in games where I’m not just experimenting or messing around. The 00000 is just for consistency with Virtual Console, no special significance there. Did you also roll the 00008 on purpose??

I'm reopening the Colosseum discussion about the RNG that never seems to end! In short, PkHex is returning an illegal flag on my Espeon/Umbreon (Unable to match encounter conditions to a possible RNG frame) because I altered the TID/SID on them to match my trainer (I'm one of those who uses the same TID/SID for every game). After a little research, looks like this is because I changed my TID/SID AFTER starting the new game save, which of course would have been inconsistent with the PRNG from when I started the save file and whatever TID/SID and Espeon/Umbreon I generated upon startup. Here is what I care about and don't care about for my Espeon/Umbreon's legality: I DON'T care about: IVs, Nature, Shinyness, Ability, Gender, basically anything that isn't TID/SID. We Gen VIII now, the world of mints and ability capsules and hyper training and all that shtuff. My Espeon and Umbreon can look like literally whatever within the following parameters: I DO care about: TID/SID/PID matching. My TID is 00008 and my SID is 00000, and despite my best efforts I cannot come up with a PID that marks the Esp/Umb as legal. To fix this, I have tried various strategies from this site and others, and seem to always come up short with generating the right PIDs for Esp/Umb. Most tools available are designed to help generate shinies, but as stated above this isn't important to me. I now have two questions. 1. Is it possible that the PRNG doesn't produce all theoretically possible TID/SID combinations? is 00008/00000 unobtainable given Colo's coding? I was able to generate PIDs for both TID00008 and SID00000, so those are both possible, I just haven't been able to get them together 2. Please help??