Okay, so I have way too little information about the actual process of saves. Any documentation would be appreciates, namely
saves are handled in chunks of data which are loaded into VRAM, processed/unpacked and then loaded into the normal places (ie unit data goes where it’s expected to go, etc)
there’s also like the checksum validation to make sure it isn’t corrupt, but i couldn’t tell you how any of that works
Do you know where in the VRAM, or the approximate structure of it(e.g. Chapter–Units–Storage–Permanent Event IDs… or?)
i have no idea where in VRAM they’re loaded into (i don’t even think we could know, it probably just loads it somewhere onto the stack); that’s kind of the point of VRAM anyway
you can try screwing with the unit data in IRAM and creating saves that differ in minor ways, then using a diff on the actual .sav files to try and locate what’s changed (with appropriate wildcards to account for clock/checksum differences)
All addresses for first save file (save 0):
[Hextator’s doc has some on it][1]; I missed the offset part! But if I can find the offsets for the 2nd and 3rd saves…
[1]:https://dl.dropboxusercontent.com/u/336940/Software/Hextator’s%20Doc/Media/Games/Reverse%20Engineering/Console/NGBA/Fire%20Emblem/Game%20Doc/7%20-%20Blazing%20Sword/Saves/Map.txt
0x0E000064 - Checksum[6]; Checksum struct is:
char[8] fieldFlags;
// For first entry: first int is usually 0x00011217; following short is usually 0x200A
unsigned short offset;
unsigned short areaSize;
int checksum;
0x0E00011C - (unsigned short)[3] of random number seeds
0x0E002000 - 0x00001F2C bytes of checksum protected area (Checksum[3])
0x0E002048 - (unsigned short)[3] of random number seeds for Resume slot 0
0x0E003F2C - 0x00000D8C bytes of checksum protected area (Checksum[0])
0x0E003F7F - Bit array of item data for ally unit 0
Set to E4 FD 79 7F DE 9F F7 E7 FD
to get 5 mines with 63/1 uses
Boost items part 1: 68 FD 5B 3F D7 DF F5 7B FD
Boost items part 2: 7C FD 60 7F D8 2F F6 8F FD
Promotion items with Mine: E4 FD 87 FF E2 6F F9 27 FE
3 Uber Spears, 2 Ereshkigals: DC FD 77 FF DD EF F8 3B FE
E4 FD 79 7F DE 9F F7 E7 FD
is
1110 0100 1111 1101 0111 1001 0111 1111 1101 1110 1001 1111 1111 0111 1110 0111 1111 1101
… if anyone can see any pattern in that.
Mine is item 79 = 01001001
63 uses = 111111
Grouped differently:
11100100 111111 0111 100101111 1111101111010011111111101111110011111111101
Hm… maybe this is stored with some kind of huffman encoding? Well, I got nothing.
Tactician name of save 0: 0xE003F4C (Among Other Locations?)
Of save 1, first occurence: E004CD8
Of save 2: E005A60
The save data seems to be recurring? O.o? Every 10000? I assume that’s just the limit of the memory in the 0x0E000000 area.
No. Given that mine is 0x79,
111111 01111001 111111 01111001 111111 01111001 111111 01111001 111111 01111001
1111 1101 1110 0111 1111 0111 1001 1111 1101 1110 0111 1111 0111 1001 1111 1101 1110 0100
FD E7 F7 9F DE 7F 79 FD E4
Read backward.
E4 FD 79 7F DE 9F F7 E7 FD
Awesome. I thought about going backwards but I didn’t think it would be very handy for the program to read it as such. So I guess the logical extensions and end goals we want are:
no point in bothering with trying to make unit stats bigger since the proposition in the TODO thread is natively handled by FEditor (unless you want to have units with stats over 50?)
I thought the FEditor patch was only to subtract the class bases upon save and re-add them upon load. Which just doesn’t seem flexible enough for me.
it’s personal bases as well
for all intents and purposes it basically equates to a stat cap of 40
So I suppose if we just bumped up the class bases by 10 on each promotion or something, we could easily get 3rd or even 4th tier jobs (with decent caps in the 50-60’s)? Sweet.
if that isn’t what it already does it shouldn’t be too difficult of a mod
could even brute-force it out if you wanted to