Personally what I would prefer to do is use a nice DB manager (ala SQLite or something) and create BLOB databases with all the binary data in it. That would be the idyllic thing to me.
As for reading the data off the disk etc. Do we know EXACTLY what files are used on the FF7 boot up sequence for the PS1?
We also know something about the FIELD directory and the reason Square used direct sector access (it's in another diatribe of mine regarding said file etc.)
There is a large file in that directory that contains everything you wanted to know about the field directory in it.
I think for installation wise since the disks are NOT identical in the FF7 PS1 it might be good to create big BLOB archive packs (not the same as an LGP archive but similar in concept). It might work to have 'Same'/Union information in a single archive and DIFF/difference/different information in DISK related databases. This would end up one BLOB for the main data and 3 smaller BLOB archives for what remains.
I prefer something like SQLite to manage a data base. It's over kill? Yeah it is .. well at first it might appear to be. However being able to know what's in the data base and access it with a more standard interface (IE SQL statements) might be a godsend. Especially when dealing with things that aren't labeled (IE FF8 Xenogears FF9 data). It's just a thought.
Data extraction from the disks, can be done via ye olde PS1 plugins for emulators. These are ideal for this type of thing. Since we know what we are looking for off the disk and can make a utility that will create whatever we want in the end this seems practical. I don't know about distributing a PS1 plug-in though (details?) Anyhow one should be able to invoke from the installer script the external program to perform the file gathering for the game.
To simplify my thoughts
So in summary:- Create a Q-gears specific utility program that slurps data from a disk. This utility likely should have it's own specialized script for said extraction. This utility should be able to identify which disk it is looking at to extract said data (IE FF7 disk 1 etc.)
- Optionally utilize a real database system ala SQLite (public domain), and sqlite3x (c++ wrapper also PD) to create the databases for the games stored information on the target system. This adds the possibility of later improvements in Q-gears in terms of functionality and dealing with large volumes of data consistency of the interface to run the games etc. Unfortunately SQLite is limited to 2 telibytes (2^41 bytes) sized databases and Strings and BLOBs up to 2 gigabytes (2^31 bytes).
- The utility should be able to be invoked from an installer with it's correct script information for it to acquire data etc. from the CD.
I don't think everyone will like the idea, however it will do some things, first keep the data from being strewn all over, second keep the data better organized, and thirdly give the option of doing more with data later on. Most groups consider a database expost facto in such things. Considering the volume of data we are dealing with, it might be better to do so before things get really unweildy. The Database idea perhaps will also help with the injection of XML scripts etc into the engine later on. Remember it's only an idea.
I just hate everything being piled like a junk yard into directories.
On a side note most of these objects are accessed via numerical values from the script no?
Cyb