[athropy]

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.

[KARMA]

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

[aldo_14]

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.

[Fineus]

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...

[Sesquipedalian]

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.

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....

[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. 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 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 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.

[penguin]

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.

[EdrickV]

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.

[penguin]

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.

[Bobboau]

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

[aldo_14]

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.

[Kazan]

i have to side with the alternative directory structure at this point
[ie each mod has it's own data dir]

[##UnknownPlayer##]

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.

[WMCoolmon]

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 )
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

Fire away