Changes

This section explains how the LGP archives from FF7PC FF7 PC are constructed. There's probably no reason why If you'd need to know this (Plugre looking for a tool that already manages LGP archives, try [[User: Use my Ficedula|Ficedula]]'s [http://www.ficedula.com LGP Editor] !) but the file format might be useful to SOMEBODY.

The first item is 12 bytes containing the file creator. This is a standard string, except it is "rightaligned". In other words the blank space comes BEFORE before the actual text, not after. Oh: In FF7 it's always "SQUARESOFT" preceded by two nulls to make it 12 bytes. The only other thing you might see is the header "FICEDULA-LGP", which I use to indicate a file is an LGP *patch* one of my programs has constructed, not a complete archive.

This code is used to validate the LGP archive. The bad news is I have no idea how to make it (I've figured out how to decode it, ie. find out whether the archive is valid ... , but I can't create my own). The good news is you don't need to! The ONLY only thing this CRC is based on is the number of files in the archive (maybe the filenames too ... , haven't checked that). Anyway, the TOC is the only thing this check relates to. So if you're replicating an archive from FF7 for use in the game with the same number of files and filenames (and what ELSE would you use LGP archives for?) you can just copy the CRC section from an existing file. Cheap but effective :)

Normally it's 3602 bytes long. I think (one archive was may be different? Maybe , possibly MAGIC.LGP - can't remember). Anyway, one normally-safe way of calculating the CRC size is to find the end of the TOC and the beginning of the first file. Anything in between is probably CRC code. (Not this is not guaranteed to work! . It works with "official" archives but editors - such as mine [http://www.ficedula.com LGP Editor] - can screw around with alter the TOC to achieve extra things).

The data from the files. However it's not that simple: the TOC doesn't list how long each file is (somewhat useful!). It's done here. The offset in the TOC is actually the position of yet another file header. Format is:

My [http://www.ficedula.com LGP Editor ] uses this to its advantage in the Advanced Editor. If you want to replace a file in an LGP archive with your own copy, it just sticks puts the file on the end of the LGP, writes a new file terminator, and updates the TOC to point at the new file. (Advantage: Fast). It even lets you link two TOC entries to the same data :) or have "inactive" files in the archive that aren't referenced by any TOC entry.

I don't know whether the file terminator has to be intact, but for safety's sake my editor preserves it. The CRC DEFINTELY has to must be present and correct. Also, if you're replacing an archive with you're own custom version make sure it has filenames in the TOC matching the ones in the old one, ne?.

Oh: The game doesn't check archive sizes so as long as all filenames are present. So if you want, you could replace an archive containing 95 files with a 98-file archive, so long as 95 of those 98 names matched those present in the original 95-file archive! . (ThereHowever there's no point in doing this - after all, when the game won't use any files OTHER other than the 95 it's expecting to find).

Other point: I've heard There are reports on [http://forums.qhimm.com Qhimm's message board ] that once you've f***ed altered an archive and the game refuses to read it, it won't EVER ever read it until you reinstall - even if you fix the problem/restore from a backup. The idea was generally scorned and ignored, but I'll mention it because something like that happened to me. Then again, it COULD have been because I upgraded basically everything in my PC; so no No solid conclusion to can be drawn here.

Further point: (due to changes in my LGP Tools/Cosmo programs) Sometimes, there are data "gaps" in the file that don't appear to be referenced by any file - even by an inactive file. This happens due to the way my programs update archives. If you're only using the TOC method to get at files (the easy way) then you won't notice this anyway. However, if you're stepping through the file header by header, even reading the unused ones, this can cause problems. If you use my program to update a file with one that's smaller than the original (can happen) then it writes it in, but leaves a gap after it (of course). However, to help you out, after the end of the file, it writes a 4 byte integer saying how much more space to skip over to reach the next file header. This really doesn't affect many things - only tools (like my Advanced LGP Editor) that bypass the TOC to construct their own file lists. FF7 never notices a thing.