Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: penguin on July 09, 2002, 11:48:12 am
-
Since I'm stuck w/ the OpenGL implementation right now :mad:, I've been thinking about other things that would be nice to have, and one of the things that came to mind was some sort of mod manager. I don't know if it's been discussed here or not...
The premise, as most of you know, is that keeping track of mods as a player (not to mention distributing them, etc.) is a pain. Heavy editing (and backing up) of the ships.tbl, weapons.tbl, managing POF files and VPs... etc.
WARNING: some of this might be construed as heresy :devilidea- VP files are replaced with ZIP files. We get all of the benefits, plus compression, plus many third party tools for manipulating zipfiles.
- ships.tbl and weapons.tbl would cease to exist :eek2: instead, every ship and every weapon would have its own ".tbl file" (e.g., "tables/ships/herc_mk2.tbl" "tables/weapons/subach_hl7.tbl" etc). Obviously if they were all on disk, this would be a lot of files, but since they're rolled up in a zipfile, it shouldn't matter, and the storage requirements would be identical.
- Not too sure about this one -> A new UI screen would be added, maybe in the Options screen to manage which weapons/ships are available. I guess you could also have the option to delete "packages" from your disk entirely.
- Not too sure about this one -> There would be (within the game, again maybe from the Options screen) a download manager to pull mods (ships, weapons, missions, campaigns) via http or ftp and install them without restarting FS2.
- Every campaign would have associated with it the ships and weapons it requires; when that campaign is downloaded, it would:
1. validate that all required mods are present
2. use the "download manager" to get the ones that are missing (obviously the campaign would need to specify a URL where they can be found)
3. mark all required ships/weapons as active, and deactivate the others
- we could also add versioning info in the files for the mods...
- more stuff as needed :D
The benefits to the modders: make your POF file, create the ship or weapons entry, put the two together in a zipfile and distribute it -- no hacking of ships.tbl or weapons.tbl needed.
The benefits to the mission/campaign designers: write your missions, package the FS2 and FC2 files up into a zipfile, along with a list of required ships and weapons, and distribute it.
The benefits to the player: you can get a mod by downloading one zipfile, and your existing ship/weapons entries are untouched (unless you're upgrading to a new version of the mod). Ditto for campaigns, which would be "smart" enough to retrieve any dependent mods automatically. And it could all be done within the FS2 interface -- no need to go out to MSIE, pull down files, back up your old ones, unzip them, and restart FS2.
Obviously, this is a pretty large-scale redesign of the way files are now handled, and backward compatibility is always an issue...
This is my first draft, so feedback is welcome!
PS: I wonder why :V: chose the .VP file format rather than zip files from the beginning? Maybe they wanted to hide the internals (like the "scrambling" of missions & tbls in FS1)? Then the modding started (but I wasn't around back then...)
-
My idea:
The mod manager should contain an expandable list. The top level would be all campaigns and an All folder (For all installed mods). Inside each top-level item would be the various types of mods (Music, Weapons, ships) which could be expanded to show each individual ship, weapon, and such. Each level could be checked to include all components below that level.
- Main Freespace Campaign(*)
|-Ships( )
|-Weapons( )
|-Sounds( )
|-Music(*)
|-...
- The Apocalypse Project(*)
|-Ships(*)
|-Weapons(*)
|-Sounds(*)
|-Music( )
|-...
+All(*)
-
i like WMCoolmon's idea...and this could be done by separating the mods into folders
If something like this is done, i would like to see a campaign manager which will select which tbls are valid for what campaign and which ones aren't, so that when the player selects a new campaign, the correct mods are automatically enabled and the ones not used by the campaign are disabled.
-
Sorry, I wasn't clear on that :o.
To a campaign, where the mods are stored doesn't matter. In the previous example, if TAP uses the same weapon as the Main Freespace Campaign, it'll still be in the TAP section-all you'd have to do to use TAP is uncheck everything and then check it.
-
ah, i see...thanks for clarifying
-
All this seems good - but I'd just like to keep one thing pointed out. It'd be best to keep major developments on the source code side of things to the standard releases of the FSSCP file. Branching out into hundreds of .EXEs which each do slightly different things... would not be to helpful. Especially if later modifications of the code make major advances which mess up earlier mods made with it etc.... that aren't "endorsed" by a version of the code....
If that makes sense - great :)
-
Originally posted by Thunder
All this seems good - but I'd just like to keep one thing pointed out. It'd be best to keep major developments on the source code side of things to the standard releases of the FSSCP file. Branching out into hundreds of .EXEs which each do slightly different things... would not be to helpful. Especially if later modifications of the code make major advances which mess up earlier mods made with it etc.... that aren't "endorsed" by a version of the code....
If that makes sense - great :)
hehe, forking isn't a problem. At the moment, I'm the only one who has checked anything into the fs2_open project in warpcore's CVS (in fact I think Inquisitor is the only other one with write access)
*looks around for Lord Farquad image*
;)
-
http://www.3dap.com/hlp/staff/thunder/image_farquad.jpg
:)
And I see your point, just making sure people don't forget the trouble of branching with things like code.
-
Why not just tell freespace to allow multiple tbl, or instead, multiple vp, that way when you go into freespace to play the mod, all you have to is go choose your campaign. The code will know where to look for the info needed to play that campaign. Or it will search for it, i don't know which is easier or more feasible, it's just an idea.
-
Actually, Mysterial has access as well.
WM and DTP will have access tonight ;)
p.s. if I can remember how.
-
ShadowWolf_IH has hit something I like.... I think that the tables are becoming our best friend in this respect...we can add to another table or include in an existing one packaged with mods information on what code to use or .exe to work with. Thus selecting another file is a matter of changing the tag in the tables. Everyone should know how to do that by now ;)
-
Originally posted by Thunder
ShadowWolf_IH has hit something I like.... I think that the tables are becoming our best friend in this respect...we can add to another table or include in an existing one packaged with mods information on what code to use or .exe to work with. Thus selecting another file is a matter of changing the tag in the tables. Everyone should know how to do that by now ;)
Right, kinda what I was saying (though with way too many words as usual :o). Multiple VP files is NP, the engine does that now obviously... the issue is mutliple files of the same name (e.g., ships.tbl) Thatt's why I suggested each ship going into its own .tbl file. And the manager bit was so that the parser wouldn't freak out if it found 3 entries for a Myrmidon in the 3 different TBL files. It should't matter, though, and all these issues are surmountable...
What about using ZIP files instead of (or in addition to) VP files? Does anyone else think this is worthwhile?
And this is way down on the priority list, I'm sure, but... I would LOVE to completely redesign all the .tbl files so that they could more easlity parsed. Somthing like XML would work nicely :nod:
-
We could (probably) implement this pretty easily and still retain compatibility with older packages (so long as we don't change the TBL files) and make it so that when Freespace reads the campaign file, it uses it to discover what mods it uses and where to find them, which would be in the form of a VP file. Freespace would then use this VP file in much the same way it does things put in the data/ folders.
The mod manager could have its own VP file that it would modify, and would also have a built in TBL parser so that you could select what elements you wanted (including missions) and then compile the changes (as in make the TBL files for the mod manager VP), open it up in Freespace 2 and play it :D
-
but what if there is more than one version of the Pegasus? if someone were to edit its entry for just one campaign, it'll either have to end up renamed or it would affect all other campaigns
-
Originally posted by LtNarol
but what if there is more than one version of the Pegasus? if someone were to edit its entry for just one campaign, it'll either have to end up renamed or it would affect all other campaigns
You have that problem now... if you edit ships.tbl to change the Pegasus, it will affect all campaigns.
But I get your point, and it's a good one; that's one of the PITA things w/ the current system that we want to fix :D That's why we need to take some time to think about the best way to implement this.
One way would be version numbers and/or tags: e.g., if the Derelict campaign used a modified Pegasus that you had released, it's entry could have some sort of tag like "Pegasus/LtNarol/1.2" embedded in it... by default it would be "Pegasus/Volition/1.0" or something. Then the Derelict campaign would have ...
requires-ship: "Pegasus/LtNarol/1.2"
requires-ship: "Orion/Volition/1.0"
requires-weapon: "Subach HL7/Volition/1.0"
... in its dependecy list.
Still just brainstorming here...
-
Two thoughts:
1) The VP files contain an internal directory structure which I can only assume needs to be maintained for the engine to be able to find all of its required files. Using ZIPs would lose this structure, would it not?
2) Perhaps a very easy way to perform many of the functions you are talking about, penguin, could be accomplished by simply getting to engine to look for VPs (or ZIPs or whatever) in subdirectories, instead of only in the main FreeSpace2 directory. Each campaign then simply has its own folder, and the "manager" need only find the right VP in its folder and use it. As it stands right now, any campaign packaged into a VP must be placed into the main directory, where they conflict with one another(alphabetical precedence rules all, I believe). This method would still leave the campaign maker with the task of hacking tables for his campaign, but by the time one makes a whole campaign, table hacking for it is just a drop in the bucket.
The only major hitch I can see in this plan is that the engine currently gives all information in the data directory precedence over any VP, so this would also have to be changed. (I.e. altering the code such that if one wanted to use one's custom information in the data folder, one would select "Custom" in the manager instead of "Derelict" or "Reciprocity".)
-
1.5' :D : zip files can (and frequently do) contain a directory structure, so that's not a problem.
I agree the solution of looking for VPs or ZIPs (let's call them "packages") in various directories would make things a little easier. But it still means the player has to have a mishmash of packages scattered about, with many of them containing a large amount of redundant information. And hacking the ships.tbl is a fairly trivial process to most modders, but it transfers the onus of maintaining all this stuff onto the player. And I assume the current trend will continue towards more and more non-Volition ships and missions, it will only get worse (or better, depending on your perspective :D)
Food for thought, though; thanks for the feedback.
-
So, theoretically, what would the pseudo code for a "package manager" zip or otherwise look like?
Lets design it here ;)
-
About the problem with identical ship designs, I suggest an ID system. Each ship model would have an ID , and the stats for the mod would have an ID. An online database would keep track of all the 'official' numbers, which would start at a nice even number. For the sake of an example, here are some numbers:
ID #s
0-100=Ship from Freespace or Freespace 2
100-500=Local ships, not to be used in an 'official' mod.
500+=Everything the Freespace community cooks up and validates in the database
Model #s
Hercules-1
Perseus-2
Pegasus-3
Ulysses-4
Stat #s
...same as above...
DeathHerc-101
Perseus III-507
Pegasus W-640
Pirate Ulysses-105
Now, let's say I want to specify the DeathHerc, which uses the Hercules model. All I'd do would be to combine the Stat # (101) with the Hercules model (1) and put that in as a requirement in the campaign with a line like so-
REQUIRE SHIP "DeathHerc" 1:101
Freespace reads the line out. 'REQUIRE' tells it this is some external file the campaign needs, 'SHIP' tells it that the object required is a ship, "DeathHerc" is the display name to be used for the mod manager, and '1:101' tells freespace that the ship uses the Hercules model (Included with FS) and the DeathHerc model. Because the number is greater than 100 but less than 500, freespace searches through local directories until it finds it.
Now, for the Perseus III:
REQUIRE SHIP "Perseus III" 2:507
This time, because the stats are ID # 640, Freespace knows that the mod is an 'official' one. It looks for it on the hard drive and then on the net, instead of just the local drive; if it finds the version on the net is different, it prompts to replace the one on the local system.
But what if you try to do the same thing with a 'Pirate Ulysses' and a Pegasus, and put this line in your campaign requirements?:
REQUIRE SHIP "Pirate Ulysses" 3:105
There are two things that could happen. One, if the model and the stats agree with each other then Freespace will integrate them like the others. Otherwise, it would display an error message.
The system can be easily adapted to work with other types of mods as well-interface, music, sound, weapons, even missions.
-
WM: While the idea of using ID numbers could work, I think that sticking with just the names would be easier -- it's certainly more user-friendly, and there's less chance of a namespace collision (and who assigns ID numbers?). To distinguish further, we could put a campaign and/or modder name as a prefix or suffix or something. (Like I said in my earlier post. Call me stubborn ;)) And specifying the model used by a ship is a little redundant, as it's already in the ship.tbl description.
In any event, we probably do want to have a way to identify official (FS & FS2) objects -- ships/weapons/missions/etc. -- and maybe treat them a little differently, I dunno.
Inq: pseudocode, hrm... gotta think about this more... give me a day or two, it's been rough at work :(
OT: Is there a reasonably comprehensive repository of all known 3rd party missions/campaigns/ships/etc. ?
-
The mod manager would really be a nice thing to have. I have a few ideas of my own to add. Each mod could have a chance to have its own description file, which defines what changes are needed. This would be a simple ASCII file that just has the information needed to make the changes, like .sfv files with .rar files or .cue files with .bin files (poor examples, but I'm sure you get my point). When the mod manager opens a description file it then searches for the needed mods and displays the user what changes its going to make or what mods are missing and cant be used. This still doesn't solve the identification problem and I cant think of a good solution for that. Maybe the description file could point out where and what to look for and read the description files for signatures, or something ("do you really want to install this mod signed by athropy"). But the main thing here is that this way the manager would have a nice opportunity to use a "Save as" function to store your current mod status and "Open" to have a quick access to specific mod changes. I dont have a more practical view than that, just an idea.
-
great idea this mod manager!!!!
probably the faster (not sure the best) way would be a new subdirectory system
something like:
-freespace2
-------data
---------------standard subdirs
---------------mods
all the new ships, textures, anis, tbl's of a mod are contained in the mods subdir with this structure:
---mods
---------------(example)TBP
------------------------------------data
---------------b5
------------------------------------data
---------------robotech
------------------------------------data
then the mod manager, maybe a different exe than fs2.exe if we want to have the fastest way to be developed, activate/deactivate the mods by simply copying/deleting from the main "data" directory to the "mods" subdirectory and viceversa
another possibility would be to have fs2.exe to "know" that this new subdir ("mods") exists and to check it for mods that will be managed inside the game, this would require freespace code editing obviously but will be also more powerful since it would allow us to have a "mods" subdir inside a vp file....eh!
the point is that with this subdir system you wouldn't have problems of different ships with same name and tables confusion
-
BTW, I think V used the VP format instead of zip's to prevent the time overhead of decompressing them when the game initialised.... I seem to remeber it being mentioned...
I'm a little wary of this scale for redesign, as far as seperate tbl files go. I think it would be a lot easier to make a program that takes a txt file and appends it to a correct place in the ships.tbl (for example), and simply increasing tbl limits for the actual FS2 code... i.e. (thinking in Java here)
Driver class
Main;
-loads ships.tbl from a set location, loads the mod file.... maybe have the mod file denoted with 1/2 lines of control data (species, mostly). Java saves as ASCII, so no real compatibility issues
- Calls method to fit in the entry & resaves the file
Parser;
- Identifies species from control data
- Reads data into a queue structure (unlimited size)
Writer;
- Copies the Queued data directly under the aprropriate 'species' entry in the ships.tbl.
Other, more important & later stuff could be tallying the number of ships in the file (counting the $name tokens parsed?) and giving a warning if they are ecceded, format checking, and error handling for unknown species.
For removal, it would be a bit tougher - I'd guess specifing the name of a ship (first tbl entry...). Once $name: xxxxx is found, deleting everything until a space is encountered.
Obviously it would require some user control to ensure formnatting, but it's simple as hell to implement.... I'd need to revise the various tokenising classes, but it would be simple in Java... my C's very rusty & limited, but I think it wouldn't be too hard with anyone fluent in that, either.
-
Originally posted by aldo_14
I'm a little wary of this scale for redesign, as far as seperate tbl files go. I think it would be a lot easier to make a program that takes a txt file and appends it to a correct place in the ships.tbl (for example), and simply increasing tbl limits for the actual FS2 code... i.e. (thinking in Java here)
Let me see if I'm with you on this - each modification mean't to be appended to a table file could be required to start with the line:
"Append_to: ships.tbl"
Or whatever, where the .tbl file specified is what that file is added to. Thus the original files can remain un-changed but when a mod is started the text files for tables are loaded with the game (at a small overhead on loading time depending on how many there are). Starting the game without a mod specified would not load any modifications in txt files...
Is that right? I like that idea...
-
Originally posted by Thunder
Let me see if I'm with you on this - each modification mean't to be appended to a table file could be required to start with the line:
"Append_to: ships.tbl"
Or whatever, where the .tbl file specified is what that file is added to. Thus the original files can remain un-changed but when a mod is started the text files for tables are loaded with the game (at a small overhead on loading time depending on how many there are). Starting the game without a mod specified would not load any modifications in txt files...
Is that right? I like that idea...
I don't think it would even be necessary to include that line, since all that is involved is having the program look for ASCII files that contain a $name token and copying all the following data.
That is a very good idea, Aldo, and would do a lot towards what penguin is describing without requiring that we rip out the entire table system and replace it. :yes:
There is no comprehensive archive, penguin. People have tried, but every attempt merely succeeds in creating another site with a few mods on it. HLP or the VolitionWatch Archives would be the logical places to have such a thing, but the VWArchives don't contain very many, and HLP, ironically, hasn't updated its Mods page in ages....
-
I think using VP files for MODs would be better then using zip files. Aside from preformance issues (and I've seen how long zip files can take to add a ton of small files to an archive) there is the fact that code for reading VPs is already built in. Zip code would have to be integrated from some 3rd party code, and you'd still have to keep the VP code in order to read the original VPs. (Unless you want every user to go and extract every file from every VP and put them into zip files.) One thing I think would be a good idea is to make a mod table file that contains all the table modifications for a particular mod. It could contain ship table data, message table data, music table data, etc. You'd just have to give it a standard name and make sections within it for each type of data. For example:
# Mod.tbl
# start SHIPS
# end SHIPS
# start MUSIC
# end MUSIC
This way the MOD author only has to edit and keep track of 1 table file. The entries probably should be checked against existing entries in the :v: table files to tell if it should replace an entry or add it. (If the name of a custom ship matches the name of a :v: ship use the custom ship instead.)
I think the idea of every ship and weapon having their own table is a bit too much and could open a whole new can of bugs. (Like what happens if FS2 runs out of available file handles and can't finish opening all the ship/weapon files that it's supposed to? That was a problem with some DOS games as I recall. Every opened file uses system resources, and the amount of system resources available is much less then the amount of available memory.)
Another feature that would be nice in a mod manager would be managing multiple game saves. Example: You run FS2, go into the MOD manager and select the MOD who's campaign you want to play. It will backup your existing game save (presumably from the original campaign) and restore the save game that goes with that MOD. That would let people who are trying to go through one campaign check other campaigns out without having to have multiple copies of FS2 installed of just plain renaming their Data directories when switching MODs. When the mod is unloaded (at game exit or in the MOD manager) the current MOD's save game would be backed up and the original save game would be restored.
-
I am getting some really excellent feedback here from everyone... thanks!
Originally posted by EdrickV
I think using VP files for MODs would be better then using zip files. Aside from preformance issues (and I've seen how long zip files can take to add a ton of small files to an archive) there is the fact that code for reading VPs is already built in.
I think the "performance hit" of zipfiles is greatly exaggerated, at least on modern machines. You would probably see a similar slowdown trying to add lots of small files to a VP or any other "package"; try adding them to a zipfile with compression turned off, I'll bet you will see only slightly better performance, but not that much better. Zip code would have to be integrated from some 3rd party code, and you'd still have to keep the VP code in order to read the original VPs. (Unless you want every user to go and extract every file from every VP and put them into zip files.)
We would definitely leave the VP support there; the cfilearchive code would be smart enough to use either the VP code or ZIP code.
Anyhow, I'm not married to the idea. My big reason for asking was (1) smaller sized files for distribution (and on the player's hard drive), and (2) more readily available tools.
I think the idea of every ship and weapon having their own table is a bit too much and could open a whole new can of bugs. (Like what happens if FS2 runs out of available file handles and can't finish opening all the ship/weapon files that it's supposed to? That was a problem with some DOS games as I recall. Every opened file uses system resources, and the amount of system resources available is much less then the amount of available memory.)
You wouldn't run out of handles if they were all in one file, say, oh, a zipfile ;) Or a VP; in eny event, they are only one "file" from the operating system's point of view. And even if there were lots of files, if we read them sequentially (foeach file do { open file; read file; close file; } ) we shouldn't have problems. Good thing to point out though...
And IIRC, the ships.tbl and weapons.tbl are only parsed once, at the start of the game (before you see the "Player Select" screen. Not sure about the other files though.
-
Originally posted by penguin
And IIRC, the ships.tbl and weapons.tbl are only parsed once, at the start of the game (before you see the "Player Select" screen. Not sure about the other files though.
If you want an in game mod manager (maybe integrated into the campaign screen) you'd have to "refresh" the table files when changing mods. And for a zip file you'd have to extract the files to read them, so they're not just one file. (And zip files aren't made for random access either.)
As far as the preformance differences between compressed and uncompressed files I did a small test. I zipped files from my relatively clean FS2's data directory with and without max compression. The difference (for about 4 megs of files) was 3 seconds. For a modded data folder that was about 25 megs, the difference was about 13 seconds. Didn't take as long as I thought it would, but I guess I was thinking of some much bigger zip files. Oh, and this is on a 933 Mhz P3. I don't think that mod was one of the bigger ones either.
-
Well, we're going round and round in circles over a fairly trivial issue (VP vs. ZIP), but I did ask for feedback, so I'm getting what I deserve ;) Like I said, zip was a suggestion; we can do the same stuff w/ VP as well.
Anyhow:- You are right, of course -- the table files would need to be refreshed when changing mods. But this is still an "occasional" thing, it wouldn't need to happen every time a mission was started, for instance.
- I probably misspoke earlier... the real issue is in unpacking the files, and here you shouldn't see as big a difference in time (I think). Compression, especially "max compression" can add a significant amount of time to the pack operation, while unzipping is typically much speedier, depending on the algorithm. However, the compression would only need to be done once, by the person distributing the package.
- You still wouldn't need to "open each file" when going through the zip, at least not in the OS sense... you would open the zip file once, and read the contents of the "subfiles" directly out of the zip and into memory (not extracting to a new file on the disk).
- As far as random access goes, I don't know enough about the internal structure of a zip file to make a convincing argument one way or the other.
-
there is a reason why V didn't use compresion in the VP files in the first place, it would add time to the loading of files and that is the thing I'd like to see quickened the most,
the tables should stay the same as they are, I only think it would increase the load times, and make things more unnesisaraly complecated to have fifty thousand table files,
keeping things organised in a simple VP file with all the files for the mod is all that is needed, this way a mod would be only one file, this online network thing is just way too big and complicated to ever get done, and I think there are better things that we could be doing
you can have an in game mod loader added to the pilot selection screen to give presidence over to a single VP file to be read first, it will select the file that was selected the last time FS was run (like it does for pilots), and there will always be a "no mod" option near the top that makes it load like it does now
-
Originally posted by Thunder
Let me see if I'm with you on this - each modification mean't to be appended to a table file could be required to start with the line:
"Append_to: ships.tbl"
Or whatever, where the .tbl file specified is what that file is added to. Thus the original files can remain un-changed but when a mod is started the text files for tables are loaded with the game (at a small overhead on loading time depending on how many there are). Starting the game without a mod specified would not load any modifications in txt files...
Is that right? I like that idea...
I'm actually thinking of a seperate program to append / delete ship entries, rather than altering the Fs2 code...
i.e. "java tblShuffler ships.tbl hercMk3.txt a"*
(a denotes append)
would add the contents of hercMk3 to the ships.tbl in the specified species slot.
an 'r', or similar, would remove it (probably by searching for a set of tokens matching the start & entry of the entry).
You could probably add a C version of this to FS2's parser code...I'm not sure how that works, (as I said, my C is very limited and my c++ worse) - I'm thinking of a standalone program at present
*(simple command line thing... stuff like a proper GUI and more robust error checking would be for later)
The idea of this is that it's independent of the code changes, providing tbl's are being used....
I've been toying with the idea of coding a few things in Java (I mainly study Java at Uni, so I'm reasonably able to do this sort of stuff), like tbl entry generators for ships, etc. the problem is that I've never compiled a java program intended to work as a standalone (need to check that). also I'm very busy, and still recovering from the utter nightmare of me airline-graph-coding-project-thing for uni last semester.
BTw, I'd imagine the parser methods are only called once upon startup / creation of a new player.... for simple reasons of avoiding unnecssarry recalculation.... I'v enot looked yet.
-
i have to side with the alternative directory structure at this point
[ie each mod has it's own data dir]
-
I'm in 100% agreement with Kazan. Alternate directory structures are neater, easier to manage etc. and also 'hide' (as far as FS2 is concerned) your mod's files frome everyone else's. That, and alternate directory structures are the style of management used in Half-Life (with great success) and also are friendly with on the fly downloads from the net. Given this, and the fact someone has already done something that can be copied I'd say the laternate directory structure is the big winner.
-
Alternative directory is sounding good to me...just have a .txt file listing the mods, or have a general-info file be in each campaign's data directory.
The way to do this might be to have Freespace compile a list of mods in the FS directory, including VP files. ALL mods should have some prefix and then a name for easier detection (ie MOD-Babylon directory or MOD-Babylon.VP) and if possible all the default FS2 content in its own VP file (Freespace2.VP :D)
Then, at the pilot select screen, you would select which mod to run Freespace with. This would be located just below the pilots select. The mod's info would then be loaded, with required files that don't exist within the mod being loaded from the default FS info (like the current system).
I'm pretty certain this will require the Freespace 2 loading code shuffled around, but it should speed up the loading of the pilots screen.
And I'll revise the above statement, content should be split into two files-one for the pilots screen, and one for the rest of the FS2 code. That way, the pilots/mod select screen is loaded, FS2 waits for the player to pick a mod, then loads and parses the files appropriate to that mod :nod:
Fire away ;)