Restore Type?

I'm sure I've written about this before, but I wanted to remind myself. I've been digging through the exe again trying to find out what the "Restore Type" really is in Attacks and Items. Well, it looks strange. For Attack's part, it looks like that byte is ignored completely. It does something for Items though, but it looks like only in the menu. Here's the deal. There's basically a function I called GetRestoreType that takes two parameters: A constant that tells it which RestoreType to get, and an index. The constant can be 0, 2, or 4. Anything else and it acts like a 0 was passed.
Passing a 0 returns a null value, passing a 2 would return an Attack's RestoreType, passing a 4 would return an Item's RestoreType. Well, the game never passes it a 2. Attacks' RestoreType is pointless. Here's how it breaks down:

Outside of function:

0x6D9A4E
if (getRestoreType(4, ItemIndex) != -1) call some_sub(-1, -1, 15h)


0x6D9D37
if (getRestoreType(0, "Something") != -1) call some_sub(-1, -1, 15h)

long getRestoreType(int constant, int Index)
{
   int tempRestoreType = 255;
   long returnValue = -1;

   if (constant == 4)
   {
      if (Index < 127)
      {
         tempRestoreType = ItemData(Index).RestoreType;
      }
   }
   elseif (constant == 2)
   {
      tempRestoreType = AttackData(Index + 72).RestoreType; //E.Skill Attack Indexes
   }
   if (tempRestoreType != 255) returnValue = tempRestoreType;

   return returnValue;
}

Then, after the function calls mentioned above, the returned value is checked against -1 and a sub is called. Thing is, the one that passes a 0 will always return a -1 so that one's worthless. The one that passes a 4 returns the item's RestoreType just fine, but doesn't seem to do anything with it once it has it. The sub that is called is sub_6D0AF9(-1, -1, 15h) with an unknown function. This is its code:

some_sub (long val1, long val2, byte offset)
{
   *[0xDC2068 + offset] = 1;
   if (!(val1 = -1 || val2 = -1))
   {
      *[0xDC3630 + offset * 98h] = val1;
      *[0xDC3630 + offset * 98h + 2] = val2;
   }
   *[0xDC3630 + offset * 98h + 8] = (([0xDC3630 + offset * 98h  + 4] - val1) >> 1);
   *[0xDC3630 + offset * 98h + 10] = (([0xDC3630 + offset * 98h  + 6] - offset * 98h) >> 1);
   *[0xDC3630 + offset * 98h + 12] = 2;
   *[0xDC3630 + offset * 98h + 14] = 2;
   call off_91E638[offset*4];
}

For items, the offset will always be 15h so we can fill in the blanks and simplify:

some_sub (-1, -1, 15h)
{
   *[0xDC207D] = 1;
   *[0xDC42B0] = (([0xDC42BC] + 1) >> 1);
   *[0xDC42B2] = (([0xDC42BE] - C78h) >> 1);
   *[0xDC42B4] = 2;
   *[0xDC42B6] = 2;
   call off_91E68C;
}

off_91E68C is labeled as some system function "__initp_misc_winxfltr_88". I have no idea what that means. Winxfltr looks like some kind of error message library. The other addresses are part of a large set that I don't see any significance to in the code, but I'm sure there is one once the game is running.

That's all I have on this.

See? I still got it.

WM:
I've modified the Materia Tab in the spirit of the Attack, Item, and Weapon Tags. The Materia Type is to be split into two types. Materia type is handled in this way.


PrC:
So I just looked back into the function that finds orphan AI lines. An orphan AI line is one that can't be called because there's no jump to it and the code always jumps around it. It happens in quite a few AIs. I just found at least seven in Eligor's Main script. Why did I bother identifying 7 lines out of over two hundred? Because by deleting those 7 lines the AI disassembly works the way it ought to. Errant jumps always made it spasm and think there are too many if statements and go all wacky.

New limitation

I just learned, while trying to find something else, that the maximum kernel2 text size for the PC version is 27K (27648 bytes) including all file headers. The PSX is likely smaller than that. This is a limitation I'm going to impose in the next version.