Another embarassing error

So I finally found someone that had an error that I could play with. Armorvil was kind enough to send me his kernel2.bin that wasn't loading correctly. Well, WM wasn't loading it correctly at any rate. He thought it was weird that once WM failed to load it, the original text would still be displayed. Indeed it is a bit strange, but that's because it's already loaded the text from the KERNEL.BIN that the PSX uses. So if it tries to load kernel2.bin and fails, WM will use the KERNEL.BIN text that it keeps handy. Pretty neat, huh? :)

Anyway, what the problem really was is that the buffer I had allocated for uncompressed file size wasn't large enough for the text he had compressed. I try to dynamically allocate memory so not to use too much or too little so I just set the uncompressed buffer to twice the compressed file's size. Not a bad theory, but his compression ratio was GREATER than 2:1! That means the resultant uncompressed file is MORE than twice the size of the compressed one so the buffer I had allocated to hold it was no longer large enough. Bummer. Since I know now that the normal limit for uncompressed text in FFVII.exe is 27K (refer to previous entry) then I set the size to 32K (since I know that Aali's customizations allow for larger text sizes).

Also, I've been getting complaints that after lots of editing, sometimes the text will get jumbled and confused with other texts. I believe this is a problem with the way I'm compressing text on listboxes. So if you had.....something like... aww, heck with it. I have no idea what it thinks it's doing. It changed

Cotton Dress
Satin Dress
Silk Dress
Wig
Dyed Wig
Blonde Wig
Glass Tiara
Ruby Tiara
Diamond Tiara
Cologne
Flower cologne
Sexy Cologne
Member's Card

into:

Cotton Dress
Satin Dress
Silk Dress
Wig
Dyed Wig
Blonde Wig
Glass Tiara
Ruby Tiara
Diamond Tiara
Colog lower colog Sexy Colog Member's Card
lower colog Sexy Colog Member's Card
Sexy Cologne Member's Card
Member's Card

If anyone has an explanation or theory as to how "ne\n" gets changed into " " let me know.

NEW UPDATE!!!

Rejoice! I actually did something! DLBP from qhimm contacted me two days ago and requested that enemies be able to be synced across the scene.bin. So I did. Since I was able to copy/paste enemies already (although they should really be called "actors") I just used that to copy the enemy data and AI and replace others using the same model. THAT'S THE TRICK, THOUGH. Every enemy uses a different model number even if the contents of the models are identical. There are at least six different Chocobo models alone and all of them are identical except for the files that contain them. Obviously you wouldn't want to replace the Wonderful Chocobo with the Poor one, so I'm going to have to restrict it by model ID. Characters of the same model ID can be synced with its copies. For example, Grunt (model ID of 0013h) exists in eight different scenes. I want to modify all of them, but to keep it straight I can now just modify one and say "sync all enemies with model ID 0013h". It's actually a rather quick process and I'm pleased with it's performance.

If another custom enemy is using that model it will be replaced, name and all! The way to prevent that is set the custom enemy to some bogus model number (which is being moved to the new stat editing screen) and then do the replacement then switch the custom enemy back.

Long overdue news

You ready for this? I got nothing. Really. This has been a tough last quarter-year for me and I haven't had the chance to even look at the code for either WM or PrC. I was taking a class that just ended today, I had two (sort of, it's complicated) deaths in the immediate family within a week of each other, my lappy's finally hit the big one, and I got a new laptop at work which won't take my external backup of my older one that had all my FFVII reversing info on it.

I'm not back to square one or anything, but I haven't had IRL time to devote thought to these projects. Hopefully, come the new year I'll be less constrained and have a new laptop.

I haven't given up on or lost motivation any of this. There just technically isn't time to do anything with it.

A little random thought....

WM 1.4.5 is out now and the links to it are on Qhimm's forums. Blogspot is being a pest and won't let me update them. When I'm able (and remember to) I'll do that. A few things were added and fixed so check them out.

Last Saturday was WM's second birthday! Or do you call those "compile days" for computer programs? Meh, one of the two I'm sure.

Since that's done I've been working on a camdat editor. I'm getting closer to what I want it to be. It's really basic because most of the cam script is unknown and I'm just basing it on what I DO know. Mostly what codes take what arguments and such. It's not done, but it's coming along nicely. Of course, the last 10% of it is likely going to take 90% of the time as usual.

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.