FOSS gamedev and creative worlds

Note: This thread contains only a brief description and release announcements. For more details, see the wiki page: http://wiki.minetest.net/Mods/LuaConfig

This mod makes it really, really easy for other mods to load Lua-based configuration settings. It's as simple as adding "luaconfig" to your mod's depends.txt and putting this at the top of your init.lua:



and then optionally (to make settings globally visible):



This automatically detects the name and path of your mod and loads settings from "config.lua" in your mod directory and/or "mymod_config.lua" in the world directory, allowing the latter to add to or overwrite the former. No errors will be generated if either or both files are missing.

This mod allows simple Lua variable-based configuration settings that almost guarantee that you don't accidentally set global variables from the config files (you can if you REALLY try, but it's difficult). You'll have access to all variables defined from the config files using logic like:



Mod Details


Require Minetest Version: (probably any; tested in 0.4.12)

Dependencies: (none)

Soft Dependencies: (none)

Craft Recipes: (none)

API:

Git Repo: https://github.com/prestidigitator/minetest-mod-luaconfig

Copyright and Licensing

Author: Prestidigitator

License: WTFPL

Change History

Version 1.0

• Released 2015-05-03
• First working version.

Wow, very nice! My only concern is that this is another dependency that mod users would need to hunt down and install (and which most players won't see the point of). On the other hand, this is generic enough that it should be built in, or at least present in most games! It has my vote, at least ;-)

My other concern is whether it's better to have your configuration in the mod folder / world folder as in luaconfig, or to piggy-back minetest.conf. The advantage of the latter would be that you won't clobber your configuration when you update the mod – but I've also seen .conf.example files to take care of that…

Yeah. Valid concerns, and I considered them. I realized I was writing this bit of code a second or third time in developing another mod, knew I would be doing it again in the future, and realized that much reuse justified a library or mod of some sort (not to mention that I've seen similar functionality in places like VanessaE's mods). I could have just made a reusable Lua file and copied it between all my mods, but it's something I think others have the potential to use too, and I rather dislike duplicating code everywhere anyway.

While a mod can certainly load things from the general Minetest settings, there's definitely something to be said for keeping a stand-alone, easily understood configuration file, and better yet a configuration that can be customized from world to world as well as from server to server. Those who believe their settings best belong in minetest.conf probably won't benefit from using this mod, no, and they already have a convenient API from minetest.setting_get(), minetest.setting_set(), etc. (though they probably aren't as convenient as something that keeps a full native Lua data structure like here). I've seen others keeping their own configuration files, and this has the potential to standardize that practice so both modders and users know where to expect settings and how to use them.

minetest.setting_get is supposed to be used by mods, although it doesn't have a very good system for defaulting to a value if the setting does not exist.

See how I solved this in Capture The Flag

Ben wrote:Wow, very nice! My only concern is that this is another dependency that mod users would need to hunt down and install (and which most players won't see the point of). On the other hand, this is generic enough that it should be built in, or at least present in most games! It has my vote, at least ;-)

+1

Ben pretty much sums it up for me, something like this would be ideal as part of builtin. minetest.conf is simply not flexible enough to handle the requirements of some mods, not to mention being a PITA to use.
I will most likely end up using this myself as support for the way I currently handle these files may soon be dropped as part of the proposed security improvements.