[karajorma]

You're right, if you need to force a flag then you are probably doing something wrong.  That being said, our main intention with forcing flags on is for TBP and WCS total conversions and their flags '-tbp', and '-wcsaga', respectively. Same idea for forcing flags off, not that I can think of anything off of the top of my head that would need it.

Yeah, but that's kinda my problem with it. I don't really think the SCP should carry on supporting those flags to that level. You shouldn't really be using 3.6.11 with TBP unless you have Zathras installed. Similarly the next WCS version isn't out yet so anything in the -wcs flag should be moved to the tables.

Which basically makes supporting those two flags in the launcher rather redundant.

[Stormkeeper]

I think that a global launcher would be awesome. But making it provide support across the board might be a tad more difficult. The current stock versions TBP and WCS probably aren't compatible with the current SCP build.

[kkmic]

You're right, if you need to force a flag then you are probably doing something wrong.  That being said, our main intention with forcing flags on is for TBP and WCS total conversions and their flags '-tbp', and '-wcsaga', respectively. Same idea for forcing flags off, not that I can think of anything off of the top of my head that would need it.

Yeah, but that's kinda my problem with it. I don't really think the SCP should carry on supporting those flags to that level. You shouldn't really be using 3.6.11 with TBP unless you have Zathras installed. Similarly the next WCS version isn't out yet so anything in the -wcs flag should be moved to the tables.

Which basically makes supporting those two flags in the launcher rather redundant.

So the SCP Team plans to make these flags redundant. Moving them to the tables is a nice idea. Any ETA on when this will happen?

I'm asking this because I want to know if we should discard the idea of being able to force flags.

[portej05]

Thought I might jump in at this point.
I've just read the thread

I like the concepts being shown, but is this the best model for user interaction?

In terms of the way the application is launched at the moment, there's probably need for some review.
In terms of managing TCs, can someone please tell me exactly why they need to be kept in a separate directory - I'm very rusty on how that works.

We do need to start versioning stuff properly (Zacams nightly numbering bit is a good start, but is not a complete solution) - yes, it's difficult and sometimes time consuming, but it's also an important facet of managing something as diverse as FSO.

[kkmic]

In terms of the way the application is launched at the moment, there's probably need for some review.
In terms of managing TCs, can someone please tell me exactly why they need to be kept in a separate directory - I'm very rusty on how that works.

Probably because it's called a Total Conversion.

Just kidding, you have a good point there.  There are some things that I would like to see changed in FSO, but this is not the correct thread.

I like the concepts being shown, but is this the best model for user interaction?

Can you be a bit more specific on the last part of the quote above? What would you like to see changed?

[portej05]

Can you be a bit more specific on the last part of the quote above? What would you like to see changed?

Have we looked at how other games handle this (benchmarked against our own needs, of course)?
What about users who just want to double click and go? (I mean anyone who can't handle the OpenAL installer is unlikely to want to be presented with a faceful of game information)

[Spicious]

It shouldn't be too hard to avoid the multiple directories thing if FS2 were to be shifted into being a mod itself. This of course sounds like a massive support headache.

[kkmic]

Can you be a bit more specific on the last part of the quote above? What would you like to see changed?

Have we looked at how other games handle this (benchmarked against our own needs, of course)?
What about users who just want to double click and go? (I mean anyone who can't handle the OpenAL installer is unlikely to want to be presented with a faceful of game information)

Other games are not what FSO is.
Even for other games, if you have MODs, you need at least to select them from inside the game, make a customized shortcut, etc.

We kinda have this here, into one launcher. Profiles allow you to start the launcher, select your profile (if not already selected) and click play. That would be 5 clicks

Of course, you need to take the time to set the profile before being able to do that. Fortunately, you should do it only once for each MOD/TC. Even more, you can clone one profile to another, so that not every profile needs to be configured from scratch.

[karajorma]

It shouldn't be too hard to avoid the multiple directories thing if FS2 were to be shifted into being a mod itself. This of course sounds like a massive support headache.

If I had a pound for every time I wished we'd been able to do that.....

But yes, telling people that they'd have to move their existing FS2 folder in order to install FS2_Open is just asking for trouble.

[The E]

In terms of managing TCs, can someone please tell me exactly why they need to be kept in a separate directory - I'm very rusty on how that works.

If it is in fact a proper total conversion, it should work without a hitch. But always remember that <FS2 directory>\data and all the vps in the FS2 dir get read regardless, which means that certain data (like, say, the FS2 campaign, or FS2 multiplayer missions) which is not overridden by the TC files will show up in-game and cause support issues.

[Spicious]

I guess an alternative could be a flag to ignore the base directory structure and vps, instead only loading the mods specified. I have no idea how practical this would be though.

[Zacam]

Not very. If it ignores the base directory without direction, that could be bad. Imagine loading the MediaVPs without FS2. Ouch.

BUT, that doesn't mean that a setting or "TC" flag couldn't be set to define that behaviour. So, instead of a -tbp or -wcsaga flag, we just have a -TC flag (similar to -standalone) that does do that behaviour.

[Iss Mneur]

Not very. If it ignores the base directory without direction, that could be bad. Imagine loading the MediaVPs without FS2. Ouch.

BUT, that doesn't mean that a setting or "TC" flag couldn't be set to define that behaviour. So, instead of a -tbp or -wcsaga flag, we just have a -TC flag (similar to -standalone) that does do that behaviour.

How would this new flag work?  Force the engine to ignore the base dirs (data, vp)?  The problem is this doesn't really solve the problem that started this entire thread of discussion, forcing flags, instead of -tbp or -wcsaga flags the mod would have to force the -TC flag.

It shouldn't be too hard to avoid the multiple directories thing if FS2 were to be shifted into being a mod itself. This of course sounds like a massive support headache.

If I had a pound for every time I wished we'd been able to do that.....

But yes, telling people that they'd have to move their existing FS2 folder in order to install FS2_Open is just asking for trouble.

Agreed.

If we were to move the default fs2 data out of the engines main directory (or force the engine to ignore the main directory unless told to use it (which is what I think Zacam is getting at)), we would still have to have the engine start with certain flags so that it could find the game data to run.  Unfortunately, the game engine is not omniscience, it cannot read the users mind as to which mod the user wants to load.  Even the king of moddable engines (doom and half life) require the user to tell the engine were to find the game data.  Doom and half life do this in engine, or with flags as kkmic stated earlier ( done as special shortcuts normally, you would be surprised at what is in the target box of some games short cuts).

Admittedly, the game engine could just start rooting around in it's game folder until it finds something, but this would require the TCs are installed in there own completely separate folders, which is not necessarily a problem, but seems to be different than how everything has worked in the past for this engine.  Because it is so different from how it works now, I am sure that The_E would love us.

Can you be a bit more specific on the last part of the quote above? What would you like to see changed?

Have we looked at how other games handle this (benchmarked against our own needs, of course)?
What about users who just want to double click and go? (I mean anyone who can't handle the OpenAL installer is unlikely to want to be presented with a faceful of game information)

So far nothing that this launcher is asking of the user is any different than what the current launcher for windows is asking of the user, they just in a different place.  The only differences are the installer/updater and the profiles, both of which are requested features and something that a user can just ignore.  As noted by kkmic in the original post, there will be a default profile and the launcher will by default save any changes there, so this launcher will not need to be used any differently than the current one.

As for users that want to double click and go, the launcher is going to have sensible defaults, and if we can get it to work, the launcher choose sensible default flags for the user (like resolution, graphics and memory options).  Because we are intending this launcher to be pointed to an existing freespace installation it will also support reading the current launcher's .ini. At that if the user wants to play the same mod that they played last time, they just start the launcher and click play, which is exactly the same as the current launcher.  This is also why I mentioned in my last reply that the network stuff will be done after the launcher is ready to go so that this launcher even though it can do more things, will not be any slower than the current launcher is at load.

[Spicious]

BUT, that doesn't mean that a setting or "TC" flag couldn't be set to define that behaviour. So, instead of a -tbp or -wcsaga flag, we just have a -TC flag (similar to -standalone) that does do that behaviour.

That's what I was suggesting (or at least trying to suggest): a flag that you use when playing a TC so it skips the FS2 data. More likely the launcher would use it for you and you would never actually touch it manually.

[chief1983]

You shouldn't need that.  At least on windows your TCs are going to be in a completely different folder, and probably have their own executables with them.  So even if you use one launcher for every FS game you have installed, you probably won't need something like that.

[Spicious]

The point was to remove the need for different folders for each TC.

[The E]

Which is nice in theory, but a really bad idea in terms of support, for the reasons I outlined above.

[Spicious]

So it's a really bad idea to add a flag to skip loading files from the executable root directory so that TCs could be installed to the same place because the executable root directory is used for loading files?

Just so we're all clear.

[The E]

It's a bad idea to introduce a flag that alters the loading behaviour which can be turned on by the user. Just wait until the first person comes along complaining that his FS2 doesn't work, even though he installed the mediavps and turned on the TC flag manually.
It's a bad idea to contradict installation guides that have been around for years.

I'd rather have a Launcher capable of dealing with separately installed TCs than something that is bound to cause confusion among the users.

[Spicious]

A new unified launcher platform seems to me like the perfect opportunity to move onto a somewhat less incoherent system for dealing with TCs.

If someone turns on the tc flag without reading the description they deserve what they get. If someone turns on the tc flag after reading the description telling them not to touch it manually they deserve what they get. If it's in a category not in someway indicated as a bad idea to fiddle with then the developers have done something wrong.