This got me thinking. And that's bad. Bad like, you know, cats and dogs living together... mass hysteria...greenfreedom10 wrote:I agree! Trying to understand/use the config file to set up vegastrike (especially fine-tuning for my low-end integrated intel graphics) is nearly impossible with a disorganized default config and many extra, undocumented or seemingly overlapping config options. But I guess that belongs in another thread.
Is the default config really disorganized? No; it has a logic; but it's meant for the vssetup, not for us humans.
Activating/deactivating sections by commenting/uncommenting them, based on the section names matching the choice values, was a smart and "cheap" ( = easy to implement) way; but it has this nasty side effect for us non-vssetup-based lifeforms.
Overlapping is due to the fact that some values are influenced by settings of different choices (gfx card class setting overrides values in quite a few areas) so the parser has no other choice than reading the xml sequentially and let the last setting for each value prevail, kinda neglecting the structural features of xml over plain ini.
But then, why keeping the commented sections in, when the game parser will ignore them? Because the same file is both source and destination of the vssetup work; so all sections must be kept in case we want to reactivate them.
So I was thinking (beware, big alert, haven't checked the code so this is all an assumption) that a change in vssetup only could benefit us all: split the in and out config files.
Suppose we get a config-source file, keeping the current one as the destination (hence requiring no changes in the main game);
the source has all the sections, all active, and it's used to feed vssetup the values for all the settings just as it is now; but, when the user chooses to save, the destination is totally rewritten with only the parts that match the user's choices, zapping all comments.
The only con I can think of as of now, is that if someone does fine tuning on the destination and then uses vssetup again, the custom settings will be lost; so, once someone finds settings they like, they should edit the config-source as well in the corresponding sections.
So, how doable is this? Is it worth the effort? By wild guessing, I'd say it is...