Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: kkmic on October 19, 2009, 03:02:27 pm
-
Although this project was started by Hellzed via a thread on this forum, since he is not answering to his PMs, Iss Mneur and I decided to continue this project on our own. Hellzed, if you're reading this, please contact one of us.
So far, we have only several mock-ups on how the launcher will look like, and a ton of ideas on how will it work.
Key additions to the current launcher design:
- Internationalization
- Profiles
- Greater control over a particular the mod by it's author (via the mod.ini file)
- Integrated install/update solution
Internationalization
The launcher will be available in multiple languages.
Profiles
- A profile basically contains the status of all the options available to the user (exe, mod, video, advanced options, etc). So, if you bothered saving one profile for a certain configuration, you can just select that profile from the list and voila, everything is set to what the particular mod you want to play needs.
When you create a new profile, the launcher should ask for it's (unique) name and the option to "clone" one of the existing profiles. That way, if you have a profile for, let's say Derelict, and want to create a new profile for Blue Planet, you can base the new profile on the existing Derelict profile and modify just the selected mod and one or two options if needed, save the profile and have a BP profile with just a few clicks.
- The launcher should ask you to save a profile if you made changes to it, when exiting and switching profiles (just as your ordinary text editor: "Do you want to save the changes to <profilename> before exiting?" Yes, No, Cancel).
- There should be one profile named "default" that is used to save the settings when using the launcher for just one mod/TC to avoid forcing you to name a profile on startup, when none is found in the configuration file. The "Always save default" check-box (intended to be named "Always save default profile" but left to "Always save default" due to not enough space on the mock-up) forces the launcher to save the default profile when exiting or switching profiles without asking - kinda replicating how the current launcher is working ATM.
Control over your own mod
Via the mod.ini, a mod author can skin the launcher window to some extent, force flags to be always on and disallow certain flags from being used. Also, a mod author can mark some flags as being recommended (but not mandatory). These flags will be marked by the launcher on the advanced settings page. The exact details are still being worked on
Install/Update integrated
With the help of a central content server, the launcher can keep track of news, new releases and available updates to your existing files. Updating will translate to downloading only the changed files, or a patch, if available. As for how all these things will happen, we're still working on it
Now, without further ado, these are the mock-ups so far:
Welcome page
(http://audiozone.ro/personal/fs2launcher/launcher_p1.jpg)
Mod selection page
(http://audiozone.ro/personal/fs2launcher/launcher_p2.jpg)
Basic settings page
(http://audiozone.ro/personal/fs2launcher/launcher_p3.jpg)
The basic settings page concatenates all the configuration tabs except the "features" one from the current launcher. It also adds the option for proxy servers.
*I KNOW* the binary selection mechanism is missing from this page, but it will be there on the actual launcher. :p
Advanced settings page
(http://audiozone.ro/personal/fs2launcher/launcher_p4.jpg)
Install/update page
(http://audiozone.ro/personal/fs2launcher/launcher_p5.jpg)
Under construction :)
Other things of interest that the launcher will contain:
- Option to remove a mod via right-clicking
- An on-screen indicator when updates are available
- A status bar (below the main window) for messages of minor importance to the user
- Ability to download updates in the background and keep playing the game at the same time
- The proverbial "more"
Anyone else interested in joining the project? We could use a graphic artist to create some images for the launcher.
And in case you missed the essence of this post.... we're looking for feedback from you. (what's good, what sucks, better ideas, etc)
-
Me likes :nod: :yes:
-
Are these the same as the ones Karajorma posted?
I mean, are you guys collaborating even though he's not mentioned :confused:
On-topic, how long til this is in the testing stage? :nod:
Because i volunteer :o
-
Are these the same as the ones Karajorma posted?
I mean, are you guys collaborating even though he's not mentioned :confused:
No, this is a separate project.
We're still not 100% done with the planning stage :), so there will be a while until the testing stage.
-
These images are really great, but I do think you guys should get in touch with karajorma before you go any further, because they look very similar to the concepts he discussed in the recent SCP meeting (http://www.hard-light.net/forums/index.php?topic=65891.0); he posted some mock-up images and went into further detail in this thread (http://www.hard-light.net/forums/index.php?topic=66064.0). We already have a few disparate Launcher efforts in the works, and now that the SCP team is talking seriously about implementing an all-encompassing cross-platform overhaul, I'd hate to see effort wasted on redundant projects. I'm sure they'd really appreciate your input and expertise. :)
-
I posted my thread not as a serious contender for what the launcher should look like, but in order to encourage discussion and ideas on what a global launcher would be like.
So this is merely more of the same. Once we've had a few people post mock-ups we can decide on which ideas are best. kkmic, you don't seem to mention whether this would be a global launcher for all projects or if it would require each TC to have their own launcher (or maybe it's just too early in the morning for me). Personally I'm in favour of the former.
-
In favor of the former too. But looks promising.
-
We already have a few disparate Launcher efforts in the works, and now that the SCP team is talking seriously about implementing an all-encompassing cross-platform overhaul, I'd hate to see effort wasted on redundant projects.
Well, to be fair, all new proposals, including karajorma's, are already redundant to the three or four launchers that are currently working and available. :p
-
Wasn't the whole idea to come up with one cross platform standalone launcher/updater/installer to do away with all the redundant work going on? Everyone putting effort into one launcher would seem to be the logical course. Not only does it prevent waste of time on duplicate efforts but reduces support load when you only have one program everyone is familiar with.
Maybe a Launcher sub forum is in order so everyone can get there ideas together and into one project.
-
We already have a few disparate Launcher efforts in the works, and now that the SCP team is talking seriously about implementing an all-encompassing cross-platform overhaul, I'd hate to see effort wasted on redundant projects.
Well, to be fair, all new proposals, including karajorma's, are already redundant to the three or four launchers that are currently working and available. :p
I know, but that situation is what you're trying to rectify, if I'm reading things right. :p
Everything else aside, I do really like the layout of this, particularly the profiles implementation. It's clear, it's compact, and it's sensibly constructed.
-
In the above mock-ups, the only thing I could recommend would be the Advanced Settings area. To the right of the flags, rather than advising people to double click on an option to view the wiki, why not just detail the information from the wiki in there?
Seems like there is more than enough room for it.
-
Yeah, now that you mention it. And having to connect to the internet to fully utilize the launcher doesn't make sense. Putting a brief description of the info would probably suffice.
-
Well, an internet connect for the install/update is nifty. And having the Hard Light headline announcements in there? Way freaking awesome sauce.
As long as net access is not a required function for it to operate (meaning that it won't swallow its own tongue if it doesn't have any) I think it provides a fairly nice capability.
-
Control over your own mod
Via the mod.ini, a mod author can skin the launcher window to some extent, force flags to be always on and disallow certain flags from being used. Also, a mod author can mark some flags as being recommended (but not mandatory). These flags will be marked by the launcher on the advanced settings page. The exact details are still being worked on.
To be honest, I am not actually sure we need this. In my mock up using settings from the mod.ini was merely a quick way of setting up the launcher based on the settings the game could use (i.e a new SCP user wouldn't need to know that Diaspora requires a powerful PC while JAD doesn't. They'd simply pick a set based on the power of their PC).
If you find you're having to force the use of flags in order to get the correct behaviour for your mod then that means you're doing things wrong/need to get the SCP to make that flag a table setting.
-
how would you handle installing a mod manually?
how are mods to be packaged?
-
Supporting disparate options in mod.inis seems like a terrible idea to me, at least when developers have some expectation of these options applying to all players.
In the above mock-ups, the only thing I could recommend would be the Advanced Settings area. To the right of the flags, rather than advising people to double click on an option to view the wiki, why not just detail the information from the wiki in there?
Seems like there is more than enough room for it.
I'd put the basic info in a tooltip and use the right pane for extended info that would be in the wiki.
- Ability to download updates in the background and keep playing the game at the same time
Updates to what?
how would you handle installing a mod manually?
how are mods to be packaged?
Those are how questions. This just seems to be about what it looks like and what it does.
-
Control over your own mod
Via the mod.ini, a mod author can skin the launcher window to some extent, force flags to be always on and disallow certain flags from being used. Also, a mod author can mark some flags as being recommended (but not mandatory). These flags will be marked by the launcher on the advanced settings page. The exact details are still being worked on.
To be honest, I am not actually sure we need this. In my mock up using settings from the mod.ini was merely a quick way of setting up the launcher based on the settings the game could use. If you find you're having to force the use of flags in order to get the correct behaviour for your mod then that means you're doing things wrong/need to get the SCP to make that flag a table setting.
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.
Well, an internet connect for the install/update is nifty. And having the Hard Light headline announcements in there? Way freaking awesome sauce.
As long as net access is not a required function for it to operate (meaning that it won't swallow its own tongue if it doesn't have any) I think it provides a fairly nice capability.
Yes net access is not required. We have not decided on how to handle the net at launcher start up, but my idea is to have the launcher load anything that is needs to display that it gets updated would be loaded from its local cache, this way the launcher's start up is not delayed. After the launcher start up is complete the launcher would then start checking online resources for updates in the background. That is, do not try the Internet until after the launcher is running. As noted in kkmic's post we have not decided exactly how the mod installer/updater is going to work, but we did decide that it was going to be a subtle system. Notification of an update would likely be a button to the left of the play button that only appears when unchecked updates are available.
As for the wiki, that could probably be bundled into the help system updates, as the updater would not just update the engine and mods/TCs but the launcher itself and the launchers content (namely the help).
As for the help system, kkmic has stated that "help should not be more than a click away." Which I think is nice, but we need some ideas as for what we are going to do for the help that is "a click away." The tool tips is a good idea, but what can't fit on a tool tip that should be included in the launcher.
I posted my thread not as a serious contender for what the launcher should look like, but in order to encourage discussion and ideas on what a global launcher would be like.
So this is merely more of the same. Once we've had a few people post mock-ups we can decide on which ideas are best. kkmic, you don't seem to mention whether this would be a global launcher for all projects or if it would require each TC to have their own launcher (or maybe it's just too early in the morning for me). Personally I'm in favour of the former.
Yes, it is supposed to be "The Freespace Launcher" to rule them all, so it does do TCs, even though that is not made really clear. Basically, replace in your mind every time kkmic writes "mod" with "mod/TC/campaign/mission/imagepack/whathaveyouthirdpartything" (yes, I am looking at you BP with that stupid star-field pack that I had a hard time letalone finding, and then even a harder time installing :mad:). Also the plan is to have the launcher installed in it own folder separate from FS.
Supporting disparate options in mod.inis seems like a terrible idea to me, at least when developers have some expectation of these options applying to all players.
I am not really sure what you are getting at with this.
In the above mock-ups, the only thing I could recommend would be the Advanced Settings area. To the right of the flags, rather than advising people to double click on an option to view the wiki, why not just detail the information from the wiki in there?
Seems like there is more than enough room for it.
I'd put the basic info in a tooltip and use the right pane for extended info that would be in the wiki.
That's a great idea. This is why we opened this to comments!
- Ability to download updates in the background and keep playing the game at the same time
Updates to what?
To everything. The launcher, the launcher's data (help, namely), all installed mods/TCs/etc., the engine executables themselves (official releases, RCs, optionally even "knightly" build), possibly even Fred. This is one thing we were not sure about, what else would be valuable to make sure it is up to date.
how would you handle installing a mod manually?
how are mods to be packaged?
Those are how questions. This just seems to be about what it looks like and what it does.
They may be how questions, but they are relevant considering that 20% of the interface is dedicated to installing and updating things.
At this point we are looking at having the launcher just scan the folder for the currently installed mods, and if it finds a valid .ini it will show it in the main mod list. The data about the mods and the possible skinning they can do to the launcher are entirely to be stored in the mod's folder.
As for mod packaging, I don't think they will need anything different than what they are currently. As for how the update system will operate, it will likely be a central repository for the necessary meta data and download information. We plan on the launcher being able be just pointed at an existing fs2open install and pickup as if it had done all of the installing itself.
At that, this is also why we are seeking suggestions as to what the update/install system, in particular, and the launcher in general will be.
-
Alright, the first Q&A session. On a "First Come, First Served" basis ;)
These images are really great, but I do think you guys should get in touch with karajorma before you go any further, because they look very similar to the concepts he discussed in the recent SCP meeting (http://www.hard-light.net/forums/index.php?topic=65891.0); he posted some mock-up images and went into further detail in this thread (http://www.hard-light.net/forums/index.php?topic=66064.0). We already have a few disparate Launcher efforts in the works, and now that the SCP team is talking seriously about implementing an all-encompassing cross-platform overhaul, I'd hate to see effort wasted on redundant projects. I'm sure they'd really appreciate your input and expertise. :)
I don't want to sound cocky, but this launcher was planned before the SCP meeting and before Krajorma posted his mock-ups (no, I am not flexing my muscles and no, I don't intend to transform this thread into a bloodbath between launchers). Some ideas are similar to what he posted there, some are not. The only thing that was lifted directly from Krajorma's thread was an idea based on this (everything else was designed independently):
What about blocking command line options unwanted by mod developers? Like tbp or 3d radar flags for WCS.
To be more precise, the ability to block some flags from the user in the launcher. Though, nothing stops you from editing the mod.ini and remove the block, or simply take the command line from the launcher, edit it and paste it into the first available console.
Anyway, I'm sure Krajorma, I and Iss Mneur we'll get along just fine. :yes:
kkmic, you don't seem to mention whether this would be a global launcher for all projects or if it would require each TC to have their own launcher (or maybe it's just too early in the morning for me). Personally I'm in favour of the former.
So am I. this launcher is intended to be able to control ALL your MODs and TCs. That's why the profiles were specifically created. So that you can switch between MODs/TCs (once the profiles are configured) with a few clicks.
But it is possible that we add an option into the configuration file of the launcher that will allow a TC (maybe even a MOD?) author to "lock" the launcher to his specific project. We'll think about this, if anyone REALLY needs it.
Well, to be fair, all new proposals, including karajorma's, are already redundant to the three or four launchers that are currently working and available. :p
There are indeed other launcher projects. How many of them are near completion and portable? And i doubt that any of them are even planned on a level comparable to what we proposed.
In the above mock-ups, the only thing I could recommend would be the Advanced Settings area. To the right of the flags, rather than advising people to double click on an option to view the wiki, why not just detail the information from the wiki in there?
Seems like there is more than enough room for it.
It seems that I failed to explain even to Iss Mneur how the advanced settings page will work (regarding extra info about the options) so here it is:
The launcher will have an internal text file from where he'll fetch the options description (available offline). If an option is clicked, that description is shown on the right, where the placeholder text is.
However, the wiki might contain more information than what is available in the internal description file (which, by the way, will be included in the list of files to be updated by the launcher) so that's why the ability to double-click the option is there. But the launcher will work just fine without internet access.
To be honest, I am not actually sure we need this. In my mock up using settings from the mod.ini was merely a quick way of setting up the launcher based on the settings the game could use (i.e a new SCP user wouldn't need to know that Diaspora requires a powerful PC while JAD doesn't. They'd simply pick a set based on the power of their PC).
If you find you're having to force the use of flags in order to get the correct behaviour for your mod then that means you're doing things wrong/need to get the SCP to make that flag a table setting.
The mod.ini will be backwards-compatible. You ll be able to use your existing mod.ini (your entire mod actually) with the launcher, if you don't feel like modifying it to make the launcher look pretty.
So if you're lazy, that won't be a problem.
We what that the launcher can be "modded" by the means of mod.ini file (so we can use it with every thing out there), so MOD/TC authors won't have to look under the hood or do a recompile for their specific MOD/TC.
At the moment, we have only one set of recommended options available to be named by the author via the mod.ini, but what stops us to make possible to have multiple (named) sets of recommended options, just like what you posted in your thread.
how would you handle installing a mod manually?
how are mods to be packaged?
Your question was answered in the answer to Karajorma above. You can do a bit of fiddling with the mod.ini if you want, otherwise you can just dump your mod as it is and the launcher will work fine. The only requirement is that you MUST have a mod.ini file. Even an empty one. I think this is a sensible requirement anyway....
-
fiddling with inis is hardly a usable solution for an end user, shouldn't there be a 'load mod' button or are you expecting the mod developers to make some sort of installer (which would defeat the purpose of an integrated installer)
-
The idea was that the developers can fiddle with the mod.ini to customize the launcher for their particular purpose if they want. Otherwise, the current mod.ini format and content will be more than enough. Sorry for the misinformation.
For the user, if he has an old mod on some dusty backup cd, he can use it with the launcher, provided that the mod has an mod.ini file in it's folder. Even an empty one will suffice, the launcher will fill in some default info in the mod section (a generic "freespace mod" image, a "no description available" text, etc).
We'll even provide a blank mod.ini file to be copied in the mod folder for the lazy user :p or for the less technical of us who have no clue on how to create a specific file.
Hope this answers your question.
LE:
I'm a bit short on time, but I'll try to make a mod.ini today to showcase what and how can be done.
-
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.
-
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.
-
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.
-
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.
-
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. ;7
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?
-
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)
-
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.
-
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 :D
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.
-
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..... :p
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.
-
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.
-
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.
-
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.
-
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..... :p
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.
-
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.
-
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.
-
The point was to remove the need for different folders for each TC.
-
Which is nice in theory, but a really bad idea in terms of support, for the reasons I outlined above.
-
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.
-
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.
-
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.
-
How is "TCs should be installed separate from FS2" incoherent?
-
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.
-
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:
SCP dir -- Launcher resides here
|---> FS2 -> All FS2 data, mods and executables go here
|---> TBP -> All TBP data, mods and executables go here
|---> Diaspora
...
-
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.
-
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.)
-
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....)
-
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.
-
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.
-
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.
-
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. :)
-
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.
-
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.
-
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?
-
TBP, at least the DVD version.
-
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.
-
This does bring up the distribution and packaging issues again.
-
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.
-
/me ducks
-
No. No Registry. Please do not use the Registry. Registry is bad. %APPDATA% is a much better choice.
-
So long as you don't create a folder in My Documents, anywhere is fine by me. :p
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.
-
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 (http://en.wikipedia.org/wiki/Advanced_Packaging_Tool) managers (http://en.wikipedia.org/wiki/Portage_%28software%29) work (http://en.wikipedia.org/wiki/RPM_Package_Manager) 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.
-
So long as you don't create a folder in My Documents, anywhere is fine by me. :p
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.
-
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?
-
The FSPort is a mod for FS2, not a stand-alone total conversion, so you'd install it in your FS2 directory.
-
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.
-
On the *nix systems, it's wherever user data is stored typically, ~/.fso_launcher or something.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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).
-
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 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.
-
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).
-
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.
-
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. :P 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.
-
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.
-
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. :)
-
That's what log files are for.....
-
It's crashing! Dammit, why didn't I think of that? :doubt:
Seriously - you could say that. Then again, why offer options, that shouldn't be used? Can you think of one good reason?
-
No.
Hmmm.....Idea: Next to the regular launch button, put a "Troubleshoot" button. This would automagically select the debug version of the currently selected exe, detect if FS is running, and pack up the log and whatever debug info the Launcher can generate into a package that can be uploaded to HLP once FS has quit.
-
That could work.
Then again, currently flags are read from the EXE file. Why just not replace that with an ini file, which could be modified, like somebody suggested here already? I had to do something similar with the IOMeter benchmark when I was conducting performance evaluation of OpenVZ systems - in that case it was the info from /proc/partitions.
-
Hmmm.....Idea: Next to the regular launch button, put a "Troubleshoot" button. This would automagically select the debug version of the currently selected exe, detect if FS is running, and pack up the log and whatever debug info the Launcher can generate into a package that can be uploaded to HLP once FS has quit.
Yes, that was actually one of the ideas that we tossed around while kkmic and I were developing the proposal. It never made the transition to the current layout, though. In the a previous version, it was a "Having problems?" button, that took the user through a wizard, that would explain to the user that we need them to repeat the problem with a debug build. When the debug build exited, it would then ask if they were able to repeat the problem, if so, the wizard would offer to post the log to pastebin, and open the (designated, by mod.ini) support forum with a sort of template in the post box to prompt the user (like what some bug trackers will do) for the important information. The template would include the pastebin url.
That being said, I have not actually looked at the feasibility of getting this to work, but that was the general plan for the wizard, anyway.
The_E, as a guy that does a lot of the support, what are your thoughts on the system? Can anyone comment on the feasibility of this?
As for information that the launcher could generate, something like a cpu-z log of the hardware (though I am not sure what all the fs2_open.log contains, or more accurately can contain, though I know it identifies the graphics card), or the launchers own debug log, that could contain information on the contents of the relevant mod.ini's. Any suggestions for useful information that we currently have the user collect, but that the launcher would be better suited for?
It's crashing! Dammit, why didn't I think of that? :doubt:
Seriously - you could say that. Then again, why offer options, that shouldn't be used? Can you think of one good reason?
Automating the collection of the data would be very helpful in a lot of these cases.
As kkmic and I have already said, we plan on supporting ways for the mod author to force and recommended flags, contrary to karajorma's protests (once game-settings is implemented it will likely not be an issue, but until then), we do plan on having flag suggestions and for the mod authors. Though at least as the design stands now, when the .ini says blacklisted, the launcher will prompt the user:
The mod author highly recommends that this flag not be turned on as will cause you problems including crashes while playing the mod/TC. Are you sure that you want to enable this flag?
No, do not enable <flag>.
Yes, enable <flag> anyway.
Tolwyn, you seem to want them completely invisible to the user, which is certainly a possibility, but as kkmic noted, all it would take is the user changing the mod.ini and then the banished flag would be visible. The ease at changing the ini is the biggest reason that we would rather go with the prompt then remove the flags completely from the interface.
Last time I checked, mipmapping flag was in the "graphics" category. :P 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. :)
Yes, I was not really referring to the actual categories that the .exe puts them in, because as you noted the categories are technically right, but not really useful for choosing which should be a TC setting and which should be a user's machine setting. Though, I think this is why karajorma wants to move some of the flags to a game-settings.tbl.
I have read what the wiki has to say about the -mipmap (http://www.hard-light.net/wiki/index.php/Command-Line_Reference#-mipmap) flag and I am not sure how it would cause problems for a TC. The quality of the mipmaped images wouldn't be as good as if they were done manually, but it seems like a useful feature.
-
Actually not. DDS textures should be created properly (e.g. with mipmaps). Generating mip maps for stuff, that does not require them is just a waste of ressources.
-
The_E, as a guy that does a lot of the support, what are your thoughts on the system? Can anyone comment on the feasibility of this?
As for information that the launcher could generate, something like a cpu-z log of the hardware (though I am not sure what all the fs2_open.log contains, or more accurately can contain, though I know it identifies the graphics card), or the launchers own debug log, that could contain information on the contents of the relevant mod.ini's. Any suggestions for useful information that we currently have the user collect, but that the launcher would be better suited for?
Now idea how feasible this is, but something like that would make support so much easier. In terms of additional information that the fs2_open.log does not provide, a complete directory listing of the selected mod directory (or directories) would help as well.
-
Shouldn't a full report be generated by the fs2_open?