[The E]

How is "TCs should be installed separate from FS2" incoherent?

[Spicious]

I'm not sure what I can say other than merely the definition of incoherent. I'd expect different game data using the exact same engine to not be required to be split up, especially if it's only that way for "won't someone think of the users!" reasoning.

[The E]

Okay then. Think about this: TBP was declared final. The recommended (that is, official) build for TBP is 3.6.9 Inferno. For obvious reasons, that build does not have that TC flag. As a result, you can't put TBP data files into a mod directory in your FS2 folder without seeing the issues I described above.

Now, what could work would be a directory structure like this:

Code: [Select]

SCP dir -- Launcher resides here
     |---> FS2 -> All FS2 data, mods and executables go here
     |---> TBP -> All TBP data, mods and executables go here
     |---> Diaspora
     ...


[Spicious]

Declaring something absolutely final seems like a fairly terrible idea. Final in this sense seems more akin to abandoned. If someone insists on using an obsolete build maybe they should continue using their current launcher too. The whole point of something new and exciting like this is to not be entirely caught in the demands of the past.

Actually, a simple flag like this could probably be backported into 3.6.9 anyway. Again, all under the assumption that this flag would be feasible to implement.

[portej05]

What does TBP use that requires the Inferno build (especially that we're now considering Inferno builds as standard).
Also, what features does the -tbp flag provide that are not standard.

Are the TBP repositories/etc available so that they can be updated at all? (and properly versioned.)

[The E]

Declaring something absolutely final seems like a fairly terrible idea. Final in this sense seems more akin to abandoned. If someone insists on using an obsolete build maybe they should continue using their current launcher too. The whole point of something new and exciting like this is to not be entirely caught in the demands of the past.

Actually, I agree, but that doesn't change the fact that the TBP team did just that.

What does TBP use that requires the Inferno build (especially that we're now considering Inferno builds as standard).
Also, what features does the -tbp flag provide that are not standard.

Are the TBP repositories/etc available so that they can be updated at all? (and properly versioned.)

TBP needs the enhanced ship limits and reduced error checking of 3.6.9 to work properly. (Zathras is a different case, but since that is a mod....)

[Tolwyn]

Honestly, I do not like the idea of using unified launcher for Freespace 2 mods and TC at the same time. As far as I am concerned, TCs may use the FS2 engine, but they are separate games, built to be played stand alone. Not to mention that Total conversions usually tend to use different distribution methods. Saga, for example, uses the Windows Installer for windows builds.

[chief1983]

TCs have been and should be installed separate from FS2.  It allows them to eliminate possible sources of error.  If you don't have any requirement of using FS2 data, you shouldn't have to install alongside it.  That can create a bigger tech support headache for a TC.

[chief1983]

Although, Tolwyn, on OS X/Linux they would definitely benefit from having a shared launcher since it's more likely their launcher stores its config data in the same place no matter where the launcher executable is stored.  Multiple launchers would then just be redundant as they would all be working with the same config.

[Tolwyn]

It depends on the launcher/EXE. Tinman, for example, modified 3.6.10 binaries to store WCS data in a different folder, me thinks.

There's also a question of skinning the launcher - it's be very cool if a TC could give the launcher a slightly different look.

[chief1983]

So you'd either have to have a slightly different version of the launcher for every TC, or use a unified launcher.  I vote unified in that case.  Too much of a pain to maintain otherwise.

[karajorma]

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

Honestly, I do not like the idea of using unified launcher for Freespace 2 mods and TC at the same time. As far as I am concerned, TCs may use the FS2 engine, but they are separate games, built to be played stand alone. Not to mention that Total conversions usually tend to use different distribution methods. Saga, for example, uses the Windows Installer for windows builds.

The idea is to make the Launcher somewhat like Steam (taking only the best things from that idea). i.e a single point for content distribution of multiple games. In many ways this solves the issue of having each TC needing its own installer (while still not preventing them from doing so) and also gives each game an easy way to advertise the existence of the others (and trust me, the number of fans who even find the TC's forum let alone stay there long enough to notice other TCs is a fairly small fraction of the whole.


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.

Let me give an example. Suppose we make a unified launcher. It lives in c:\games\FS2_Open. We tell it that FS2 lives in c:\games\Freespace2 and Diaspora lives in c:\games\diaspora.  Now WCS comes along and wants to have their own launcher. They install it and the game in c:\games\WCS. All they really need to do to only offer WCS mods, etc is simply tell the launcher to look for information on what is available on the WCS website rather than having it use the same global list that FS2 mods and Diaspora is using.

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.

[Iss Mneur]

Honestly, I do not like the idea of using unified launcher for Freespace 2 mods and TC at the same time. As far as I am concerned, TCs may use the FS2 engine, but they are separate games, built to be played stand alone.

It shouldn't be an issue to be honest.  The launcher itself can be branded, and contrary to kkmic's mockups the title bar will either be "<name of TC> Launcher" or "The Source Code Project Launcher" which is a bit different than how the current launcher brands itself.  At that, the launcher will not require that someone brand it.  This is also why we are looking for idea's, is there anything in particular that you would like to be able to skin or brand about the launcher?

As karajorma posted while I was writing this reply, the Launcher is to be like steam or other Content Distribution Systems.

Not to mention that Total conversions usually tend to use different distribution methods. Saga, for example, uses the Windows Installer for windows builds.

As for using the installer, as long as it is a proper installer that allows for flags to be used to make the installer do its thing silently and install to a particular directory the launcher should be able to use it in the launchers installer.

That being said, I was not aware of anyone actually using the windows installer for installing. Does anyone else use this method as well?

[The E]

TBP, at least the DVD version.

[chief1983]

Let me give an example. Suppose we make a unified launcher. It lives in c:\games\FS2_Open. We tell it that FS2 lives in c:\games\Freespace2 and Diaspora lives in c:\games\diaspora.  Now WCS comes along and wants to have their own launcher. They install it and the game in c:\games\WCS. All they really need to do to only offer WCS mods, etc is simply tell the launcher to look for information on what is available on the WCS website rather than having it use the same global list that FS2 mods and Diaspora is using.

But if you install more than one launcher, where does the launcher's own data live?  Config files in the same directory as the exe are a bad idea these days, and a really bad idea on *nix systems.  It should be in the user's home folder somewhere ideally.  So the exes would still be sharing some config data, and need to have a global awareness.

[portej05]

This does bring up the distribution and packaging issues again.

[Tomo]

So, the problem boils down to 'Where do we store these settings?"

Under Windows, these kind of settings should either live in HKEY_CURRENT_USER/SOFTWARE/<manufacturer>/<application> or in Documents and Settings\<username>\Local Settings\Application Data\<manufacturer>\<application>
- Microsoft would prefer us to use the Registry, but using Application Data is probably more easily localised to the other OSes.

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

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.

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.

[portej05]

* portej05 ducks

[The E]

No. No Registry. Please do not use the Registry. Registry is bad. %APPDATA% is a much better choice.

[Mongoose]

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

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.