CLI flags should always support some form of 'help' (/? -? -help --help /help), usually a version (--version /version). Beyond that, it depends on the app. Personally, I think any non-trivial app should have a config file parameter (often -f "path") which would then fiddle with most stuff.
I'm not a big fan of XML in general, and specifically for this. In game consoles are more useful, and it's generally trivial (and expected) to read in that config file and pass line by line into the in game console parser ala-quake.
Silent Expectations : The Command Line
Quote:Original post by CJM
it lets you arbitrarily add new stuff without needing to update the parser.
You can do the same with my demonstrated solution:
variableName: value
You can store a stl map of variable names and values, then whatever needs a specific variable can pull that value from the map. There are other ways to approach that, but in the end the parser need not change when the contents of the config file changes.
Regardless, you can never "arbitrarily add new stuff" in any file and get a result in the software unless, the meaning of that data has already been defined in that software.
Quote:But then you miss out on all of the goodness that you can get from XSLT or whatever it's called.
Why would a config file need XSLT? The find function in notepad is likely more than enough. The need for XSLT is generated by the complexity of XML, if you don't use XML you don't need XSLT.
Quote:TinyXml
2+ MB is not tiny, TinyXML is a complex parser with plenty more overhead than a simple config file needs. A config file is an ant, TinyXML is an obese hammer.
Quote:While I agree that sometimes XML isn't the solution, in 99% of non-realtime cases, it is.
There was a time when I was steering at XML hard enough to believe that as well. Implementing it and then looking back on my previous solutions showed me the light. XML has more features, more restrictions - especially on what is and is not an invalid character [flaming] -, and more excessive syntax than most non-realtime cases are going to need or use.
Quote:
<configuration>
<profile name="profile1">
...
<videomode width="1024" height="768" redbits="8" greenbits="8" bluebits="8" alphabits="8"/>
</profile>
<profile name="profile2">
...
</profile>
</configuration>
<playlist name="myPlaylist">
<song name="Song Title" filename="song1.ogg"/>
<song name="Song2 Title" filename="song2.ogg"/>
</playlist>
I will agree that the heirarchal nature of your data makes the XML syntax and available tools an attractive option. However, XML is not the only text based means of storing heirachal text data. Regardless, in most cases a config file is simple and does not need an heirachy of data. Personally I would not put the data in your demo in one config file, I would keep that data with the resources that they relate to. Data should be organized according to how it is used and accessed.
One thing I have always hated doing, is clicking through the same menus to accomplish the same initial tasks when connecting to a game server (e.g. connecting with a username/password, selecting a server, selecting a character, etc). Being able to "game.exe -connect myhost.com:8110 -username superdude -password mypass2000" from a commandline / bash script / Windows shortcut, I could save myself the aforementioned nuisance.
It seems that (and this is true both of games and command-line applications e.g. in Linux) command-line is the super-override alternative, whose fallback is config files, whose fallback is hard-coded application 'minimum configuration'. If your game allows for cmdline options to shorten the amount of time the user must spend kludging through GUIs, then all the more power to you.
It seems that (and this is true both of games and command-line applications e.g. in Linux) command-line is the super-override alternative, whose fallback is config files, whose fallback is hard-coded application 'minimum configuration'. If your game allows for cmdline options to shorten the amount of time the user must spend kludging through GUIs, then all the more power to you.
Like Telastyn, I expect at least -h or --help.
And I think XML configuration files are often overkill.
And I think XML configuration files are often overkill.
for my last .NET project I used both INI and XML. The situation was simple, being as how I program C# .NET at work and the XML libraries are even more easily available than any INI wrapper library I initially set out to just use XML. Then things came up where I wanted more people to be able to open up and edit some core settings, and XML is quite simply NOT in any way usable by non-computer people - and I didn't have time to write a custom editor. So I made an INI file for the user-level settings and used XML for the program data files. Over time the user settings file grew to include more and more debug and config choices as well. So now there are 3 XML formats and 2 INI files. And I'm happy that I'm not wasting time and energy forcing myself to adapt everything to one or the other, cause this solution is working great for me.
Author
Hey guys, thanks for your comments again you've really given me something to think about.
As for the reason I was thinking about using XML as opposed to the usual INI file was that after taking a look though the DirectX SDK I saw a project that used as mini-database to store different hardware configurations and specs, the program would query these on loading and then configure itself for the most optimal settings for that hardware.
It's been a big toss up between XML (tinyXML) and SQL (SQL lite) but I recently made the decision to use SQL and provide a nice GUI for storing and changing the configuration. This was mainly because I was already using SQL for storing user profiles and settings so the infrastructure was already there, XML still sounds good for storing maps and save games though.
I know this probably sounds a little 'over the top' but it's a good leaning experience and that's all I really wanted, well and a kick ass game but it's a little to early for hopes that high :)
Thanks again.
Carlos
As for the reason I was thinking about using XML as opposed to the usual INI file was that after taking a look though the DirectX SDK I saw a project that used as mini-database to store different hardware configurations and specs, the program would query these on loading and then configure itself for the most optimal settings for that hardware.
It's been a big toss up between XML (tinyXML) and SQL (SQL lite) but I recently made the decision to use SQL and provide a nice GUI for storing and changing the configuration. This was mainly because I was already using SQL for storing user profiles and settings so the infrastructure was already there, XML still sounds good for storing maps and save games though.
I know this probably sounds a little 'over the top' but it's a good leaning experience and that's all I really wanted, well and a kick ass game but it's a little to early for hopes that high :)
Thanks again.
Carlos
I was already using XML for data files, so it was pretty trivial to use it for the config file too. Admitably, it's a bit of a waste, as the config file is just 'flat data'. But changing it would require writing more code. :) As such, I only have three command line options: [-]c[onfig] "filename", [-]v[ersion], and [-]s[et] "attribute name" "value". The usage of each should be pretty obvious. :) [] denotes optional parts.
Quote:Original post by Deyja
I was already using XML for data files
I shudder at the thought. Unless your data is transfered bewteen servers from different companies using different technology.
Have you ever tried binary?
For configuration I always use Lua. Actually everything I do is bound to lua anyway.
Lua's clean, lightweight and can directly map to data objects in your code. It's as simple to read and edit as a little text file, but handles all the parsing for you. Plus you get the added benefit that you're running a scripting language so you can do far more interesting things than in XML.
Personally I hate XML. It's a tangled mess of brackets that confuses the eye and makes editing difficult.
Lua's clean, lightweight and can directly map to data objects in your code. It's as simple to read and edit as a little text file, but handles all the parsing for you. Plus you get the added benefit that you're running a scripting language so you can do far more interesting things than in XML.
Personally I hate XML. It's a tangled mess of brackets that confuses the eye and makes editing difficult.
Quote:Have you ever tried binary?Can't edit binary in notepad.
And, XML is perfect for heirarchial data; which is what I have.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
