[Iss Mneur]

What are the equivalent locations under Linux and OS X?
I presume there must be something like this.

On linux, it would be a "dot" folder in users home directory (classicly this would be /home/<username>/.FSSCP/) which is no different that Microsoft's suggested file location (\Users\<username>\Application Settings\FSSCP\).  I would pefer to not use the registry, if only because that way there is only one code path for all OSs (a folder in the users OS profile).  OS X being a unix based system is /Users/<shortusername>, so we would put the files in /Users/<username>/.FSSCP/, though I will have to check Apples usablilty manual for their suggested location, but that should be good enough.

So for these, the 'manufacturer' should be "FSSCP"
The 'application' should be the name of the Total Conversion.

This way, a Launcher can have it's own 'custom' settings stuff sat in /FSSCP/SuperLauncher5000 (or whatever), but store the settings actually used by FreeSpace2 in /FSSCP/FS2 and the settings used by (eg) Wing Commander Saga in /FSSCP/WCS

By scanning the tree from /FSSCP and finding 'TC.INI' files (or something similar), a launcher can both locate the correct executable (be that a 'known stable' build or simply a pointer to 'use latest SCP build') and the necessary files.

This would be the same even if we used a directory in the users profile.

It may make sense to change the FS2Open executable to look in /FSSCP/<something> for its config, which would tell it where to look for the correct VPs.

I'm thinking out loud here, but it might make a lot of sense to have the only *genuine* command-line flag (as in 'a flag on the actual command line') be a pointer to an INI file that contains all the real settings, including base folder and applicable MOD folder to find the right VPs.

Then you could not only have a Launcher to do configuration stuff, but you could have a set of shortcuts that launch the same executable directly, but for each TC.

Yes, it is a good idea, but at this point, this is about creating a launcher to work with the current and past builds of fs2open, without changing the engine.  The way that the engine works currently is perfectly adequate for what we have done with it.  As The_E has said, invalidating years of installation manuals and instructions is just asking for trouble.

Installing TCs into separate folders is an issue that I had not thought about, but this is why kkmic and I have brought this proposal up for discussion.  At this point,  is something that we should do, in particular because as a TC, they have to provide there own game data for the entire engine which will should override everything that FS2 has for data anyway.

Skinning is pretty easy. Simply have the launcher take the skin details from the .ini of the last game played on the launcher.

[snip]

People keep acting like the idea of having "One launcher to rule them all" automatically precludes TCs from having a launcher that lives in the same folder as the TC and only being able to see that TC. That's simply not true. Acceptance of the global launcher could easily be an opt-in system with everyone else using the launcher as a local launcher/installer.

Or having a single launcher that is installed in a central location getting all of the update information it needs from the TCs mod.ini.  Like the url of the mods (package) list.

Just to be clear, there is no intention of this launcher/installer, just like the current auto installer becoming the primary source the different TCs data.  With this launcher and its installer we are not trying to take a TCs independence, the current system seems to have worked well enough for 10 years, there is no reason to change it now.  I personally envision the installer/updater being similar to how the package managers work for the various linux distributions in that they download a list of possible packages to install from a variety of sources (i.e. a list of mods for each TC from each TC's website).  This list of packages includes the download location and the instructions to install the downloads.

As I mentioned before the planned format will be basically the same as the how the current packages are distributed (but will be automated), and as I noted earlier the mods that use windows installer could be supported if the installer is well behaved and allows the use of flags or switches to control where and how it installs.  But at that, the linux users will still need some kind of archive that does not rely on executable downloads.

[Iss Mneur]

So long as you don't create a folder in My Documents, anywhere is fine by me.

Aggreed except for maybe screen shots Its a launcher I know.

And from an end-user organizational standpoint, I agree about keeping TCs separate from the main FS2 directory.  For one, there are obviously people playing certain TCs who don't have FS2 installed, so having to submit to some naming/organizational convention based on it is grounds for all sorts of confusion.  For another, and maybe even more significantly, it'd be somewhat of an organizational mess even for people who do own FS2 and know what they're doing.  A popular TC will presumably develop (or has developed, in the case of TBP) its own independent modding scene.  So you'd essentially have to have each TC installed to the main FS2 folder, and then any mods (and their own dependencies) installed in the TC folder within the main FS2 folder.  It seems far less headache-inducing to me to keep everything separated out.

Absolutely, if a TC has to use the FS2 folder they are not really a TC.

[castor]

So.. lets say we have installed:
c:\games\FS2

And would like to install:
c:\games\FSPort

We want to use MVPs with FSPort. Do they need to be copied to c:\games\FSPort also?
Or everything located in the "FS universe" needs to go under c:\games\FS2?

[Mongoose]

The FSPort is a mod for FS2, not a stand-alone total conversion, so you'd install it in your FS2 directory.

[Spicious]

I shall say no more on this but having multiple copies of the same engine floating around seems incoherent by definition to me.

While participation in an installer such as this may be optional, if it does become successful and many mods become easily available through it, there is likely to be an expectation of new mods using it.

[chief1983]

On the *nix systems, it's wherever user data is stored typically, ~/.fso_launcher or something.

[karajorma]

I shall say no more on this but having multiple copies of the same engine floating around seems incoherent by definition to me.

Unfortunately it is necessary. Otherwise we have situations where Diaspora launches with 3.6.11 and breaks the second 3.7 comes out and the launcher updates you to it. Each TC needs to store its executables in its own folder.

[chief1983]

So far that doesn't seem to be a problem for Windows and OS X, but I haven't run FS on Linux yet to have any say there.

[portej05]

I shall say no more on this but having multiple copies of the same engine floating around seems incoherent by definition to me.

Unfortunately it is necessary. Otherwise we have situations where Diaspora launches with 3.6.11 and breaks the second 3.7 comes out and the launcher updates you to it. Each TC needs to store its executables in its own folder.

I thought backwards compatibility was a major goal of FSO.
Is that still the case?

[Spicious]

Mods could specify maximum and minimum versions and the launcher could use say the latest supported executable. This could have entertaining (for me, not anyone trying to help people) problems if one mod and another mod it depends on specify disjoint sets of compatible versions however.

[kkmic]

That could be a quick fix. However, I won't have the launcher enforce a certain FSO version.
While a mod designer can specify the FSO version with which the MOD works, ATM I would like to keep these specifications as a note to the user.
You must download the proper version from the launcher itself, however, you will have to do this by hand.

Various customized binary versions will be kept in the repository, so they will be quick to get.

[karajorma]

I thought backwards compatibility was a major goal of FSO.
Is that still the case?

Backwards compatibility with retail, yes. Backwards compatibility with previous versions of FSO, not so much. I can think of a few occasions when we've deliberately broken compatibility there.

[Tolwyn]

BTW, for those against a unified launcher. There really isn't much of a reason we couldn't make a launcher that could be used both as a replacement for the current launcher (i.e every TC can have one) or as a unified one. All you'd need to do is change the URL that the launcher uses to get data from.

People keep acting like the idea of having "One launcher to rule them all" automatically precludes TCs from having a launcher that lives in the same folder as the TC and only being able to see that TC. That's simply not true. Acceptance of the global launcher could easily be an opt-in system with everyone else using the launcher as a local launcher/installer.

My main concern is a different one: say I setup my TC for best gameplay experience. A new user starts the launcher, sees all those nifty features (3d radar, additional pair of scanning likes just to name a few) and makes them active. Which is perfectly logical in modern games - the more features you enable, the better gameplay experience you will get. Now in a case of a TC it can either alter the gameplay or break it completely. So, no, I am not against a unified launcher, but I'd like to excercise some amount of control over available options. Some flags are downright misleading (like the mipmaps flag).

[Tomo]

What are the equivalent locations under Linux and OS X?
I presume there must be something like this.

On linux, it would be a "dot" folder in users home directory (classicly this would be /home/<username>/.FSSCP/) which is no different that Microsoft's suggested file location (\Users\<username>\Application Settings\FSSCP\).  I would pefer to not use the registry, if only because that way there is only one code path for all OSs (a folder in the users OS profile).  OS X being a unix based system is /Users/<shortusername>, so we would put the files in /Users/<username>/.FSSCP/, though I will have to check Apples usablilty manual for their suggested location, but that should be good enough.

Sounds good.
The key issue with "One launcher to rule them all" is ensuring that the Launcher can find the TCs, and that the TCs can find the Launcher.

By putting a small amount of config files in a 'known location', the problem is solved.
- When a TC is installed, it can check for an existing Launcher, and when the Launcher is run it can check for all installed TCs to provide useful options.

I agree that it shouldn't go in the Registry.
Having everything go in $APPDATA$/<blah> is much easier to localise for the different platforms.
On top of that, $APPDATA$ can contain more than just INI files, while the Registry is really limited to simple text and integers. (It doesn't do floats very well, and the binary support is painful.)

As for specifying available flags etc:
This is difficult, because you're either looking at "Exclude" or "Include" lists for each mod or TC.
Once a mod or TC is no longer actively supported, those lists become out of date as new features are added.

The simplest way of solving that is to assume the following:
- Mods *do not* limit flags, but *may* have recommended flags.
- TCs *always* specify both their executable and their permitted flags.

[The E]

The key issue with "One launcher to rule them all" is ensuring that the Launcher can find the TCs, and that the TCs can find the Launcher.

Just ask the user where everything is on the first start.

[karajorma]

My main concern is a different one: say I setup my TC for best gameplay experience. A new user starts the launcher, sees all those nifty features (3d radar, additional pair of scanning likes just to name a few) and makes them active. Which is perfectly logical in modern games - the more features you enable, the better gameplay experience you will get. Now in a case of a TC it can either alter the gameplay or break it completely. So, no, I am not against a unified launcher, but I'd like to excercise some amount of control over available options. Some flags are downright misleading (like the mipmaps flag).

That's kinda what I meant about flags being present that really shouldn't be. The -wcs and -tbp flags aren't the only two that should be moved to table values.

The things these all set up are one of the big arguments in favour of a game_settings.tbl (rather than further abusing ai_profiles as we have done in the past).

[Iss Mneur]

The key issue with "One launcher to rule them all" is ensuring that the Launcher can find the TCs, and that the TCs can find the Launcher.

Just ask the user where everything is on the first start.

Yep, the launcher can certainly ask the user were the TCs are located, the launcher can even scan some well known locations for FreeSpace and its TCs (like gog.com's default location, the default location that WCS's installer uses, etc.).  Though I am not sure why the TCs need to find the launcher, because the Launcher pushes to the TCs, though depending on install location the launcher may not be able to write the configuration files in some specific cases. For example, C:\Program Files\, as noted above.

My main concern is a different one: say I setup my TC for best gameplay experience. A new user starts the launcher, sees all those nifty features (3d radar, additional pair of scanning likes just to name a few) and makes them active. Which is perfectly logical in modern games - the more features you enable, the better gameplay experience you will get. Now in a case of a TC it can either alter the gameplay or break it completely. So, no, I am not against a unified launcher, but I'd like to excercise some amount of control over available options. Some flags are downright misleading (like the mipmaps flag).

That's kinda what I meant about flags being present that really shouldn't be. The -wcs and -tbp flags aren't the only two that should be moved to table values.

The things these all set up are one of the big arguments in favour of a game_settings.tbl (rather than further abusing ai_profiles as we have done in the past).

How much effort do you think be involved in getting this to happen in the engine?  What flags would you include?  I would assume that anything that is related to game play would be included, but things like the -mod flag, screen resolution, graphics performance options like -normal would be something that should be set per machine, not mod.

Towlyen, this is why in the OP, kkmic and I talk about forcing or disabling flags, recommending flags.  Of course, there is no conceivable reason why any flag cannot be force or disabled, though in looking at the list of flags, some are counter-intuitive, not helpful, or even gameplay damaging.

Mods could specify maximum and minimum versions and the launcher could use say the latest supported executable. This could have entertaining (for me, not anyone trying to help people) problems if one mod and another mod it depends on specify disjoint sets of compatible versions however.

There is no reason that we cannot have multiple versions of exes side by side for playing certain mods, TCs mainly though, especially when TCs should have separate base folders anyway.  Though mods could have the same thing, say there is a TC that only works with 3.6.9, but someone issues a patch mod that allows this TC to work with the 3.6.10 engine.

[Tolwyn]

How much effort do you think be involved in getting this to happen in the engine?  What flags would you include?  I would assume that anything that is related to game play would be included, but things like the -mod flag, screen resolution, graphics performance options like -normal would be something that should be set per machine, not mod.

Towlyen, this is why in the OP, kkmic and I talk about forcing or disabling flags, recommending flags.  Of course, there is no conceivable reason why any flag cannot be force or disabled, though in looking at the list of flags, some are counter-intuitive, not helpful, or even gameplay damaging.

Last time I checked, mipmapping flag was in the "graphics" category. Plus we have a lot of flags in the gameplay/HUD/... categories that aren't exactly helpful. Not for a TC, that is. One can't rely on the user to distinguish between different flags - it's against every rule of usability.

A blacklist, on a TC basis, would be a nice have.

[kkmic]

The mod.ini file will provide the option to disable some flags from the launcher. But as I said before, that won't stop a determined user to actually use them.

For the moment, you are the only one that requested this (at least AFAIK)

One can't rely on the user to distinguish between different flags - it's against every rule of usability.

True. That's why we planned the force on, force off, and recommended flags. However, that means that MOD and TC authors should use their head when using the first two categories. And use it A LOT.

While we can't rely on a user to have a deep understanding of different game flags, I would hate to start having the same opinion about authors.

Having the launcher blamed because some author forced the wrong flags and the game does not work properly is not something I look forward to.

[Tolwyn]

For the moment, you are the only one that requested this (at least AFAIK)

That would be because I already had some trouble with the launcher in the past.

Having the launcher blamed because some author forced the wrong flags and the game does not work properly is not something I look forward to.

And I'd hate to try to track a bug that is actually caused by an accidentally enabled launcher flag.