[The E]

A unified Launcher, "One Launcher to rule them all", as it were, would be my preferred solution. That is, the Launcher is installed separately from each TC, but can be used to launch (and install!) every TC or campaign that provides the necessary information. Skinning being dependant on mod.ini settings.

[chief1983]

There are some definite issues with some of these ideas unique to OS X/Linux.  Havner would be a good one to comment on some of them, or Soulstorm.

[Goober5000]

However, I would suggest that it *doesn't* expect to deal with all TCs, but instead the same executable should be 'skinnable' to meet the needs of each TC.
- So a TC distributes the same Launcher app, but with a different skin and config file suited to their particular needs.

Thus TCs have the option to have associated 'mods', handled in the same way as FS2O handles mods to FS2.

This removes the problem of 'Where do you put the Launcher?' and the issues of having the Launcher find the appropriate executables, because it simply lives in the same folder as the associated TC or FreeSpace2Open itself.

It also prevents future updates to the Launcher from possibly breaking older 'no longer supported' TCs, as they will simply keep their old one.

Yeah, this is what I was thinking.  It also is another reason to separate the launcher and installer behaviors.

[Tolwyn]

What about blocking command line options unwanted by mod developers? Like tbp or 3d radar flags for WCS.

[chief1983]

Many of those options should be handled differently, i.e. an in game options menu, and some options should have the possibility of being locked by the mod.  Of course, this could all be based on the same system, as the in game options will mostly be stuff already definable through the command line anyway.

[karajorma]

@Tomo : If we design things correctly the launcher shouldn't ever break TCs that worked with an earlier version of it in the first place.

Hell I don't remember the last time the current launcher broke anything and that had far less planning.

[Gregster2k]

Hope I am not preaching to the choir - I am thinking these levels of settings are good.

3. User's user-defined settings for a particular mod.  These override all settings below, whether it be flags or things like screen resolution.
Located in the mod directory, is not used until user starts setting overrides for settings on a per-mod basis.

2. Mod's default settings for flags and such, included with the mod to allow the author to provide suggested settings for things such as ambient factor.  Also includes information about the mod such as what content to use.  Equivalent to today's mod.ini.  Again, located in the mod directory.

1. User's user defined settings for the engine itself.  These are the defaults which the engine falls back on in the absence of the above two settings.  These are located where the builds are located.  Most settings are located here, except for those which are mod-specific such as the TBP warp effects.

0. Hardcoded default settings per build (as if you ran without any flags at all).

Note that 3 overrides 2, 2 overrides 1, etc, although I do not believe that #2 should be capable of setting things which can adversely affect system performance.  Video settings are the purview of #1 - the user's global settings.  In other words, we should limit what mods are capable of setting, so that we do not wind up with people having to edit their mod's files to get it to run well on their systems.

Maybe we could also have settings which more adversely affect performance be grouped together for ease of access.

[Tomo]

Yeah, this is what I was thinking.  It also is another reason to separate the launcher and installer behaviors.

Not quite seeing how it makes it necessary to separate launcher and installer-updater.

Simply adding a button "Check for updates" to the launcher means that a user can always quickly check for updates to all their installed mods, executables and settings.
It could also suggest new mods and campaigns that have been released/updated since the last update check.

This is far more likely to get used than if a user has to download a separate 'updater' application.
The installer itself is basically irrelevant, but having a native app will always be both faster and easier to use - no need to install additional framework, like the current Java-based Turey's Installer.

Each 'user copy' of the Launcher would be attached to a different TC, and thus would automatically be looking in a different location for relevant updates and new mods.

The actual Launcher executable itself would be identical for all.
- If we're very careful, we could allow the Launcher to update itself from a single location, but that requires extreme care with the original design.

[Nuke]

Hope I am not preaching to the choir - I am thinking these levels of settings are good.

3. User's user-defined settings for a particular mod.  These override all settings below, whether it be flags or things like screen resolution.
Located in the mod directory, is not used until user starts setting overrides for settings on a per-mod basis.

2. Mod's default settings for flags and such, included with the mod to allow the author to provide suggested settings for things such as ambient factor.  Also includes information about the mod such as what content to use.  Equivalent to today's mod.ini.  Again, located in the mod directory.

1. User's user defined settings for the engine itself.  These are the defaults which the engine falls back on in the absence of the above two settings.  These are located where the builds are located.  Most settings are located here, except for those which are mod-specific such as the TBP warp effects.

0. Hardcoded default settings per build (as if you ran without any flags at all).

Note that 3 overrides 2, 2 overrides 1, etc, although I do not believe that #2 should be capable of setting things which can adversely affect system performance.  Video settings are the purview of #1 - the user's global settings.  In other words, we should limit what mods are capable of setting, so that we do not wind up with people having to edit their mod's files to get it to run well on their systems.

Maybe we could also have settings which more adversely affect performance be grouped together for ease of access.

 
i like this idea. there is no reason to change some settings such as joysticks and video resolution for every mod you download. so configuring a new mod to play should take little or no time at all. per mod settings means i can keep settings for mods in development. the only thing id change is ad a new alterantive to level 3 for debug mode (running the game with a debug build) settings.