[Mod] Configuration Panel [config]

[sorcerykid]

Configuration Panel Mod v1.1
config (by sorcerykid)

Configuration Panel is an API extension for Minetest that allows seamless loading of mod configuration at runtime. It provides much greater flexibility than Minetest's builtin 'Settings' interface, since the mod configuration itself is read as a native Lua script. Hence it's possible to include simple data structures without the need for serialization, in addition to temporary variables, mathematical expressions, and conditional branching.

• "An important use of Lua is as a configuration language...."
  from Programming in Lua: Extending your Application (https://www.lua.org/pil/25.html)
  
  "Lua started off as a configuration language. This has some nice quirks in that it's great for creating and configuring things - which is what you want to do in a game."
  from Lua Users Wiki: Lua versus Python (http://lua-users.org/wiki/LuaVersusPython)

While some might be opposed to using Lua for configuration purposes, arguing that it is anti-pattern, that's not actually true. In fact, Lua itself was originally intended to double as a configuration language, like JSON, so it is very befitting of its purpose.



Repository:

https://bitbucket.org/sorcerykid/config
Download Archive (.zip)
Download Archive (.tar.gz)

Dependencies:

Default Mod (optional)

ActiveFormspecs Mod (optional)

Installation Instructions:

1. Unzip the archive into the mods directory of your game
2. Rename the config-master directory to "config"
3. Add "config" as a dependency to any mods using the API

Source Code License:

The MIT License (MIT)

Overview

There is only one function call necessary to load your mod's configuration:

• minetest.load_config( base_config, options )
  Automatically loads the mod configuration at server-startup according to the options and returns a table of key-value pairs.
  • 'base_config' is the default mod configuration (optional)
  • 'options' are the additional options that effect loading behavior (optional)

By default, the configuration is first loaded from the 'config.lua' script within the mod directory. If not found, it will instead be loaded from a script residing within the 'config' subdirectory of the current world. That script must be named the same as the mod but with a '.lua' extension, of course.

This would be the typical order of loading on Linux distros of Minetest:

1. /usr/local/share/minetest/games/minetest_game/mods/sample_mod/config.lua
2. /home/minetest/.minetest/worlds/sample_world/config/sample_mod.lua

By specifying the option 'can_override = true', both scripts will be loaded, allowing for the world configuration to override the game configuration. So for example

Code: Select all

/usr/local/share/minetest/games/minetest_game/mods/sample_mod/config.lua
        allow_fly = false
        allow_walk = false
        allow_swim = false

/home/minetest/.minetest/worlds/sample_world/config/sample_mod.lua
        allow_swim = true

Hence, 'allow_fly' and 'allow_walk' will be false, whereas 'allow_swim' will be true. By default, however, all three would remain false since the world configuration is ignored whenever the game configuration is found.

For security reasons, configuration scripts are executed within a restricted environment. However, the following builtin functions are made available for convenience:

• core.print
• core.debug (alias for minetest.log)
• core.is_yes (alias for minetest.is_yes)
• core.has_feature (alias for minetest.has_feature)
• core.string_to_pos (alias for minetest.string_to_pos)
• core.pos_to_string (alias for minetest.pos_to_string)
• core.colorize (alias for minetest.colorize)
• core.tonumber
• core.tostring
• core.sprintf (alias for string.format)
• core.tolower (alias for string.lower)
• core.toupper (alias for string.upper)
• core.concat (alias for table.concat)
• core.random (alias for math.random)
• core.max (alias for math.max)
• core.min (alias for math.min)
• core.next
• core.pairs
• core.ipairs
• core.date (alias for os.date)
• core.time (alias for os.time)
• core.assert
• core.error

The 'core' table also contains the properties 'MOD_NAME', 'MOD_PATH', and 'WORLD_PATH' which designate the name and the path of the currently loading mod as well as the path of the selected world respectively.

A chat command is also available for editing the configuration directly in-game. Simply type '/config' followed by the mod name to configure. The interface is self-explanatory.

Special Note: Before using the chat command you must add "config" to the list of trusted mods in minetest.conf and you must install the ActiveFormspecs mod, otherwise the editing functionality will be disabled.

[sorcerykid]

I just pushed a quick-fix to address mod security issues. Now the mod should work properly when security is enabled, which is by default. However, to use the /config chat command you must add "config" to the list of trusted mods in minetest.conf:

Code: Select all

secure.trusted_mods = config

If you opt not to do this, then the editing functionality will be disabled. However, the mod will continue to function otherwise.

[runs]

Why is mandatory ActiveFormspecs?

Any chance of a version without that dependency?

[sorcerykid]

Yes, that is a good point. It's doubtful that ordinary players will need the in-game editing functionality, so the extra dependency shouldn't be a requirement for bundling with other packages. I've made note of your suggestion for the next version.

[sorcerykid]

Version 1.1 Released

A new version of Configuration Panel is ready for download. Here is a complete change log:

• Various edits to documentation
• Expanded sandbox with various builtin functions
• Fixed bug with base configuration being clobbered
• Added check for ActiveFormspecs in chat command
• Made ActiveFormspecs an optional dependency
• General code cleanup

There were no new features in this release, other than expanding the sandbox with several more builtin functions.

However, I did fix a serious bug that prevented mods from presetting their configuration via the base_config parameter to minetest.load_config(). This would have only impacted mods that actually used that parameter. For those mods that relied solely on the game and/or world configuration scripts, this would not have been an issue.

[Astrobe]

Out of curiosity, do you have pointers about using Lua as a configuration language being an anti-pattern ?