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? 
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. 
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 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.
