0.6 plans

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

0.6 plans

Post by safemode »

Lots of ideas have been thrown around on the forums. There is a checklist of stuff to be done on 0.6 at http://vegastrike.sourceforge.net/wiki/ ... dmap:0.6.0

I think we should greatly reduce the amount of stuff scheduled for the next release. Perhaps making them subdivisions of 0.5.x until everything on the wiki is addressed, then having it move to 0.6

For the next immediate release, maybe a 0.5.1. We should do a few things.

1. Make a high quality graphics texture pack. This shouldn't require a change to code, except in vssetup, and the only change to data4.x would possibly be a config file change, though it's not necessary.

2. continued updates to the shader and it's textures in units.

3. End User tools for helping with content creation. These should be a part of vegastrike code-base, to keep things in sync and reduce maintenance.

4. Minor bug fixes.

that's it. We release then move on to 0.5.2

1. Ray Collider. (alongside bsp collider tunable via configure switch ala how opcode was done). Wont be turned on by default until 0.5.3

2. More shader fixes, texture updates/additions.

3. Make tools and readers operate on a Proper XML format , this could be switchable via special comment at top of xml input. This is for backwards compat with non proper xml files in mods. To be made default in 0.5.5

0.5.3

1. Ray collider turned on, BSP stuff removed.

2. More shader fixes (should be pretty good by now), texture updates/additions

3. Continue to work on proper XML parsing in engine and content creation tools. update xml files in VS to be proper mode.

4. Minor bug fixes.

0.5.5

1. make proper xml mode default, remove code to parse obsolete xml-ish code.

2. Continued texture updates, additions.

3. Bug fixes. Get codebase stabilized in prep for refactoring graphics code.

0.5.6

1. Refactor graphics code.

2. Refactor sound code.

3. Bug fixes.

0.5.7

1. Bug fixes.

2. Texture additions/ etc

3. Document refactored graphics and sound code.

0.5.8

1. Thread graphics code and sound code with boost threads.

2. Bug Fixing.

0.5.9

1. Bug fixes.

0.6.0

1. Minor bug fixes from previous revision.



Notice, i skipped some things from the wiki prior to hitting 0.6, that stuff can wait till after 0.6, I think what's described above is enough to last us till the end of the year easy.

Now, if only we had the man power to stick to goals :)
Last edited by safemode on Wed May 28, 2008 2:30 am, edited 1 time in total.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

These releases could be real (with patches and new pkgs) or just svn tags. I dont care.

I think it'll give us a clearer motivation and direction by tagging on goal competions rather than just arbituary large code base changes. With any luck, that will equate to most developers not straying far from goals and doing their own thing.

Obviously the above list is vague on data side changes, and there is some room for additional engine changes other than what's listed, and changes to what's listed are welcome. I just think we really should chomp our list of things to do into bite sized pieces and make releases (at least tags) based on those bite size pieces. If anything, us developers need a clear and atainable near-term direction.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

One change in code that needs to be done ASAP, long before 0.5, in order to make incremental improvements to shaders and texture packs as you describe for 0.51, 0.52, etc., is to add a "TexturePackingVersion" variable to xmesh.
Let me give you some examples of the problems, and how this new variable would solve them:

Problem:
Currently, the shaders compute shininess using an ad-hoc formula from the specular value. This works very badly. For all new texturings, we'd like to include shininess in the alpha channel of the specular texture. But the problem is that a shader has no way to tell whether the alpha channel is present.
Solution:
Write TexturePackingVersion=2 in the unit's xmesh when adding shininess to spec alpha. The engine would assume the value of the variable is 1, if not present.
When the engine sees a value of 2, it looks for a shader with a "002" at the end of the name. This shader pulls shininess from spec alpha, rather than compute it using the ad-hoc formula.

Problem:
The present fragment shaders add ambient light to a unit. The OGL-style ambient light component looks like garbage, because of the lack of ambient occlusion modulation. When I texture a ship, I add ambient occlusion modulated ambient light to the glow texture, so the ambient light component is no longer necessary. In this case, however, the texturePackingVersion variable just happens to not be not so necessary; because I can turn ambient light to zero in the mesh. However, having the shader add ambient light is a waste of precious shader instructions.
Solution:
Add variable to the unit's xmesh TexturePackingVersion=3.
When the engine sees a value of 3, it looks for a shader with a 003 at the end of the name. This shader simply ignores ambient light.

Problem:
Firstly, the solution above does not allow modulation of ambient light for a unit from the system's ambient light. Secondly, DDS compression is particularly bad at handling smooth gradients (causes banding artifacts). But the way I currently apply ambient occlusion is, partly as ambient light modulation of the ambient light component in the glow texture, as I was mentioning; partly the square root of the ambient occlusion modulating the diffuse texture; partly the square of the ambient occlusion baking modulating the specular texture. But all these modulations result in smooth gradients that suffer when DDS-compressed.
The solution I have in the pipeline is to let the shader do these modulations, rather than modulate the textures themselves. To do this, I would include the raw ambient occlusion bake to the texture pack as the alpha channel of the glow texture. In DDS, the alpha channel gets much higher quality compression than the RGB channels. Then the shader can compute the square, and square root, of this better quality ambient occlusion, and at full precision; and it can also modulate the ambient light component by the system's specified ambient light. Unfortunately, the shader has no way to distinguish the new texture packing and the old...
Solution:
Put TexturePackingVersion=4 into the unit's xmesh. This way, the engine looks for a shader with a "004.fp"-terminated name. That shader pulls ambient occlusion from the glow texture's alpha channel and applies it.

Without this variable, we wouldn't be able to improve shaders and texture packs incrementally. We'd be forced to change all units in data4.x at once, whenever we change the shaders to use a new texture packing.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

I'm going to add a little something. Though, i'm not sure exactly where it'll fit in.


We have opcode which has geometry and physics type classes internally. Then we have other classes that refer to the same objects.

I'd like to merge them into one class, and make all the code share the same code.

In addition, I'd like to get SIMD versions of vector and matrix classes setup, via templating Matrix and Vector, quaternion. GCC can auto-vectorize some loops, but performance is hit or miss becuase of alignment. By using things like simdx86, we can make some calculations also vectorized.

I'm thinking these changes would occur around 0.5.8 after the code has been properly compartmentalized
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Re: texture packing, I'll try something infinitely more interesting: techniques. You can still use techniques named "StandardPackingX" and such, but you could also use "StandardPlanetX" :D

I think it would be doable. How cleanly doable is the thing. But doable.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

I know what you're thinking, Klauss: procedural shader generation... It's a good idea, but on the other hand we don't want to proliferate the shaders just yet. We need to evolve through a few texture packings, all the way to your GI; and once all the models are converted we can start having specialized shaders. Right now what we need is a clean solution for the problem that shaders cannot evolve because all units have to be changed at once. THAT is the immediate problem. To solve it, we need to to keep concurrent shader variants. That's enough shaders! If we try to have specialized shaders at the same time, it will be a nightmare. Could we just solve our first problem first? All it takes is a variable in xmesh. Just a little bit of code => great happiness.
Mr. Fahrenheit
Trader
Trader
Posts: 26
Joined: Mon Jan 15, 2007 4:06 pm

Post by Mr. Fahrenheit »

Does this (thread and discussion) mean that there's an official 0.5 release available? Or if not, that a straw-man date for such a thing is being thought of? Just curious...
bgaskey
Elite Venturer
Elite Venturer
Posts: 718
Joined: Wed Mar 07, 2007 9:05 pm
Location: Rimward of Eden

Post by bgaskey »

Nope no release out yet. Hopefully within the next week. The original plan was by the end of August, but it may have been delayed slightly... but soon now. :wink: stay patient
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

Release process...

can this get documented in detail somewhere? It seems like the release process is somewhat outdated from the little I've heard of it's details. Plus, it would be nice to have that part of the project out in the open in detail.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

Well, assuming things go according to plan (plans discussed anyway), my first personal order of business is getting mini-xml (library for correctly parsing valid xml), incorporated into VS. This will be done in a completely backwards compatible way with that compatibility being removed by 0.5.5

Mini-xml support will coincide with updates to our xml files (can be done incrementally), and with the introduction of helpful tools for editing some of our more complex configuration files.

The tools will eventually fall under CSV editor ( this will have various submenus for units.csv, weapons, cargo etc), system/galaxy XML editor, and a new setup tool for the config file.

Those are the ones I plan on making. Others that would be more complicated are mission editor, campaign editor and anything else i'm missing.


The main issue i'm having is deciding what GUI toolkit to use. I want to make these tools using python, so that they can be modded and crossplatform without having to deal with the compiler, but at the same time, that may end up being more difficult than just doing gtk C++ apps. I'm kinda mulling it over and want some input.
Ed Sweetman endorses this message.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

Python might be easier to learn, easier to use, and attract a large group of contributors to improve the applications. I don't really like the idea of using c++ for applications that are not computationally expensive. And there are cross platform APIs available. Examples include PyGUI or the more visually enabled uxPython. A simple application window can be written with as little as 20 lines of code (http://www.uxpython.com/docs/quickstart-hello).

In any case the gui development should follow the xml standardization of files to avoid unnecessary rewriting.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

my intention was to go the python route, but i was unsure what python toolkit to use (there are many) and keep in mind, most people dont have those tookit's installed. Indeed, i think we use libpython to make use of python, rather than a parser so i'm not sure how that's gonna work (which was my concern for having to fallback to gtk C++ apps, since we install the libs for that). I planned on using the same mini-xml lib to parse xml as i'll be putting in vs.

so basically it comes down to if python's runtime parser is installed on all system's vegastrike is installed in (or would we have to make an additional external requirement?), what tookit to use (only one is shipped with python, tkinter), and what to do if python's runtime parser is not installed currently.

If we dont require a runtime python parser then i dont see how we can justify it being installed for these small applications.

We might have to make small c++ wrapper applications that execute all the python code, basically leaving all the functionality to the python code and only the executing and linking to the python library to the C++ code.

That would probably be how we'll have to do it. Make a little C++ app that loads a particular python script (our program), and that's it. It should have no features or functionality so it shouldn't ever need to be changed, all so we'll retain moddability and all the ease of making a python gui app.

That leaves what toolkit to use, as we'll probably have to distribute it (for those non-unix systems that suck for package management).
Ed Sweetman endorses this message.
bgaskey
Elite Venturer
Elite Venturer
Posts: 718
Joined: Wed Mar 07, 2007 9:05 pm
Location: Rimward of Eden

Post by bgaskey »

I think Tkinter is probably the way to go. It seems to be the defacto standard for python gui's and its probably the best documented as well.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

the thing is, we dont install python... we carry the python library, and we have many basic python headers required for our project, but i dont know if we include tkinter support.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

I'm starting the mini-xml work this week.

I'm going to assume people are ok with the library chosen.

Basically, I'm going to make my branch (the safemode branch), the only branch i update to until everything is ratified with the higher ups and the roadmap is set in stone and everything is ok.

Then i'll start merging changes back to svn head.

Btw, you may have noticed that xml support wasn't supposed to go in until 0.5.2, but it was discussed (with those devs who are around to discuss things with) that proper xml support should go in before the tools that read xml and such get written.

So those two things are flipped, with xml support being 0.5.1 and userland tools 0.5.2
Ed Sweetman endorses this message.
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

Doesn't Vegastrike already have XML support?

I cast my vote for good userland tools. I spent a while struggling with the mesher a few days ago, which is actually surprisingly hard to get working right...
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

vegastrike seems to have some kind of home-grown xml support ....whether or not it handles xml properly or in an efficient manner, is another thing entirely.

mini-xml seems to be a much more robust and proven xml parsing library. Basically, the idea would be to replace our home-grown code with a very simple and basic interface.

basically, you wouldn't need all the vega config class crap.
you would basically have XMLSupport as a wrapper class to mini-xml functions. That's it. plus, mini-xml is threaded (if you want it to be), so, and since it's re-entrant, we have the option of handling threaded access to xml data.

in any case, the userland tools will get done as well. Making them C++ with python frontends will be a benefit as things like the mesher can have C++ functions for processing complex data and exposing it to the python gui while also allowing mods to add or remove or edit additional functionality to the gui without bothering with recompiling or patching the source code.

But like i said, I dont think we force users to install a proper python environment, we only provide a minimal environment via our C++ python library and some support python files in data4.x. That means tkinter wont be available to us. We'll have to pkg that too. Or am i wrong about that and we can assume everyone running VS has python installed and thus tkinter is available?


back to xml changes:

So basically i see using an xml file as creating an instance of an XMLSupport object, either keeping it around (if we use it recurrently) or re-using it via opening a new xml file for one time uses.


so reading in the config would be like
XMLSupport vs_config;
vs_config.open("path/to/vegastrike.config");

finding and walking through the xml file will follow mini-xml construction (which is similar to what we currently use, only better).

opening any other xml file is done the same way, a new object created, or reused.

simple, sweet, uncluttered and optimized .

Then it's a simple matter to python-ify the new XMLSupport so we can expose xml files to the userland tools and link the XMLSupport object into the C++ part of them.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Wait safemode, there's something odd with that mini-xml stuff.

VS uses a library for XML parsing already, and a very pedant one at that! It's using expat, and expat doesn't forgive the tiniest mistake, throwing assertion failures and such.

I'm pretty sure every xml file in VS is proper XML, with the only possible exception being, probably, that there's no DTD validation, which makes sense (I wouldn't want that done at runtime).

And... I already have a tinyxml-ish class based on expat in the ogre branch I believe. You don't have to work on anything, if you find that class either a good starting point or acceptable altogether. It's just a C++ wrapper for expat (which is plain C). It's rather high-performance (I made sure things loaded as fast as possible), and it's even editable (you can dump in-memory XML to a file and it even preserves comments!). In fact, the whole point I had to make that class was to be able to write XML-editing stuff that doesn't bork up comments (which are useful for people reading the XML).

If you haven't started working on it yet, I'd suggest you take a look.

BTW: it's XMLDocument.h/cpp in /branches/ogre_branch/vegastrike/src/UserInterface

NOTE: It's not the prettiest code I grant you that. It was a quick & dirty thing I needed. But you can beautify all you like, as long as you retain the main features (editability and performance).
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

then why are people complaining about non-standard type xml config files and such?

I thought the reason why was that our xml parser had to be fudged or our parser was fudged to work with crappily coded xml files.

if that's not the case then what could they have been talking about?



Assuming xml support is valid, and there's nothing wrong with what we have, then what i'd like to do in place of proper xml in 0.5.2 (original roadmap) is get rid of VegaConfig and all related mumbo jumbo.

I dont think the config file should be treated differently than any other xml file we read in.

Edit: what i mean is that there should be one interface to xml files. We have one method right now for utilizing values from xml files (getVariable), we save those values to static vars as needed (sucky but until the code is modularized, it'll do), we dont need any special classes or wrappers to do anything else with them.

Now, maybe expat works good, maybe mini-xml works better, maybe tiny-xml works better. I dont know. In the end it's whatever is easier to maintain that counts. In any case, we should have a single api to xml data.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

I believe people may be complaining about the way vssetup edits the config file. It enables/disables entire sections commenting/uncommenting them, instead of doing proper XML editing.

This makes hand-editing the config file a bit painful, because you have to keep the comments in sync with each other. Besides the extra logic embedded in those comments. Weird stuff.

Other than that, I don't know what they could be referring to.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

You are perfectly justified in complaining about VSSetup. However, the config files are the only strange part of the Vegastrike system.

Basically, Vega Strike handles XML properly using expat and friends.

However, the Setup program does not understand any of this. The only thing the Setup program understands are simple commands after a "#" symbol, and how to tweak comments:

<!-- #Category1
... disabled XML code ...
#end -->
<!-- #Category2 -->
... Vega Strike will parse this XML code since it's not in a comment ...
<!-- #end -->

[ EDITS ]
In essence, you can think of the VSSetup program as a sort of preprocessor, more than anything else, with the exception that it leaves preprocessing directives in the file after it is done with it.

Also, Vega Strike does not check for validity. Expat will stop parsing as soon as it finds something invalid, but for performance reasons, Vega Strike handles the XML during the parsing phase, rather than afterwards.
That may be why you see some .mission files that have invalid code at the bottom, but nobody notices since the important parts get parsed.
[ END EDITS ]

So if anything should be rewritten it is two things:
1. Vega Strike will have option groups (in XML) with what used to be surrounded by Comments, as well as the defaults, defined in the vegastrike.config.

2. A setup program that understands XML, and writes a User's configuration file with the updated settings. (if this file is deleted, it will use the defaults).


So why has Vega Strike been doing it the old way all this time?

The answer is that it is not easy to read in an entire XML file, make a few small modifications, and spit out a similar version.

On the other hand, it is very easy to search for # and <!-- and --> symbols: the XML rules regarding comments are very simple, assuming you have valid XML to start with. Then, it just has to tweak a few comments and spit it out again.
Indeed, the setup program does this each time you click on a dropdown--it's so fast you don't even notice it.

So anyway, I'm not saying I'm a proponent of the old method.
This chaos has to change: making everything into XML will allow users to have a custom file with only modifications/settings, and it will allow Vega Strike to modify settings inside of the game, both of which are really important.

Maybe mini_xml or Klauss's classes can help, but it is not trivial to read in, and write out a modified version of XML... especially if you want to keep user comments and things the game might not necessarily understand.

Also, I would hold off on allowing Vega Strike to write Config XML for now, until we get a new VSSetup working smoothly: it will open up a new set of synchronization problems -- you could open up vega strike, then change settings in Setup.


Also, I'm not sure why I wrote so much about this again--it's just something I like to complain about, I guess.
Last edited by ace123 on Thu Apr 24, 2008 5:11 am, edited 2 times in total.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

well that will go away after the new config editor is made.

the vegastrike.config will hold default values, the python coded editor will deal with all the valid values and settings. It'll then output a config file to the user's "home" directory with only the config parameters that are utilized.

Basically, all the vegastrike.config in data4.x will do is tell the new vssetup what options to show as being enabled when it loads, what gets outputted is coded in the python script of the vssetup program. The various pulldows and radio buttons and such will output little self contained chunks of xml that the program will know how to put together via the xml parser and write a neat properly formatted xml file.

The new vssetup would have provisions for mapping the entire keyboard to all available commands, (point and click like), joystick configuration, auto-detection of display settings (should be reportable via the gui toolkit), advanced config settings etc. All with proper bounds checking and validation of config values.

What's also cool is that we could detect vssetup hasn't been run (on new installs), and load the vssetup python script from within vegastrike, forcing the user to create a config file, then load up our config file and run.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

mini-xml can alter xml values very easily.

read in xml file via load function
then change some text in a given node :
mxmlSetText(node, 1, "new");

then you write the xml data to your new config file. done.
it's quite easy.

the new setup program will be nothing but python, and it'll have python hooks to the same XMLSupport class that vegastrike has access to. Thus it'll be able to parse and handle xml just as well.


In addition to that, i'd be cleaning out the xml support files so that the api for it's use is clear.

I want _everything_ to go through XMLSupport. I want XMLSupport to handle opening, retrieving, listing children/parent nodes, editing, and saving xml data.

All vegastrike and userland tools will communicate to xml files via the XMLSupport class.
Last edited by safemode on Thu Apr 24, 2008 5:18 am, edited 1 time in total.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

One of the annoyances people have been complaining about, IIRC, is that editing the config file by hand isn't either easy or recognized by vssetup. That's why I'm not a big proponent of letting vssetup generate a new .config file, but rather I'd modify VS code so that simple and small changes on an anciliary .config file controls what is read from the big config file.

Ie:

In presets.xml

Code: Select all

<preset name="default">
  ...defaults here...
</preset>
<preset name="ExtremeGraphics">
  ...overrides from the default to get extreme graphics...
</preset>
And in vegastrike.config

Code: Select all

<set preset="default"/>
<set preset="ExtremeGraphics"/>
<set preset="blah"/>
...
<!-- then custom overrides -->
<section...
   <var name="x" value="y"/>
</section>
Or something like that.
The idea is that if I edit the .config file, then vssetup does pick the changes. Plus, the .config file can be left out of SVN, and only presets.xml is versioned (which is another big issue - people commiting changes to .config files really is bothersome)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

I think it's easier to just ditch vssetup and do an xml editor the right way and give it a pretty gui tailored to a config setup tool. Put the bounds values in the python code (where it belongs), make a small default config file to give the user some good starting values (that file isn't used by the game).

Then all the selected values are saved giving you a proper xml config file.

Various tabs in the gui can allow the user to see a keyboard and set various keys to commands, a joystick window if that's seleceted to give the user the ability to set joystick buttons, etc etc.

The save function would then traverse all the active values in the gui and push them into the xml parser creating a brand new file and save that xml tree data to the user's home dir.


edit: let me clarify too, the vssetup in my world would use the exact same xml code that vegastrike uses. It's nothing but a python script with C++ hooks to the same object file linked into the vegastrike binary. The C++ part of the new vssetup would be compile time linked to the same XMLSupport.o file with it's own set of python hooks in it's private vssetup.cpp file.
Last edited by safemode on Thu Apr 24, 2008 5:32 am, edited 1 time in total.
Ed Sweetman endorses this message.
Post Reply