Re: Lua as a configuration file

[Daniel Heck <dheck@...>]

Pyrogon Public <public@pyrogon.com> wrote:

> > Yeah, basically I just regurgitated your exaple.  I wasn't 
> > sure if you'd seen that table arg syntax before.
> 
> I'm still not comfy with Lua -- I've been threatening to actually use
> it now for over a year, but I still haven't actually used the language
> in anger.  Baby steps, I say.  Right now I do all my "cvars" in Lua,
> and it's kind of ugly.

I'm the author of Enigma (http://nongnu.org/enigma).  We're using Lua
configuration files, model definitions, and level definitions.  You may
want to take a look at the current CVS snapshot--it's not perfect, but
it may give you a few ideas.

Defining your "cvars" (too much quake hacking i guess :-) in Lua is
something I also did before switching to tolua, but it's cumbersome. 
What I do now is something like

namespace options
{
	extern double MouseSpeed;
	extern int FullScreen;
	// ...
}

in C++.  Let tolua create the bindings and write

	options.MouseSpeed = 4.2

in your Lua script.  It's the best solution I have found so far, at
least for configuration files.  For level definitions, a procedural
interface is naturally the better approach.

> That seems to be the cleanest way of doing it, but I'm so conditioned
> to.ini files, Quake .map and entity .def files, etc. that having a
> config file that actually executes code instead of being read/parsed
> is a bit of a, *cough*, paradigm shift for me.  But it's much cleaner
> than writing parsing code for each new type.

There's not really much of a difference between the two approaches.  If
you write your own parser, you must also call functions like "AddSprite"
at some point inside your parser.  With Lua, you call "AddSprite"
directly from the script.

And don't forget that you have a full-blown scripting language at your
hands when you define the levels.  This is great for adding dynamic
content or randomized elements to a game.

- Daniel