Progress Update:
What I have completed:
Database Structure, Access, and Encryption
Program Logic (How it decides to deal with the mods and files, and various failure scenarios)
Graphical User Interface (about 80%)
Not yet Completed:
Mostly the file manipulation
- Scanning files
- Adding Mod
- Removing Mod
- Changing Mod
At this point I really need some input.
This is how the program is designed to interoperate with SFC:Orion Pirates Mods so far:
The program will be released with only the basic Taldren files as part of its DB. (ftrlist, shiplist, models.siz)
As mods edit files, the program will adaptively back up files edited by the mod to another location.
-- This is to preserve hard drive space, and to maintain efficiency.
The DB Structure:
I have a few things in there, but only thing concerning the developers is how thier mod will appear in the DB, so they know what information the program will need.
Each Mod will have its own table. The table will store inforamtion for each file the mod is made of.
Each table will have the following fields:
FileName - Name of the file (shiplist.txt)
Source - Its location in the file system (Ex. OPDir\Modifications\<ModCode>\Specs
Destination - Its destination if it has one (Ex. OPDir\Assets\Specs)
FileHash - The MD5 of the file. Not required for each file, but recommended for at least the critical files, such as the shiplist.
Mandatory - True/False field letting the program know if the Mod will function w/o this file, stock files will be used (Ex. Mouse cursors)
Another table holds information about the mods themsevles.
Feilds:
ModCode (ex. opplus)
ModName (ex. OP+ 4.0 by FireSoul)
ModLocation (Ex. OPDir\Modifications\<ModCode>
ModHash - MD5 of the Mod's installer file (more on this later)
ModUninstaller - the command line text (including parameters) to call the mod's uninstaller to silently remove the mod
The DB is not direcly editable. For the information about the mod to make it to the DB, the dev will have to provide two files containing the required information. I suggest the files be a simple CSV db format. The program will detect the files and import all required information to its database.
I suggest the Mod install the files to the 'OPDir\Assets' directory. This allows an immediate detection of new mod being installed, its data imported to the Db, and available for use. The program will move this file to the root its Mod Directory.
The two files could be: FilesData.txt and ModData.txt
ModData.txt layout:
ModCode, ModName, ModLocation, ModHash, ModUninstaller
FileData.txt
FileName, Source, Destination, FileHash, Mandatory (simple 'true', 'false' text should do for the mandatory field)
Aside from the DB:
I am trying to decide how to handle a severe failure of an OP installation.
I can make a procedure that will scan OP for to verify if all files are OK but those mostly likely or commonly to become corrupted.
The question is:
What are the bare minimum files need by OP to work? (Stock 2552, nothing else)
Models
Scripts
Lists
Cursors
Music
Sound
ect.
And what of this list can be made readily available for download?
Lists
cursors
scripts
Once we have decided on this information, we can make a Recovery Installer to bring these files to OP in order to avoid a reinstallation of the whole thing.
As it is, this new version is designed to treat even Taldren v2552 stock files as a Mod, so if they go, Op still works, you may load others mods. This is becuase the Taldren files are reaily available for download, and people do not really play that mode anymore.
I need thoughts and opinions. I don't want to spend all this time on this project (which I enjoy) to have a Mod producer come up later and tell me "Well this just isn't feasable."
I also do not want to miss any points or cause incompatilties.
Thank you for any input you have.
Topic: Strat and Bonk - Mod Chooser, SFC Direct integration - Mods standardisation (Read 22905 times)