PMArkive

Looks like this issue wasn't completely fixed https://github.com/kwsch/PKHeX/issues/2267 rip kurt

7 hours ago, theSLAYER said:

I don't know if those saves are direct before/after saves. If they aren't direct next to each other saves, comparing the status may be difficult. The saves probably duplicate as a save backup feature, in case first slot gets corrupted, load second slot. That feature is in every Pokemon gen since GBA, I think. (Tho the backup won't show in mains of gen 6 and 7, if I'm not mistaken)

In any case, if anyone has Ranger, can load up the unsent save, send an egg, an provide me the next save as a sent save, probably could take a look.
(@InsaneNutter are these saves direct before/after saves? If they are I'm screwed, there's too many differences at first glance)

They are direct before/after saves that I made with the `and new game` saves done through till the first save point.

Here's some saves (egg sent, unsent (original), new games from both, and a fresh new save) (from digiex) that could be looked at. Interestingly, saves appear to duplicate the first 0x200 bytes at the beginning.

manaphy_egg_saves.7z

To add onto the Wormhole Encounters info, here's a table for the Legendaries:

I may need to edit the yellow wormhole Pokemon but I'm pretty sure they're correct. The slots are correct.

I'm not sure if the 851 const does anything though. I tested a few times and it didn't affect which Pokemon appeared.

Here are some other consts that changed between my saves, before entering Ultra Space and after entering a wormhole with Thundurus in Ultra Moon:

0: 0->333 // unknown
1: 0->702 // unknown. Entei and Lugia had 702 also but Regigigas had 706.
2: 0->642 // Pokemon's Pokedex number used for message upon running away from Legendaries?
3: 0->4278 // Event flag to set upon capture (Thundurus's here)
4: 0->4541 // Unknown event flag (for Thundurus too I think).
851: 40->8 // 40 was when I edited it for Sigilyph prior to exiting the Wormhole and reentering. 8 is the const value from the legendary encounter table above.
852: 0->24 // unknown

IsSet flags upon entering a wormhole:
0001, 0002, 0003, 0004, 0005, 0006, 0007, 0009, 0010, 0011, 0012, 0013, 0014, 0015, 0016, 4114
0001 through 0015 are for determining the slot.
0016 might be too but I don't know. edit: I'm assume it's an unused slot flag.
I'm not sure what 4114 is. Maybe a "In wormhole" flag.

After finishing the battle, there are flags that are set like 0071 (Regigagas), 0067 (Lugia), 0068 (Entei). Also const 3's event flag is set if captured. const 4's event flag also appears to be set if captured but I need to make a clean save without any wormhole Pokemon caught to check.

I also ran into a shiny Thundurus that I assumed was caused by the wormhole's shiny flag and then soft-reset. I didn't have the shiny flag set though... nice.

1 hour ago, BlackShark said:

Save block 4 offset 0x2B1 is set to 1 when Wishmaker Jirachi was received. That's at 0x82B1 in your Post Jirachi save file.

Aye, you're right. I don't know if you found this in the Ruby/Sapphire disassembly, but I didn't think to look there until after your post...

I tested with this code in PKHeX (well, a worse version of the code at first):

public bool WishmakerJirachiGiven
{
    get => GetFlag(BlockOfs[4] + 0x2B1, 0);
    set => SetFlag(BlockOfs[4] + 0x2B1, 0, value);
}

@Kaphotics would you be interested in adding the flag into PKHeX somewhere?

I was curious how the US Colosseum Bonus disc knows whether the Wishmaker Jirachi has been received on a save, but it doesn't appear to be through any flags that PKHeX can diff (along with much of the save's data moved around). Here are the save files if anyone else wants to look at what changes

Sapphire Before Jirachi.sav

Sapphire Post Jirachi.sav

On 1/3/2019 at 9:54 PM, BlackShark said:

The most interesting file is probably mii.arc.ash, that's where I think all the NPC data (Miis) is stored. So if the trades are really inside the game, there should be evidence in this file. It is actually bigger in the Japanese version than in the European version. Though this could be just because the Platinum update added 3 additional Miis to the game. Another interesting file is rodata.arc.ash, which is only in the Japanese version. But just like the other file this one could just be part of the Platinum update.
Those ash files are compressed and should be extractable with ASH Extractor (which seems to be the only tool available to handle ash files), but while it works well for some ash files it fails to decompress these two files. So the content remains a mystery.

ASH Extractor will usually crash when attempting to extract mii.arc.ash, but can sometimes extract it successfully. I haven't tested rodata.arc.ash yet but I imagine it will be the same thing.

edit: Possibly a heap corruption in ASH Extractor, but we could try requesting the source code from crediar so we can fix it. Looks like someone has asked before ( https://wiibrew.org/wiki/User_talk:Crediar ) so might ask that person too

the file extracted from mii.arc.ash appears to be a Wii U8 file, but attempting to use ARCTool.py or whatever misc tools fail to extract it due to large file sizes being detected. Maybe because of the endianness needing to be swapped.

edit2: I sent an email to the person that asked crediar before for the source of ASH Extractor and they said they weren't able to reach crediar when they asked. I haven't tried too much to get ahold of crediar tbh. Anyway, the crash for ASH Extractor seems to be caused by an out-of-bounds read. I think the only reason I was able to extract a file from mii.arc.ash is because Wine on Linux had placed memory some valid memory right before the buffer and so it read some random data. That would also explain why extracting files from it (a U8 file) failed... because its contents were random data. I tossed ASH.exe into IDA and decompiled the main function and changed a little bit so it can compile and to find out where it crashes but I don't have a fix for it... yet... You can find it here.

edit3: Was able to get the source from crediar and it crashes here. I also found that wiiqt, wii-system-menu-player, and quickbms had code apparently based off of crediar's disassembly too and hoped their changes/versions could decompress mii.arc.ash but they crash nonetheless.