Element Grid Growth Formula

[glennxserge]

Hi everyone, I'm poking around in some of the character stats trying to work at a few details about how the element grids function.  And I think I've mostly sorted out out the bitmasks that enable grids as well as how they are initially set when a character joins your party.  But I'm running into trouble understanding how the game determines which slot to open up at what level.  I'm not sure if it's set explicitly in some other data block or if there's a formula related to star level.

I'll use Serge's block as an example (from :MKL122788's character gamefaq)

Code: [Select]

[  22  ][  31  ][  39  ][      ][      ][      ][      ][      ]
[  19  ][  20  ][  24  ][  30  ][      ][      ][      ][      ]
[  12  ][  14  ][  16  ][  23  ][  36  ][      ][      ][      ]
[  07  ][  08  ][  09  ][  13  ][  21  ][  34  ][  46  ][  48  ]
[  00  ][  00  ][  00  ][  05  ][  11  ][  18  ][  26  ][  37  ]
[  01  ][  02  ][  03  ][  10  ][  15  ][  29  ][  35  ][  41  ]
[  04  ][  06  ][  25  ][  28  ][  33  ][  40  ][  43  ][  44  ]
[  17  ][  27  ][  32  ][  47  ][      ][      ][      ][      ]
At star level 0, there is one open slot in level 1, 2, and 3, on the fourth row, which is basically the center of the grid.  This is the case for every character, except Sprigg because she has no low level elements.  The rest of the slots are denoted with a number indicating which star level they will be unlocked.  I can't find anywhere that determines this growth pattern, and it's varies quite a bit character to character.

Referencing the stat data block for Serge at 0x13B721C8:

Code: [Select]

xx   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
   - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
00 - 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 - 00 00 00 00 01 40 32 00 09 05 55 08 07 07 0A 0A
02 - 20 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00
03 - FC 03 FC 03 FC 03 F8 03 F0 01 E0 01 E0 01 E0 01
04 - 00 40 00 40 00 40 00 40 69 40 00 40 00 40 00 40
05 - 00 40 00 40 00 40 00 40 55 40 00 40 00 40 00 40
06 - 00 40 00 40 00 40 00 40 00 40 A0 C0 00 40 00 40
07 - 00 40 00 40 00 40 00 40 00 40 00 40 00 40 00 40
08 - 00 40 00 40 A1 C0 00 40 00 40 00 40 00 40 00 40
09 - 00 40 00 40 A2 C0 00 40 00 40 00 40 00 40 00 40
0A - 00 00 7B 00 32 14 00 00 00 00 00 00 00 00 00 00
Line 03 is the bitmask series (2 bytes per grid level), that indicate the final grid shape
Line 04-09 are the specific element slot values (2 bytes per value, with the upper nibble of the high byte being a flag for slot behavior; bit 7 means occupied for stuff like a tech, bit 6 is default)

I don't see any other areas of the data block that would indicate which slots open at what level.  Does anyone know more about this? 

[glennxserge]

Figured out a couple more things that are worth documenting, that I found weren't identified in the modification pages for enemy data: https://www.chronocompendium.com/Term/2535.html.  The player characters actually share the exact same data block format, and a couple of the missing 'unknown' bytes from the enemy section are used for characters.

Relevant to this post, byte 0x03 (previously unknown) is some kind of offset for which grid element growth table to use.  There are 8 used growth types, with most of them being Pip (uses 3,4,5, and 6 for his various forms), and Harle uses 7.  Serge and friends use 0 for the most part, and Viper and associates all seem to use 1.  I'll get a complete list as I keep digging.  I need to see if I can find an explicit lookup table associated with that byte offset, but this does seem to be the way the game determines which slots become available for characters at specific star levels.  I'll keep checking.

The other unknown byte from that link, is 0x1F.  This is the character stamina attribute.  It's listed in the block in the full integer form, the game must divide by 10 to get the decimal point, but I've verified that this is the stat that's used to regenerate character stamina.  It makes sense this wouldn't be used for enemies since they use a different attribute to determine their turn order.

Alright, back to looking for the element tables...

[Grobycftw]

Sup Glennxserge! Long time!
I thought I shared this doc before somewhere but not 100% sure so I'll post it here

https://drive.google.com/file/d/157ShXf_YE0djzhVvIVZiWs6bjjpEei1W/view?usp=sharing

here's some info/test I did when looking how the element grid we're working. We, just like you couldn't figure out what determined which grid gets open at "x" lvl, but we did figure a few things out and just needed to do some more testing to hope finding an answer to this  
anyway hope this can help somehow, feel free to use/edit anything in there!

Im thinking maybe we should try to find some similar bytes in those blocks with characters that has similar Element Grid Growth, like Grobyc and Karsh I think? they have the same grid I believe, things like that would be worth being checked out!

[glennxserge]

Hey Grobyftw!  Thanks for sharing that, lots of good details in there 

Yeah, I tried finding some kind of lookup tables that represent the 7 specific growth patterns but I didn't have any luck.  Hard to search for something without knowing how the data is packed.  I should give this another look, after I read through your doc.

[ZeaLitY]

Updated that offset page in the encyclopedia. We can always get encyclopedia access going if you need edit access concurrent with some research/investigation; just let me know.

[glennxserge]

Thanks, ZeaLitY, I'm still pluggin' away when I have time.  I'll let you know if I learn anything new, but it's slow going.

[F-man]

I did a little research related on those grid lookup tables. The grid growth type 0, which is the most common one, seems to be 8x8 grid with 9 unknown values (rest can be gotten by combining Serge's and Guile's grids). So, I edited Serge's grid shape so that he could unlock all those unknown slots at some unknown star levels. Then I star-upped him to max stars, one star at time, to find which levels those would be. The answer ended up being never. Seems like those slots cannot be unlocked at any level as devs must have left them empty because they didn't use them. A very boring decission but might be useful information. I hope we can find those lookup tables.

[glennxserge]

That's a good test, F-man.  How are you incrementing the star level in game?  I'm taking a look at this again since I'm working through the character customization part of my tool.  I wasn't sure if the growth pattern was explicit, or something like: "at star level 1 an arbitrary first level slot opens", and then the grid layout of the character determined which slot matched that criteria.  So I did a similar test with star levels (but less complete than yours )

I tested using the grid bit masks in the player stat block to turn off the element slot that Serge learns at star level 1, and then fought the first boss.  The star level didn't yield any slots at all, which seems to imply that element growth is specifically hard coded somewhere.  I guess it's good to know that's the case, but it would be nice to have a better answer for where that information is stored. 

Oh, and one other thing that I discovered.  The stat blocks for characters only seems to apply at the point they are recruited.  So for Serge, making edits to his grid shape only worked if I started from a save state right as he's waking up at the beginning of the game.  There's probably more nuance here, but that's the only reliable way I've been able to test it.

[glennxserge]

I managed to run the full test on all star levels from 1-99 with all unknown slots checked too.  Ended up with the same result as you, F-man.  So it looks like growth table 0 (Serge, Kid, Guile, etc..) are bound by this leveling chart, regardless of their specific element grid availability:

Code: [Select]

[  22  ][  31  ][  39  ][      ]       ][      ][      ][  78  ]
[  19  ][  20  ][  24  ][  30  ][      ][      ][  69  ][  72  ]
[  12  ][  14  ][  16  ][  23  ][  36  ][  60  ][  63  ][  66  ]
[  07  ][  08  ][  09  ][  13  ][  21  ][  34  ][  46  ][  48  ]
[  00  ][  00  ][  00  ][  05  ][  11  ][  18  ][  26  ][  37  ]
[  01  ][  02  ][  03  ][  10  ][  15  ][  29  ][  35  ][  41  ]
[  04  ][  06  ][  25  ][  28  ][  33  ][  40  ][  43  ][  44  ]
[  17  ][  27  ][  32  ][  47  ][      ][      ][      ][  75  ]

Unfortunately, that means, the next test is chasing pointers and disc reads to figure out where that table lives.  Will let you know if I find anything.

[glennxserge]

   Made some progress tracking down the lookup table.  I was able to trace execution through the star level up routine and find where it's pulling data from.  The game reads in a block of data from 0x13B6B370 on disc 1 (sector mm,ss,ff == 31,16,71), and stores it in memory at 0x80101448.  I don't understand how this data is formatted, it seems obfuscated in a way.  But I did verify it's responsible for which slots open up at specific levels.  If anyone wants to step through it in a debugger, the instruction execution for using this table starts here (after a battle if a star is earned): 801EF130

   The best summary I can make is that the game iterates over this data for the number of current star levels in 16 byte strides and uses the table data with some bit manipulation to determine which slot opens.  It then ORs the value onto another table at 0x80071C7C. 
   This second table is the current state of unlocked slots for all 45 characters in the game.  It's stored as a 2 byte pair of grid bitmasks.  As the star level increases, this table will eventually match the grid bitmasks defined in the character stat blocks
 
   Once this second table has been updated, the routine finishes by iterating across each 2 byte pair, shifting and masking for each slot, and checks the low bit to see if the slot is unlocked.  If that is the case, then the game clears the seventh bit of the character stat block's low byte pair (0x4000 becomes 0x0000), which makes the slot usable.

I still need to dig into that first table to try and understand how it's formatted.  But at least now we know where the data lives on disc.

[glennxserge]

Ah, scratch that.  The data on disc isn't being used in this case, which is really strange because it matches exactly what's in ram.  But, that just means I need to keep tracing this upstream in the game execution.  I think I'm close to finding the answer