our config file parsing is...sort of a joke.

[Ind]

we don't have one, not even two, but three "standard" (wat) config parsing subsystems:

1. /common/strlib.c::config_switch stuff (with relatives all over the place within all 3 servers)
2. libconfig (most awful code i've ever seen)
3. /common/raconf.c

and thats what I'd like to discuss in this topic, please post all your opinions, my opinion:

drop all 3, write a new one with a input similar to libconfig one which is, imo, pretty good-looking and easy to read.

[GreenBox]

it's easy to write a lib like libconfig with flex+bison, but, if we can use it, why create another one?

[Ind]

yes that can also be a option

[GreenBox]

But using libconfig it would be a total config files rewrite as it doesn't follow our current config syntax

[Brian]

Would any of this change trunk/conf/help.txt ?

I'm about to edit some commands to use atcommand_help_string() and read their help text from /conf/help.txt instead of soft-coded messages in /conf/msg_athena.conf

[GreenBox]

yep. it could be something like lua, one line per string in the array as libconfig can deal with arrays and groups.

[Ind]

do any of you know if we're allowed to modify libconfig? (there are a couple things in it that are quite annoying, for example if it finds a duplicate entry in the file it drops the whole file data rather than throwing a warning or replacing.)

[GreenBox]

Yep,

http://www.hyperrealm.com/libconfig/

It's LGPL

[Ind]

Thank you :3 I'll grab my sword and start ripping stuff out of it.

[xazax]

Let's also consider how much compatiblity do we want to maintain with eA. The more config format we change, the more work we force to the users who wants to migrate to rA.

[Akkarin]

For conversion support, perhaps a similar tool to convert configs like how forums do it i.e. smf->ipb. We had one for porting item_db.txt into `item_db`, so why not for the /conf files? It shouldn't be difficult to maintain - how often do new configs pop up in eA?