Rilne

static.bin is stuff that's loaded from the rom everytime you boot the game. Since it's never saved to (since the game assumes it won't be changed), anything you do to it does not persist. Two ways around this: Repack the rom with a changed static.bin People have done this, I have not personally. Probably can't do it from a physical cart. Run a code once each time you start the game to fixup static data. More annoying, though less so if you have long play-sessions. Someone was working on a phone-hotspot exploit server that would help with portability, dunno how that worked out.

Huh. That should have stripped out any enemy only skills (vantage+, rightful god, etc.), though I definitely left in skills some chars can't get (intentionally). What can I say? Galeforce for everyone! But, ah, double-check that it ended up with enemy skills, if it did, somethings wrong and you might be missing some normal skills.

D'oh. [spoiler=non-enemy skills only for EU] B3CF2100 00000000 C0000000 00000044 2000001F 000000FE 00000020 FFFFFFFE 00000024 FFFFFFFF 00000028 8090FFFF 6000000C 00000000 B000000C 00000000 D2000000 00000000

Based on previous screw-ups developing my version of the 'all chars all skills' code, the bitset for learned skills has the same ordering as the list of possible equipped skills. [as previously seen in this thread]. So we need to change the last two bytes to 9080. Applying this to the code you're using yields: [spoiler=code] B3CF1100 00000000 C0000000 00000044 2000001F 000000FE 00000020 FFFFFFFE 00000024 FFFFFFFF 00000028 8090FFFF 6000000C 00000000 B000000C 00000000 D2000000 00000000

You'll need to install the old browser from 9.5-22 or before, which you can do on emunand. I'm running sysnand so I can't explain too much how to do it, there are guides around. (yay perma-9.5-22 and repeatedly deleting system updates to get it to stop bugging me) As long as the browser is the exploitable build from 9.0 to 9.5-22, you can use whatever emunand firmware level you like.

Do we have a working firmware spoof for post 9.2 yet? And the browser exploit works all the way up to 9.5-22, by the way; was patched in 9.5-23.

Or, if you know your roster block offset, just load the parent pointer from the sibling with D9, then write it with D6.

Nice. Oh, I'm not sure if this is common knowledge or not: If you dump, close your 3DS lid while still on home screen, take out SD card and copy dump off, then put SD card back in and open 3DS back up AFTER it's back in, it won't freak out and decide to shutdown/close your game. useful for looking at the memory _right now_ and then immediately making edits based on that.

Eh. I worked with pointers by loading a known one with D9, incrementing/decrementing it enough to point to what I want (since most of them are in a consistant order), then writing to target with D6. This admittedly doesn't help too much with the parent pointers, since we'd need to actually follow them, but for support tables/class tables/other stuff it works fairly well. I wanna try and fork the lunarcookies generator and add some extensions (inline ASM and the 'add data to offset' in particular), we'll see how far I get with that. Should be able to make better general codes then.

I've seen that a few times in my dumps too, I suspect it has to do with whether Chrom is locked or not. Why are we making an excel calculator? Just do D3000000 [your starting offset] then work relative to that. It's what that mode is for.

Hmm. So parent pointer leads to a patch table with both parents? Interesting, would explain some of the issue I had with getting extra Morgan pointing to the right set. I'll have to take a look at that later. Ach, sorry. Lotta interleaving replies in here. [spoiler=current roster offset list] 0x00::0x16 (17 bytes) unknown 0x17::0x23 (15 bytes) learned skills 0x5C (4 bytes) character 0x60 (4 bytes) class 0x64 (4 bytes) team 0x6C (4 bytes) logbook 0x70 (4 bytes) parent 0x74 (4 bytes) enemy portrait? 0x78 (4 bytes) unknown 0x7C::0x83 (8 bytes) stats 0x84 (1 byte) roster position 0x85 (1 byte) level 0x86 (1 byte) xp 0x87 (1 byte) hp 0x88 (2 bytes) map position 0x8A (2 bytes) unknown 0x8C::0x97 (8 bytes) unknown 0x98::0xAB (20 bytes) inventory 0xAC::0xB5 (10 bytes) equipped skills 0xB6::0xBB (6 bytes) weapon ranks 0xBC::0xFB (64 bytes) support levels 0xFC hair color 0x100::0x10F (16 bytes) unknown As for the alignment...hmm. If we knew some more of the leading/trailing data, we could narrow it down. For the locations we do know, so long as we start from the table header these offsets + 0x110 for each block will work fine, even if our offsets are...offset. from the true structure.

Remember, for every child, one parent doesn't need to be stored since it's always the same. For most of them it's the mother, so only the father is stored. For Lucina and Morgan♀, the father is known, so it stores the mother. So here, Lucina has a parent pointer to Olivia, and Inigo has one for Chrom. As for what the data means, pointers just list another section in memory. In this case, it's likely listing a spot in the static character data. To find the offset it's pointing to so you can go look at it in your dump, flip it from little-endian (the byte order in the dump) to big-endian (ie. human order). Then add 0x14000000 (because FCRAM dump starts at 0x14000000, so offsets in the dump are off by that much). That said, what you've listed don't make much sense. Even assuming those are already in big-endian, that'd be addresses of 0x149B46B0 and 0x1624BC88, which are much too far apart. Are you sure you're pulling from the right spot? For reference (since I'm getting tired of the screenshot offset lists): [spoiler=roster block offsets] 0x00::0x16 (17 bytes) unknown 0x17::0x23 (15 bytes) learned skills 0x5C (4 bytes) character 0x60 (4 bytes) class 0x64 (4 bytes) team 0x6C (4 bytes) logbook 0x70 (4 bytes) parent 0x74 (4 bytes) enemy portrait? 0x78 (4 bytes) unknown 0x7C::0x83 (8 bytes) stats 0x84 (1 byte) roster position 0x85 (1 byte) level 0x86 (1 byte) xp 0x87 (1 byte) hp 0x88::0x97 (12 bytes) unknown 0x98::0xAB (20 bytes) inventory 0xAC::0xB5 (10 bytes) equipped skills 0xB6::0xBB (6 bytes) weapon ranks 0xBC::0xFB (64 bytes) support levels 0xFC hair color 0x100::0x10F (16 bytes) unknown These are offsets from the start of each roster block. So, parent pointer should be the 4 bytes at 0x70.

Please don't quote the entire opening post when asking a small question. '0x' at the start of a number is the standard notation for saying the number is in hexadecimal, ie. base 16. The actual number in this case would be 134DE9C, which is obviously in hex, but something like 0x1245008 is ambiguous without the 0x at the front.

Nothing. Lucina will always come as Lord. Now, Morgan can vary a bit based on parents, though not parents class. Case in point: vanilla game with MU♂⨯Nowi pairing, Morgan♀ will start as manakete.