SupremeThunderDragon

The alarm has always been such an afterthought to me that I never explored that possibility! It's one thing for the receiver of Watts to send the last-gifted Watts as a dummy amount, but it's another thing entirely for the Pikachu to send their alarms to each other. Perhaps they share them? Between my three Pikachu devices, my one English one has two "presets," which are "A" and either a "G" or maybe a "6." Of the two Japanese ones, one has only "A" while the other has "A" and "B". Curious. Also, I did a couple reads of my Japanese Pikachu sending data to the other with an alarm created. Turns out, the first byte of the 65-byte string is actually the length of the melody, with 0x64 being the highest with one test, and another test with 30 being 0x30, so this also appears to be a binary-coded decimal. The next 64 bytes are the actual melody. The lowest pitch is 0x7D (decimal 125), and decreases in size as pitch increases. It stops after 0x72 (decimal 114), and there's a small gap where 0x71, 0x70, and 0x6F aren't included, so the next pitch increase goes from 0x72 to 0x6D, and continues to increase by one until the max at 0x62 (decimal 98). I don't know why there's that gap, but 0x71 is used as a rest note, as opposed to one with a pitch. 0x70 and 0x6F appear unused however. Thank you for the new insight!

Thank you a ton BlackShark for this breakdown. In combination with other resources, it's been very helpful for this novice to understand the basic structure of the e-cards. I'm wondering if there's any additional details you can go into regarding what the VPK is and how it works? I'm assuming this is the machine code for the e-Reader to parse, but I wouldn't know where to start in regards to editing something beyond just a trainer or berry. In particular, I've been curious about how multi-strip programs work for Mystery Event. It's hard enough to find any documentation regarding the e-Reader, much less about Mystery Event e-cards with more than one strip, since to my knowledge only two exist and they're both Japanese. The trainer cards, berry cards, and Eon Ticket are all one strip to scan. However, the Japanese 08-O001 Regi Doll Decoration Present is two strips, and the oft-forgotten Japanese 16-A001/2 "Berry Problem Repair Program" is a whopping four strips to scan. Against my better judgement, I wanted to start my e-card analysis with the Berry Problem Repair Program. Since it supposedly just shifts the RTC timestamp of the save game, I found it curious that it somehow requires four strips to scan. Instead, I've discovered that the BPRP appears to not follow the same VPK rules that all other Mystery Event e-cards do. Firstly, I should mention how these multi-strip cards differ from the single-strip ones. For every e-card .bin file, the compressed data VPK + padding is a total of 2029 bytes after the VPK size bytes. With more than one strip, the only strip that actually has padding is the final one (ie, the second strip for the Decoration Present, and the fourth strip for the BPRP), with all other strips containing VPK data in the full 2029 bytes. In addition, the VPK size bytes only seem to apply for the first strip, which denotes the combined VPK size of all strips. Every other strip has weird VPK size bytes that I don't understand. Strip VPK Byte VPK Byte (Decimal) VPK Size Size Info Byte 08-O001 1 0x0DA4 3,492 2,029 0x021B4C42 08-O001 2 0x0D00 3,328 1,461 0x021B4C44 16-A001 1 0x19D5 6,613 2,029 0x0233B682 16-A001 2 0x087E 2,174 2,029 0x0233B684 16-A002 1 0xC203 49,667 2,029 0x0233B686 16-A002 2 0x708F 28.815 524 0x0233B688 The total VPK size for the Decoration Present is 3,490, but the first strip's VPK byte has it two bytes larger at 3,492. Likewise, the BPRP's total VPK size is 6,611 yet the first strip's VPK byte also has it two bytes larger at 6,613. I thought I miscounted multiple times, but it's peculiar that two separate strip sizes are both two bytes less. I ensured this was a trait not shared with other cards; for reference, both the English and Japanese Eggant Berry cards' VPK byte matches their VPK size (0x053F to 1,343 and 0x054B to 1,355, respectively). This oddity aside, I was able to take the two strips from the Decoration Present e-card, cut their VPKs from each, paste the two together, and it successfully decompiled into a VPK that has "GameFreak inc," so I assume it was done properly. On the other hand, the BPRP can't be decompiled in the same manner. The VPK tool says "Invalid vpk data" when I try decompressing a file composed of the four VPK pieces from each strip of the BPRP. Perhaps most importantly, the VPK of the first strip does lacks something every other strip does: leading with 0x306B7076, aka the text "vpk0." After the VPK size bytes, every VPK starts with that, and this includes strip 1 of the Decoration Goods (but not strip 2, likely because it's a direct continuation of the full VPK). It seems possible that the Berry Problem Repair Program uses some unique format or something, and if it doesn't follow the same format that the rest do, then this novice is immediately out of ideas. Decoration Goods' header and VPK start, with the standard "vpk0" begin: Berry Problem Repair Program's header and alleged VPK start, lacking the standard "vpk0": I've included the sets of .bin files for the BPRP and Decoration Goods to look at or check my work. berry_prog_bin_files.rar deco_goods_bin_files.rar

I'm not used to PKHeX so I'm likely doing something wrong or misunderstanding how the Event Flag Research works, but: in Crystal, I saved just before and after talking to Carrie, the Mystery Gift girl in green on floor 5 of the Goldenrod Dept Store. Talking to her is what unlocks the Mystery Gift option in the main menu. Placing the pre-Carrie and post-Carrie saves into the Researcher brings up nothing. Just the Alert "No Event Constant diff found." Am I using the Researcher wrong? It's not like I understand what the flags or constants mean. It's also possible that the Mystery Gift unlock isn't a flag, but I don't understand how that could be the case.

Over the past year I have spent time on and off working with the IR signals for the Gen II Mystery Gift (specifically in regards to the Pokemon Pikachu 2), and there are two clarifications to bayleef's data that I was able to gleam, for whatever that's worth. I will note that I wouldn't have gotten to where I am if it hadn't been for bayleef's trove of information and trailblazing on this topic. I discovered that, of the 67 bytes the receiving Pikachu sends, the first two bytes are--for some reason--the number of Watts that was most recently given to Pikachu on that Pokemon Pikachu 2. When a player goes to "Present," then "Give," the Watt amount given will show up as a binary-coded decimal in the Pikachu's payload, followed by 65 0x00 bytes (ie If the receiver was recently given 987 Watts, its payload will be 0x09, 0x87, 0x00, 0x00...; you can even "reset" this to 0 by giving Pikachu 0 Watts). To quote bayleef, don't ask me why! (Note: This was discovered by reading from a Japanese Pocket Pikachu Color, but I'm confident it applies to the international version as well) I was noticing that there was considerable variety among my Pokemon games' status byte here when there was an item waiting at the center. It took an embarrassingly-long amount of testing and troubleshooting for me to discover how it actually works. If there is no item waiting at the Center, the status byte will of course be 0x00. However, if an item is waiting at the Center, the status byte will actually be the ID of the item waiting at the center. However, it is not the Mystery Gift ID of the item. That is a separate and unique ID list. It goes off of the item's internal GSC ID number. In bayleef's case, it happened to be 0xAD--the Berry item that otherwise has a Mystery Gift ID of 0x00. I will note that upon this revelation that at least once, the Mystery Gift's payload used GSC ID numbers, I was excited at the possibility of using Mystery Gift to inject items like the GS Ball. However, the rest of the process uses the unique Mystery Gift IDs, so I unfortunately don't believe that is possible. Would love for someone to prove me wrong though!