Anonymous

Changes

From Final Fantasy Inside

FF7/Battle and growth data

4,569 bytes added, 05:11, 23 May 2019
m
25 revisions imported
| 0x0000
| 56 bytes
| Character data: Cloud ([[#Character_data_layoutCharacter_data_record|see below]])
|-
| 0x0038
| 0xF1C
| 64 bytes
| Scene.bin look-up table ([[#Scene.bin_Look-up_file_layoutup_file|see below]])
|-
| 0xF5C
|-
| 0x09
| 47 1 byte| FF (padding)|-| 0x0A| 1 byte| Starting Level|-| 0x0B| 1 byte| FF (padding)|-| 0x0C| 1 byte| Limit Command 1-1|-| 0x0D| 1 byte| Limit Command 1-2|-| 0x0E| 1 byte| Limit Command 1-3 (UNUSED)|-| 0x0F| 1 byte| Limit Command 2-1|-| 0x10| 1 byte| Limit Command 2-2|-| 0x11| 1 byte| Limit Command 2-3 (UNUSED)|-| 0x12| 1 byte| Limit Command 3-1|-| 0x13| 1 byte| Limit Command 3-2|-| 0x14| 1 byte| Limit Command 3-3 (UNUSED)|-| 0x15| 1 byte| Limit Command 4-1|-| 0x16| 1 byte| Limit Command 4-2 (UNUSED)|-| 0x17| 1 byte| Limit Command 4-3 (UNUSED)|-| 0x18| 2 bytes| Kills required for Limit Level 2|-| 0x1A| 2 bytes| Kills required for Limit Level 3|-| 0x1C| 2 bytes| Uses required for Limit 1-2|-| 0x1E| 2 bytes| Uses required for Limit 1-3 (UNUSED)|-| 0x20| 2 bytes| Uses required for Limit 2-2|-| 0x22| 2 bytes| Uses required for Limit 2-Placeholder3 (UNUSED)|-| 0x24| 2 bytes| Uses required for Limit 3-2|-| 0x26| 2 bytes| Uses required for Limit 3-3 (UNUSED)|-| 0x28| 4 bytes| HP Divisor for Limit Level 1|-| 0x2C| 4 bytes| HP Divisor for Limit Level 2|-| 0x30| 4 bytes| HP Divisor for Limit Level 3|-| 0x34| 4 bytes| HP Divisor for Limit Level 4
|-
|}
70 * ((13-1) ^ 2) /10
70 * (144 / 10)
70 * Floor( 14.4) 1008 980 additional XP
The savemap contains information about the needed XP to get to the next level for each character so it can be assumed that the game only performs this calculation at level up and changes the needed XP stat accordingly and compares that against the total XP the character has to determine when the next level occurs.<br/>
To calculate the total XP needed for a given level:
XP = XP + [Mod * (I ^ 2) / 10]
Next I
The Mod only needs to be assigned based on the character's current level.
==== Character AI data ====
Section contains 24- Placeholder byte header representing 2-bytes per script block (1 per character?). Each number is an offset from the beginning of this block to the actual AI data. Each script block follows the same AI data found in the [[FF7/Battle/Battle_scenes#AI_Data|Battle Scenes]].A basic disassembly of the characters' scripts can be found [http://forums.qhimm.com/index.php?topic=7928.msg97889#msg97889 here] ==== Scene.bin Look-up Table ==== In order to understand the purpose of this table we must understand the structure of the compressed and packed [[FF7/Battle/Battle_scenes|scene.bin]] file. It is divided into blocks of 8K in size. Each of these blocks begins with an array of pointers that point to a compressed array of bytes that contain a single scene file. There can be between 1 and 16 inclusive scenes in each of these blocks. There is no direct indication of how many scenes are in each block other than searching through all the headers to find the desired one. It would take a noticeable amount of time to search through each block when the greater valued formations are requested. The working solution to this is a look up table that would tell the scene retrieval method which block contains the desired scene. Enter the Scene Look-Up Table (hereafter abbreviated SLUT because I can :) ). When a specific formation ID is requested, the Scene File that contains it can be determined like this: Scene File = ( Formation ID AND FFFC ) >> 2So, for example, we know that formation 134h would be in scene 4Dh. Without searching through all the blocks as noted above, this table serves to indicate what the first scene is in each block of 8K. When a formation is to be loaded, the containing scene file is retrieved as mentioned above then the SLUT is looped through to find the lowest value greater than the requested scene then uses the value BEFORE that.  Example Unmodded SLUT: 00 0C 12 19 21 27 2D 35 3D 49 51 5A ...etc Desired scene is 4D. 51 is first in that list greater than 4D. Value to the left of that is used (49). Then we know that the 10th block in the scene.bin contains the scene and formation we're looking for. The rest of the details of what happens next don't matter. This is all that involves the SLUT.
==== SceneThis needs to be checked/updated each time the scene.bin Lookis compressed and repacked. If not it can lead to errors and out-up file ====of-place formations being used.
As you may knowan example, [[FF7/Battle/Battle_scenes|scene.bin]] file is divided into banks or sections. There are 33 total sections, and each one is 8192 long. Each section contains 5 - 20 files, based on their length. If archive is modified and if a modder changes the one of the files is bigger than before, scenes in the first block it must may not be put able to fit together in the next section, which'll probably cause an 8K block of compressed space with all its original "brothers." The last file scene in this section to be put block is then kicked out of that block and into the next. Now each scene in the next block is off by one, etcfile. This look-up table contains data about how many files are in each sectionwill domino onward displacing scene after scene until a block with enough padding can absorb a new scene without going over the 8K limit. It begins like this:
00 0C 12 19 21 27 2D So if formation 31h is requested it will see that formation is part of scene 0Ch which is the first scene of block three.But since one of the scenes from block 1 became the first scene in block 2, the game will load the second formation in the first scene which won't match the one we're really looking for.The solution is to change the second byte in the SLUT to 0Bh which will correctly indicate that the desired scene is actually the second scene of block two.
Which meansAlso consider if scene 0Bh were requested. The scene retrieval mentioned above leads the game to conclude that scene 0Bh is in the first block. However, when it tries to loop through the pointers in the block, it will find a null pointer. Then an error beyond your imagination will occur:the game will crash!! D: (not verified, but probably around 0x5D116B)
Section 1 contains 0x0C - 0x00 Both [[http://forums.qhimm.com/index.php?topic= 12 files Section 2 contains 0x12 - 0x0C 7186.0 Hojo]] and [[http://forums.qhimm.com/index.php?topic= 6 files Section 3 contains 0x19 - 0x12 = 7 files 8481.0 Proud Clod]] will examine this SLUT automatically and make changes accordingly.The moral of the above story is use one of these programs when altering the scene. bin and so let them take action accordingly onthe KERNEL.BIN.
Everytime you modify scene.bin file, you must also keep this table updated, or you'll end with VERY random encounters (wrong battles in wrong places). You can use [http://forums.qhimm.com/index.php?topic=7127.0 SceneFix] program, which'll update the table for you.
Bonus Info: Since there are only 64 bytes allotted to this table, there must be no more than 64 blocks in a scene.bin file which indirectly limits its size to 64 * 8K or 512K.
==== Magic Order ====
NOTES:
*If a value is repeated, that attack will override the previous listing.
*The final two bytes are NULL (0xFF) so the game moves the Attack pointer ahead to load the summon attacks(?).**Even if these were not NULL, they would be ignored.