raytheon

Okay, got it! It seems that, unlike with storage/general blocks, where checksum is being calculated for the whole block except the footer, for Hall of Fame block the checksum is being calculated right up until checksum field itself, meaning that it takes into account size of the block and every other footer field.

Hello. As stated in the title, I'm trying to modify HoF entries. It's pretty straightforward until block checksum recalculation - I've followed the same path as with general/storage block, i.e calculating CRC16 CCITT for the whole block right until footer part, but it seems that this is not the correct way, as every time I load such modified save, when selecting HoF in PC, there's a message saying that HoF data has been corrupted and in order to fix it, I should enter Elite 4 (or something similar, doesnt matter). I've tried recalculating the checksum and comparing it with one in the footer and it differs. Additionaly, I've downloaded this tool to play around with it a little more and this one does the job - entry is modified as expected and game properly loads HoF. So such modification is possible, how the checksum for Hall of Fame Block in gen IV is calculated?

Hi there. I was toying with HGSS save offsets and it seems that three parts are incorrect in the technical documentation: - battle items - first registered item - second registered item using this save, one can see that first registered item is a bicycle and the second one super rod. But according to listed offsets it seems that something is off - battle items starts at 0xD64 and consists of 31 blocks 4 byte each = 124 = 0x7C. But if this offset is used, then the last item of battle items is bicycle. I've subtracted 4 bytes from this supposed length and battle items were left intact. Then I've modified offsets of registered items so the first one starts at 0xDDC instead of 0xDE0 and the second one starts at 0xDDE. So I think battle items indeed starts at 0xD64, but consists of 30 4-byte blocks instead of 31. If someone would be so kind to verify my findings, as I cannot exclude the possibility of doing something wrong on my side. Though I'm rather confident, given that every other value is looking as it supposed to. EDIT: python output with corrected battle items offset: bytearray(b'<\x00\x01\x009\x00\x02\x00:\x00\x01\x00C\x00\x01\x007\x00\x01\x00=\x00\x01\x008\x00\x02\x00;\x00\x01\x00A\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00') and before the correction: bytearray(b'<\x00\x01\x009\x00\x02\x00:\x00\x01\x00C\x00\x01\x007\x00\x01\x00=\x00\x01\x008\x00\x02\x00;\x00\x01\x00A\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xc2\x01\xbf\x01') at the end of the second output you can see that those two fellas: \xc2\x01 and \xbf\x01. Applying little endian notation, first one is equal to 450 and the second 447, bicycle and super rod respectivly, according to bulbapedia. edit2: or even not 30 4-byte blocks but 15, as there are only 15 distinct battle items According to another technical documentation

Hello. I'm fiddling around with HG/SS saves. Following DP save structure page and Bulbapedia for gen 4 save (As I cannot find any info about HGSS), I've split 512kb save into two partitions and then, after looking it up in the PkHeX code, using ccurate offsets, divided each partition to general and storage blocks. Now, having that and knowing that each of those blocks have 20-bytes long footer, I wanted to check in which partition I can find most recent both general and storage blocks. I think I've calculated everything okay - as size of the block is exactly the same as the size itself, also storage block save count looks probable. But when it comes to general block save count, it is always 0, no matter what - on both partitions, on both general and storage blocks. Is it possible? Does HGSS games set this value at all? Here are said footers: I've observed this with my every HGSS save, but to double-check it, I've took save from this thread and this save is the source of data for above spoilers. Is there any "debug mode" or something that would let me see those values in PkHeX? Because all I've seen was an info whether checksums are valid or not, but no data about partition number of selected blocks. EDIT: I've changed the offsets and looked for some Diamond/Pearl save in the Saves subforum, to verify my hypothesis and as it turns out, my code is valid! It seems that HGSS games does not use general block save count at all, hence its empty. But when I've loaded this Pearl save, I've got following results: so my question now is: in HGSS games, how it is determined from which partition general block should be loaded? simply from the one which holds storage block with higher count of storage block saves?

Och, okay, I get it now! So if shift value is equal to, lets say 11, then the block order is BDCA. To invert it, I have to look at "inverse" column in the table and look for BDCA string, which is present next to 19 shift value (having in mind that its indexed from zero). Just wanted to explain it here in case anyone will be looking for this answer in the furure. Thanks a lot!

Hi there. I'm reading through PKHeX codebase and I've stumbled upon list of bytes that can be used to invert shuffling when encrypting the pokemon. I've read through block shuffling section on Bulbapedia but cannot figure out how it was calculated - instead of "mapping" that can be seen in the BlockPosition array which maps easily to A, B, C and D values in the table, this I cannot figure out, but I'd love to hear more about this!