PMArkive

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

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. Wormhole Legendaries Flag UnSet Const Flag UnSet Const Red Green 0001 851=1? Articuno 0001 851=11? Mewtwo 0002 851=2? Zapdos 0002 851=12? Raikou 0003 851=3? Moltres 0003 851=13 Entei 0004 851=4? Ho-Oh 0004 851=14? Dialga 0005 851=5? Rayquaza 0005 851=15? Cobalion 0006 851=6? Cresselia 0006 851=16? Terrakion 0007 851=7? Tornadus 0007 851=17? Virizion 0008 851=8 Thundurus 0008 851=18? Reshiram 0009 851=9? Landorus 0009 851=19? Zekrom 0010 851=10? Yveltal 0010 851=20? Xerneas Yellow Blue 0001 851=21? Regirock 0001 851=29? Suicune 0002 851=22? Regice 0002 851=30 Lugia 0003 851=23? Registeel 0003 851=31? Latias 0004 851=24? Groudon 0004 851=32? Latios 0005 851=25? Heatran 0005 851=33? Kyogre 0006 851=26 Regigigas 0006 851=34? Uxie 0007 851=27? Palkia 0007 851=35? Mesprit 0008 851=28? Giratina 0008 851=36? Azelf 0009 851=37? Kyurem 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.

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

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.