Minetest Lua Client Modding API Reference 5.4.0 ================================================ * More information at * Developer Wiki: Introduction ------------ ** WARNING: The client API is currently unstable, and may break/change without warning. ** Content and functionality can be added to Minetest 0.4.15-dev+ by using Lua scripting in run-time loaded mods. A mod is a self-contained bunch of scripts, textures and other related things that is loaded by and interfaces with Minetest. Transferring client-sided mods from the server to the client is planned, but not implemented yet. If you see a deficiency in the API, feel free to attempt to add the functionality in the engine and API. You can send such improvements as source code patches on GitHub (https://github.com/minetest/minetest). Programming in Lua ------------------ If you have any difficulty in understanding this, please read [Programming in Lua](http://www.lua.org/pil/). Startup ------- Mods are loaded during client startup from the mod load paths by running the `init.lua` scripts in a shared environment. In order to load client-side mods, the following conditions need to be satisfied: 1) `$path_user/minetest.conf` contains the setting `enable_client_modding = true` 2) The client-side mod located in `$path_user/clientmods/` is added to `$path_user/clientmods/mods.conf` as `load_mod_ = true`. Note: Depending on the remote server's settings, client-side mods might not be loaded or have limited functionality. See setting `csm_restriction_flags` for reference. Paths ----- * `RUN_IN_PLACE=1` (Windows release, local build) * `$path_user`: `` * `$path_share`: `` * `RUN_IN_PLACE=0`: (Linux release) * `$path_share`: * Linux: `/usr/share/minetest` * Windows: `/minetest-0.4.x` * `$path_user`: * Linux: `$HOME/.minetest` * Windows: `C:/users//AppData/minetest` (maybe) Mod load path ------------- Generic: * `$path_share/clientmods/` * `$path_user/clientmods/` (User-installed mods) In a run-in-place version (e.g. the distributed windows version): * `minetest-0.4.x/clientmods/` (User-installed mods) On an installed version on Linux: * `/usr/share/minetest/clientmods/` * `$HOME/.minetest/clientmods/` (User-installed mods) Modpack support ---------------- Mods can be put in a subdirectory, if the parent directory, which otherwise should be a mod, contains a file named `modpack.conf`. The file is a key-value store of modpack details. * `name`: The modpack name. * `description`: Description of mod to be shown in the Mods tab of the main menu. Mod directory structure ------------------------ clientmods ├── modname │   ├── mod.conf │   ├── init.lua └── another ### modname The location of this directory. ### mod.conf An (optional) settings file that provides meta information about the mod. * `name`: The mod name. Allows Minetest to determine the mod name even if the folder is wrongly named. * `description`: Description of mod to be shown in the Mods tab of the main menu. * `depends`: A comma separated list of dependencies. These are mods that must be loaded before this mod. * `optional_depends`: A comma separated list of optional dependencies. Like a dependency, but no error if the mod doesn't exist. ### `init.lua` The main Lua script. Running this script should register everything it wants to register. Subsequent execution depends on minetest calling the registered callbacks. **NOTE**: Client mods currently can't provide textures, sounds, or models by themselves. Any media referenced in function calls must already be loaded (provided by mods that exist on the server). Naming convention for registered textual names ---------------------------------------------- Registered names should generally be in this format: "modname:" ( can have characters a-zA-Z0-9_) This is to prevent conflicting names from corrupting maps and is enforced by the mod loader. ### Example In the mod `experimental`, there is the ideal item/node/entity name `tnt`. So the name should be `experimental:tnt`. Enforcement can be overridden by prefixing the name with `:`. This can be used for overriding the registrations of some other mod. Example: Any mod can redefine `experimental:tnt` by using the name :experimental:tnt when registering it. (also that mod is required to have `experimental` as a dependency) The `:` prefix can also be used for maintaining backwards compatibility. Sounds ------ **NOTE: Connecting sounds to objects is not implemented.** Only Ogg Vorbis files are supported. For positional playing of sounds, only single-channel (mono) files are supported. Otherwise OpenAL will play them non-positionally. Mods should generally prefix their sounds with `modname_`, e.g. given the mod name "`foomod`", a sound could be called: foomod_foosound.ogg Sounds are referred to by their name with a dot, a single digit and the file extension stripped out. When a sound is played, the actual sound file is chosen randomly from the matching sounds. When playing the sound `foomod_foosound`, the sound is chosen randomly from the available ones of the following files: * `foomod_foosound.ogg` * `foomod_foosound.0.ogg` * `foomod_foosound.1.ogg` * (...) * `foomod_foosound.9.ogg` Examples of sound parameter tables: -- Play locationless { gain = 1.0, -- default } -- Play locationless, looped { gain = 1.0, -- default loop = true, } -- Play in a location { pos = {x = 1, y = 2, z = 3}, gain = 1.0, -- default } -- Play connected to an object, looped { object = , gain = 1.0, -- default loop = true, } Looped sounds must either be connected to an object or played locationless. ### SimpleSoundSpec * e.g. `""` * e.g. `"default_place_node"` * e.g. `{}` * e.g. `{name = "default_place_node"}` * e.g. `{name = "default_place_node", gain = 1.0}` Representations of simple things -------------------------------- ### Position/vector {x=num, y=num, z=num} For helper functions see "Vector helpers". ### pointed_thing * `{type="nothing"}` * `{type="node", under=pos, above=pos}` * `{type="object", id=ObjectID}` Flag Specifier Format --------------------- Flags using the standardized flag specifier format can be specified in either of two ways, by string or table. The string format is a comma-delimited set of flag names; whitespace and unrecognized flag fields are ignored. Specifying a flag in the string sets the flag, and specifying a flag prefixed by the string `"no"` explicitly clears the flag from whatever the default may be. In addition to the standard string flag format, the schematic flags field can also be a table of flag names to boolean values representing whether or not the flag is set. Additionally, if a field with the flag name prefixed with `"no"` is present, mapped to a boolean of any value, the specified flag is unset. E.g. A flag field of value {place_center_x = true, place_center_y=false, place_center_z=true} is equivalent to {place_center_x = true, noplace_center_y=true, place_center_z=true} which is equivalent to "place_center_x, noplace_center_y, place_center_z" or even "place_center_x, place_center_z" since, by default, no schematic attributes are set. Formspec -------- Formspec defines a menu. It is a string, with a somewhat strange format. Spaces and newlines can be inserted between the blocks, as is used in the examples. ### Examples #### Chest size[8,9] list[context;main;0,0;8,4;] list[current_player;main;0,5;8,4;] #### Furnace size[8,9] list[context;fuel;2,3;1,1;] list[context;src;2,1;1,1;] list[context;dst;5,1;2,2;] list[current_player;main;0,5;8,4;] #### Minecraft-like player inventory size[8,7.5] image[1,0.6;1,2;player.png] list[current_player;main;0,3.5;8,4;] list[current_player;craft;3,0;3,3;] list[current_player;craftpreview;7,1;1,1;] ### Elements #### `size[,,]` * Define the size of the menu in inventory slots * `fixed_size`: `true`/`false` (optional) * deprecated: `invsize[,;]` #### `container[,]` * Start of a container block, moves all physical elements in the container by (X, Y) * Must have matching container_end * Containers can be nested, in which case the offsets are added (child containers are relative to parent containers) #### `container_end[]` * End of a container, following elements are no longer relative to this container #### `list[;;,;,;]` * Show an inventory list #### `list[;;,;,;]` * Show an inventory list #### `listring[;]` * Allows to create a ring of inventory lists * Shift-clicking on items in one element of the ring will send them to the next inventory list inside the ring * The first occurrence of an element inside the ring will determine the inventory where items will be sent to #### `listring[]` * Shorthand for doing `listring[;]` for the last two inventory lists added by list[...] #### `listcolors[;]` * Sets background color of slots as `ColorString` * Sets background color of slots on mouse hovering #### `listcolors[;;]` * Sets background color of slots as `ColorString` * Sets background color of slots on mouse hovering * Sets color of slots border #### `listcolors[;;;;]` * Sets background color of slots as `ColorString` * Sets background color of slots on mouse hovering * Sets color of slots border * Sets default background color of tooltips * Sets default font color of tooltips #### `tooltip[;;,]` * Adds tooltip for an element * `` tooltip background color as `ColorString` (optional) * `` tooltip font color as `ColorString` (optional) #### `image[,;,;]` * Show an image * Position and size units are inventory slots #### `item_image[,;,;]` * Show an inventory image of registered item/node * Position and size units are inventory slots #### `bgcolor[;]` * Sets background color of formspec as `ColorString` * If `true`, the background color is drawn fullscreen (does not effect the size of the formspec) #### `background[,;,;]` * Use a background. Inventory rectangles are not drawn then. * Position and size units are inventory slots * Example for formspec 8x4 in 16x resolution: image shall be sized 8 times 16px times 4 times 16px. #### `background[,;,;;]` * Use a background. Inventory rectangles are not drawn then. * Position and size units are inventory slots * Example for formspec 8x4 in 16x resolution: image shall be sized 8 times 16px times 4 times 16px * If `true` the background is clipped to formspec size (`x` and `y` are used as offset values, `w` and `h` are ignored) #### `pwdfield[,;,;;