[penguin]

Since I'm stuck w/ the OpenGL implementation right now , 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...)

[WMCoolmon]

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

[LtNarol]

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.

[WMCoolmon]

Sorry, I wasn't clear on that .
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.

[LtNarol]

ah, i see...thanks for clarifying

[Fineus]

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

[penguin]

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*

[Fineus]

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.

[ShadowWolf_IH]

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.

[Inquisitor]

Actually, Mysterial has access as well.

WM and DTP will have access tonight

p.s. if I can remember how.

[Fineus]

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

[penguin]

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

[WMCoolmon]

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

[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

[penguin]

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

Code: [Select]

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

[Sesquipedalian]

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

[penguin]

1.5' : 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 )

Food for thought, though; thanks for the feedback.

[Inquisitor]

So, theoretically, what would the pseudo code for a "package manager" zip or otherwise look like?

Lets design it here

[WMCoolmon]

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-

Code: [Select]

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:

Code: [Select]

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?:

Code: [Select]

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.

[penguin]

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