Minetest Lua Client Modding API Reference 0.4.15
================================================
* 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.
Transfering client-sided mods form 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.
Paths
-----
* `RUN_IN_PLACE=1` (Windows release, local build)
* `$path_user`:
* Linux: ``
* Windows: ``
* `$path_share`
* Linux: ``
* Windows: ``
* `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
----------------
**NOTE: Not implemented yet.**
Mods can be put in a subdirectory, if the parent directory, which otherwise
should be a mod, contains a file named `modpack.txt`. This file shall be
empty, except for lines starting with `#`, which are comments.
Mod directory structure
------------------------
clientmods
├── modname
| ├── depends.txt
| ├── init.lua
└── another
### modname
The location of this directory.
### depends.txt
List of mods that have to be loaded before loading this mod.
A single line contains a single modname.
Optional dependencies can be defined by appending a question mark
to a single modname. Their meaning is that if the specified mod
is missing, that does not prevent this mod from being loaded.
### 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.
`minetest.setting_get(name)` and `minetest.setting_getbool(name)` can be used
to read custom or existing settings at load time, if necessary.
### `sounds`
Media files (sounds) that will be transferred to the
client and will be available for use by the mod.
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: Not fully implemented yet.**
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 on all clients
{
gain = 1.0, -- default
}
-- Play locationless to one player
{
to_player = name,
gain = 1.0, -- default
}
-- Play locationless to one player, looped
{
to_player = name,
gain = 1.0, -- default
loop = true,
}
-- Play in a location
{
pos = {x = 1, y = 2, z = 3},
gain = 1.0, -- default
max_hear_distance = 32, -- default, uses an euclidean metric
}
-- Play connected to an object, looped
{
object = ,
gain = 1.0, -- default
max_hear_distance = 32, -- default, uses an euclidean metric
loop = true,
}
Looped sounds must either be connected to an object or played locationless to
one player using `to_player = name,`
### 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", ref=ObjectRef}`
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[,;,;;