A config nightmare before Vegastrike

Talk among developers, and propose and discuss general development planning/tackling/etc... feature in this forum.
Post Reply
CLoneWolf
ISO Party Member
ISO Party Member
Posts: 443
Joined: Thu May 01, 2008 5:14 pm

A config nightmare before Vegastrike

Post by CLoneWolf »

from this topic:
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.
This got me thinking. And that's bad. Bad like, you know, cats and dogs living together... mass hysteria... :shock:
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...
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: A config nightmare before Vegastrike

Post by pheonixstorm »

The biggest problem to the config file is that setup does not handle the keyboard and joystick key bindings. That has to be done manually.

Before we trash or move anything in config we really need to figure out which sections or bindings actually work. If it doesn't work its a good choice for removal. If it works we need to revamp setup to handle it or push the config file into an options menu inside the vs binary.
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
CLoneWolf
ISO Party Member
ISO Party Member
Posts: 443
Joined: Thu May 01, 2008 5:14 pm

Re: A config nightmare before Vegastrike

Post by CLoneWolf »

I generally agree. Besides, the key binding lack is two-fold as it's absent in the game too; rather than making the effort twice, probably the "best" target between setup time and in-game time should be chosen and worked upon. Or, even better if possible, finding a modular solution that would work both in the setup and in game.

The pro of working on the current setup for the other options would be not to hamper the whole game development, serving as a testbed for the issue, bringing only things that are already working and optimized into the main executable, if that was the final choice.
The other pro is that my idea leaves the original config untouched, nothing moved or trashed. Only the output is cleaner (Bonus cleaning consisting of a pre-save step that cuts all the multiple assignments to the same value, writing only the last one).
So that would also leave people to keep analyzing what doesn't work and can really be cut from the original config as well, with no task blocking the other.

On a side note, Debian Squeeze has dropped *everything* GTK-1.2 related; the setup GUI really needs to be revamped in that field too, or scratched for good if an in-game version appears.
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: A config nightmare before Vegastrike

Post by pheonixstorm »

On the linux side of things setup and all the other out of game binaries that use GTK+ can use 2.X If fact if you compile using the cmake makefiles it looks for gtk2 and not gtk1. The only thing really stuck on the 1.2 or 1.3 gtk is on the windows side of things and for that I would like to get the gtk windows theme engine working so it has more of a windows look rather than a windows 3.1/95 look to it. Working with QT has made me kinda touchy about how my cross platform gui looks in windows. The downside to QT though is 1. changing all the code over, and 2. the number of dependencies.

But yeah.. config changes in game or out is something I remember getting discussed briefly that needed to be moved ingame.
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
greenfreedom10
Hunter
Hunter
Posts: 67
Joined: Wed Sep 29, 2010 3:06 am
Location: Lost in an adventure

Re: A config nightmare before Vegastrike

Post by greenfreedom10 »

CLoneWolf wrote:Is the default config really disorganized? No; it has a logic; but it's meant for the vssetup, not for us humans.
Yes, that's it exactly. And a config without human logic is a failure if it can not be completely managed by vssetup or some alternative. Or it could be said that a config that a human can not understand is a failure to begin with.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: A config nightmare before Vegastrike

Post by klauss »

An easy way to revamp the config file to make it have more logic, is to cease using the commen-in/comment-out method, and instead have "available presets" and "active presets".

The change would only be a minor change to both vssetup and vegastrike's engine.

Example:

Code: Select all

<preset category="graphics/shaders" name="highend" description="High shader">
    <section name="graphics">
        <var name="default_technique" value="blabla"/>
        ...
    </section>
</preset>

<active-presets>
    <preset category="graphics/shaders" name="highend"/>
    <preset category="graphics/textures" name="high"/>
    <preset category="controls/keyboard" name="qwerty"/>
    <preset category="controls/joystick" name="genius-somegadget"/>
</active-presets>
vssetup only needs to rewrite the <active-presets> section

vegastrike only needs to search active presets when reading a config variable.

Simple.

Elegant.

Extensible.

We can even create include directives to separate the xml into manageable bits.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
CLoneWolf
ISO Party Member
ISO Party Member
Posts: 443
Joined: Thu May 01, 2008 5:14 pm

Re: A config nightmare before Vegastrike

Post by CLoneWolf »

klauss wrote:An easy way to revamp the config file to make it have more logic, is to cease using the commen-in/comment-out method, and instead have "available presets" and "active presets".
Indeed, that was a kind of "step 2" of my thoughts, as it would also require some changes in the game executable, though probably still in the "easily doable" range.
klauss wrote:We can even create include directives to separate the xml into manageable bits.
That would be great to keep, say, the joy/key bindings section in a completely separate xml, with the relevant game/setup screen only touching it.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: A config nightmare before Vegastrike

Post by klauss »

There's two XML parsing methods in VS right now.

Old code uses Easydom, I'm not sure where it comes from, but it's far from easy.

Actually there's three, even older code uses expat directly. And there's a lot of that kind of code.

New code uses a non-derivative of TinyXML (Tiny wasn't used as base code, but it did inspire it) which I wanted to call PicoXML (but there's already a PicoXML library), since it's even smaller and lighter weight than TinyXML itself, and has some nifty features I coded precisely for config editing.

Basically, the classes in XMLDocument.h are more OOP, a lot safer (though they do work with pointers, if used with proper care you seldom encounter segfaults), and support XML editing. Not only that, it supports human-friendly xml editing

What's that?

Well, when you edit stuff, it will preserve user-specified formatting like comments and indentation.

It also supports plug-in processor directives (which could be used to do include directives) and efficient access to the DOM after initial parsing. It also supports parsing very big XML files very quickly and very memory-efficiently. (I've tested with huge .xmesh files).

So...

I'd propose slowly moving all code to using that small library, since it will allow easy coding and easy editing of the XML. technique.cpp already uses, you can take a look there and see how easy its use is.

Config code could heavily benefit from it.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
CLoneWolf
ISO Party Member
ISO Party Member
Posts: 443
Joined: Thu May 01, 2008 5:14 pm

Re: A config nightmare before Vegastrike

Post by CLoneWolf »

klauss wrote:There's two XML parsing methods in VS right now.
Old code uses Easydom, I'm not sure where it comes from, but it's far from easy.
Actually there's three, even older code uses expat directly. And there's a lot of that kind of code.
Ewww. I'm all for the "If it ain't broken, don't fix it" strategy, but in the long run it can really create a zoo of fossils. Bearable as long as they don't induce maintenance trouble, but if they do, they should go.
klauss wrote:I'd propose slowly moving all code to using that small library, since it will allow easy coding and easy editing of the XML. technique.cpp already uses, you can take a look there and see how easy its use is.
Config code could heavily benefit from it.
Seconded! Death to the old style heavy unfriendly zombies, KoreXML for the win! (Klauss's Optimized Really Easy XML ;) )
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: A config nightmare before Vegastrike

Post by klauss »

CLoneWolf wrote:KoreXML for the win! (Klauss's Optimized Really Easy XML ;) )
Hey... that's a cool name :)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: A config nightmare before Vegastrike

Post by charlieg »

klauss wrote:
CLoneWolf wrote:KoreXML for the win! (Klauss's Optimized Really Easy XML ;) )
Hey... that's a cool name :)
Register it as a project on googlecode then. ;)
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: A config nightmare before Vegastrike

Post by pheonixstorm »

Klauss, post or PM a list of the files for the KoreXML :lol: and I can tinker with changing everything over from expat and that other fossil you mentioned. Also, what gives with expat anyway. The newest version dll is 128k while the one we use is about 400k i think, or I could be thinking of the libs.. either way something is odd there.
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
greenfreedom10
Hunter
Hunter
Posts: 67
Joined: Wed Sep 29, 2010 3:06 am
Location: Lost in an adventure

Re: A config nightmare before Vegastrike

Post by greenfreedom10 »

I think simplifying the config would be a great thing for VegaStrike.

- Sane defaults for variables
- Remove unused variables
- Remove or separate seldom modified variables
- Clearly define config sections
- Fix weirdness like these options in vssetup (which make no sense to me):
No Sound
My Sound Only
All Sound
My Linux Sound
All Linux Sound
greenfreedom10
Hunter
Hunter
Posts: 67
Joined: Wed Sep 29, 2010 3:06 am
Location: Lost in an adventure

Re: A config nightmare before Vegastrike

Post by greenfreedom10 »

Perhaps it is relevant that 2 config parameters have recently been added to VegaStrike. Surely something needs to be done to the config file to make it usable? Even if a parameter is successfully modified or added it may or may not work after a run of vssetup.

It seems to me that a simple and organized XML style config with comments (either in the config or in the wiki) and no vssetup at all would be better than what VegaStrike has now.

I should add that vssetup has never actually worked for me. I have always had some graphics-related issue that was not covered by vssetup. It goes like this:
  1. Try to edit the config in a vssetup-compatible way (usually multiple variables need changed, across multiple overlapping vssetup blocks)
  2. Give up and try to edit the config file by hand
  3. Fail in confusion and try to organize the config file by removing vssetup blocks, sorting the variables into their proper sections, and fixing whitespace
  4. Give up because the parameters are not documented anyway
Post Reply