Minetest Lua Modding API Reference

Introduction

Content and functionality can be added to Minetest using Lua scripting in run-time loaded mods.

A mod is a self-contained bunch of scripts, textures and other related things, which is loaded by and interfaces with Minetest.

Mods are contained and ran solely on the server side. Definitions and media files are automatically transferred to the client.

If you see a deficiency in the API, feel free to attempt to add the functionality in the engine and API, and to document it here.

Programming in Lua

If you have any difficulty in understanding this, please read Programming in Lua.

Startup

Mods are loaded during server startup from the mod load paths by running the init.lua scripts in a shared environment.

Paths

Minetest keeps and looks for files mostly in two paths. path_share or path_user.

path_share contains possibly read-only content for the engine (incl. games and mods). path_user contains mods or games installed by the user but also the users worlds or settings.

With a local build (RUN_IN_PLACE=1) path_share and path_user both point to the build directory. For system-wide builds on Linux the share path is usually at /usr/share/minetest while the user path resides in .minetest in the home directory. Paths on other operating systems will differ.

Games

Games are looked up from:

Where <gameid> is unique to each game.

The game directory can contain the following files:

Games can provide custom main menu images. They are put inside a menu directory inside the game directory.

The images are named $identifier.png, where $identifier is one of overlay, background, footer, header. If you want to specify multiple images for one identifier, add additional images named like $identifier.$n.png, with an ascending number $n starting with 1, and a random image will be chosen from the provided ones.

Games can provide custom main menu music. They are put inside a menu directory inside the game directory.

The music files are named theme.ogg. If you want to specify multiple music files for one game, add additional images named like theme.$n.ogg, with an ascending number $n starting with 1 (max 10), and a random music file will be chosen from the provided ones.

Mods

Mod load path

Paths are relative to the directories listed in the [Paths] section above.

World-specific games

It is possible to include a game in a world; in this case, no mods or games are loaded or checked from anywhere else.

This is useful for e.g. adventure worlds and happens if the <worldname>/game/ directory exists.

Mods should then be placed in <worldname>/game/mods/.

Modpacks

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.

Note: to support 0.4.x, please also create an empty modpack.txt file.

Mod directory structure

mods
├── modname
│   ├── mod.conf
│   ├── screenshot.png
│   ├── settingtypes.txt
│   ├── init.lua
│   ├── models
│   ├── textures
│   │   ├── modname_stuff.png
│   │   ├── modname_stuff_normal.png
│   │   ├── modname_something_else.png
│   │   ├── subfolder_foo
│   │   │   ├── modname_more_stuff.png
│   │   │   └── another_subfolder
│   │   └── bar_subfolder
│   ├── sounds
│   ├── media
│   ├── locale
│   └── <custom data>
└── another

modname

The location of this directory can be fetched by using minetest.get_modpath(modname).

mod.conf

A Settings file that provides meta information about the mod.

screenshot.png

A screenshot shown in the mod manager within the main menu. It should have an aspect ratio of 3:2 and a minimum size of 300×200 pixels.

depends.txt

Deprecated: you should use mod.conf instead.

This file is used if there are no dependencies in mod.conf.

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. This means that if the specified mod is missing, it does not prevent this mod from being loaded.

description.txt

Deprecated: you should use mod.conf instead.

This file is used if there is no description in mod.conf.

A file containing a description to be shown in the Mods tab of the main menu.

settingtypes.txt

The format is documented in builtin/settingtypes.txt. It is parsed by the main menu settings dialogue to list mod-specific settings in the "Mods" category.

minetest.settings can be used to read custom or engine settings. See [Settings].

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.

textures, sounds, media, models, locale

Media files (textures, sounds, whatever) that will be transferred to the client and will be available for use by the mod and translation files for the clients (see [Translations]). Accepted characters for names are:

a-zA-Z0-9_.-

Accepted formats are:

images: .png, .jpg, .tga, (deprecated:) .bmp
sounds: .ogg vorbis
models: .x, .b3d, .obj, .gltf (Minetest 5.10 or newer)

Other formats won't be sent to the client (e.g. you can store .blend files in a folder for convenience, without the risk that such files are transferred)

It is suggested to use the folders for the purpose they are thought for, eg. put textures into textures, translation files into locale, models for entities or meshnodes into models et cetera.

These folders and subfolders can contain subfolders. Subfolders with names starting with _ or . are ignored. If a subfolder contains a media file with the same name as a media file in one of its parents, the parent's file is used.

Although it is discouraged, a mod can overwrite a media file of any mod that it depends on by supplying a file with an equal name.

Only a subset of model file format features is supported:

Simple textured meshes (with multiple textures), optionally with normals. The .x and .b3d formats additionally support skeletal animation.

glTF

The glTF model file format for now only serves as a more modern alternative to the other static model file formats; it unlocks no special rendering features.

This means that many glTF features are not supported yet, including:

Textures are supplied solely via the same means as for the other model file formats: The textures object property, the tiles node definition field and the list of textures used in the model[] formspec element.

The order in which textures are to be supplied is that in which they appear in the textures array in the glTF file.

Do not rely on glTF features not being supported; they may be supported in the future. The backwards compatibility guarantee does not extend to ignoring unsupported features.

For example, if your model used an emissive material, you should expect that a future version of Minetest may respect this, and thus cause your model to render differently there.

Naming conventions

Registered names should generally be in this format:

modname:<whatever>

<whatever> can have these characters:

a-zA-Z0-9_

This is to prevent conflicting names from corrupting maps and is enforced by the mod loader.

Registered names can be overridden by prefixing the name with :. This can be used for overriding the registrations of some other mod.

The : prefix can also be used for maintaining backwards compatibility.

Example

In the mod experimental, there is the ideal item/node/entity name tnt. So the name should be experimental:tnt.

Any mod can redefine experimental:tnt by using the name

:experimental:tnt

when registering it. For this to work correctly, that mod must have experimental as a dependency.

Aliases

Aliases of itemnames can be added by using minetest.register_alias(alias, original_name) or minetest.register_alias_force(alias, original_name).

This adds an alias alias for the item called original_name. From now on, you can use alias to refer to the item original_name.

The only difference between minetest.register_alias and minetest.register_alias_force is that if an item named alias already exists, minetest.register_alias will do nothing while minetest.register_alias_force will unregister it.

This can be used for maintaining backwards compatibility.

This can also set quick access names for things, e.g. if you have an item called epiclylongmodname:stuff, you could do

minetest.register_alias("stuff", "epiclylongmodname:stuff")

and be able to use /giveme stuff.

Mapgen aliases

In a game, a certain number of these must be set to tell core mapgens which of the game's nodes are to be used for core mapgen generation. For example:

minetest.register_alias("mapgen_stone", "default:stone")

Aliases for non-V6 mapgens

Essential aliases

mapgen_river_water_source is required for mapgens with sloping rivers where it is necessary to have a river liquid node with a short liquid_range and liquid_renewable = false to avoid flooding.

Optional aliases

Fallback lava node used if cave liquids are not defined in biome definitions. Deprecated, define cave liquids in biome definitions instead.

Fallback node used if dungeon nodes are not defined in biome definitions. Deprecated, define dungeon nodes in biome definitions instead.

Aliases for Mapgen V6

Essential

Optional

Setting the node used in Mapgen Singlenode

By default the world is filled with air nodes. To set a different node use e.g.:

minetest.register_alias("mapgen_singlenode", "default:stone")

Textures

Mods should generally prefix their textures with modname_, e.g. given the mod name foomod, a texture could be called:

foomod_foothing.png

Textures are referred to by their complete name, or alternatively by stripping out the file extension:

Supported texture formats are PNG (.png), JPEG (.jpg), Bitmap (.bmp) and Targa (.tga). Since better alternatives exist, the latter two may be removed in the future.

Texture modifiers

There are various texture modifiers that can be used to let the client generate textures on-the-fly. The modifiers are applied directly in sRGB colorspace, i.e. without gamma-correction.

Texture overlaying

Textures can be overlaid by putting a ^ between them.

Warning: If the lower and upper pixels are both semi-transparent, this operation does not do alpha blending, and it is not associative. Otherwise it does alpha blending in srgb color space.

Example:

default_dirt.png^default_grass_side.png

default_grass_side.png is overlaid over default_dirt.png. The texture with the lower resolution will be automatically upscaled to the higher resolution texture.

Texture grouping

Textures can be grouped together by enclosing them in ( and ).

Example: cobble.png^(thing1.png^thing2.png)

A texture for thing1.png^thing2.png is created and the resulting texture is overlaid on top of cobble.png.

Escaping

Modifiers that accept texture names (e.g. [combine) accept escaping to allow passing complex texture names as arguments. Escaping is done with backslash and is required for ^, : and \.

Example: cobble.png^[lowpart:50:color.png\^[mask\:trans.png Or as a Lua string: "cobble.png^[lowpart:50:color.png\\^[mask\\:trans.png"

The lower 50 percent of color.png^[mask:trans.png are overlaid on top of cobble.png.

Advanced texture modifiers

Crack

Parameters:

Draw a step of the crack animation on the texture. crack draws it normally, while cracko lays it over, keeping transparent pixels intact.

Example:

default_cobble.png^[crack:10:1

[combine:<w>x<h>:<x1>,<y1>=<file1>:<x2>,<y2>=<file2>:...

Creates a texture of size <w> times <h> and blits the listed files to their specified coordinates.

Example:

[combine:16x32:0,0=default_cobble.png:0,16=default_wood.png

[resize:<w>x<h>

Resizes the texture to the given dimensions.

Example:

default_sandstone.png^[resize:16x16

[opacity:<r>

Makes the base image transparent according to the given ratio.

r must be between 0 (transparent) and 255 (opaque).

Example:

default_sandstone.png^[opacity:127

[invert:<mode>

Inverts the given channels of the base image. Mode may contain the characters "r", "g", "b", "a". Only the channels that are mentioned in the mode string will be inverted.

Example:

default_apple.png^[invert:rgb

[brighten

Brightens the texture.

Example:

tnt_tnt_side.png^[brighten

[noalpha

Makes the texture completely opaque.

Example:

default_leaves.png^[noalpha

[makealpha:<r>,<g>,<b>

Convert one color to transparency.

Example:

default_cobble.png^[makealpha:128,128,128

[transform<t>

Rotates and/or flips the image.

<t> can be a number (between 0 and 7) or a transform name. Rotations are counter-clockwise.

0  I      identity
1  R90    rotate by 90 degrees
2  R180   rotate by 180 degrees
3  R270   rotate by 270 degrees
4  FX     flip X
5  FXR90  flip X then rotate by 90 degrees
6  FY     flip Y
7  FYR90  flip Y then rotate by 90 degrees

Example:

default_stone.png^[transformFXR90

[inventorycube{<top>{<left>{<right>

Escaping does not apply here and ^ is replaced by & in texture names instead.

Create an inventory cube texture using the side textures.

Example:

[inventorycube{grass.png{dirt.png&grass_side.png{dirt.png&grass_side.png

Creates an inventorycube with grass.png, dirt.png^grass_side.png and dirt.png^grass_side.png textures

[fill:<w>x<h>:<x>,<y>:<color>

Creates a texture of the given size and color, optionally with an <x>,<y> position. An alpha value may be specified in the Colorstring.

The optional <x>,<y> position is only used if the [fill is being overlaid onto another texture with '^'.

When [fill is overlaid onto another texture it will not upscale or change the resolution of the texture, the base texture will determine the output resolution.

Examples:

[fill:16x16:#20F02080
texture.png^[fill:8x8:4,4:red

[lowpart:<percent>:<file>

Blit the lower <percent>% part of <file> on the texture.

Example:

base.png^[lowpart:25:overlay.png

[verticalframe:<t>:<n>

Crops the texture to a frame of a vertical animation.

Example:

default_torch_animated.png^[verticalframe:16:8

[mask:<file>

Apply a mask to the base image.

The mask is applied using binary AND.

[sheet:<w>x<h>:<x>,<y>

Retrieves a tile at position x, y (in tiles, 0-indexed) from the base image, which it assumes to be a tilesheet with dimensions w, h (in tiles).

[colorize:<color>:<ratio>

Colorize the textures with the given color. <color> is specified as a ColorString. <ratio> is an int ranging from 0 to 255 or the word "alpha". If it is an int, then it specifies how far to interpolate between the colors where 0 is only the texture color and 255 is only <color>. If omitted, the alpha of <color> will be used as the ratio. If it is the word "alpha", then each texture pixel will contain the RGB of <color> and the alpha of <color> multiplied by the alpha of the texture pixel.

[colorizehsl:<hue>:<saturation>:<lightness>

Colorize the texture to the given hue. The texture will be converted into a greyscale image as seen through a colored glass, like "Colorize" in GIMP. Saturation and lightness can optionally be adjusted.

<hue> should be from -180 to +180. The hue at 0° on an HSL color wheel is red, 60° is yellow, 120° is green, and 180° is cyan, while -60° is magenta and -120° is blue.

<saturation> and <lightness> are optional adjustments.

<lightness> is from -100 to +100, with a default of 0

<saturation> is from 0 to 100, with a default of 50

[multiply:<color>

Multiplies texture colors with the given color. <color> is specified as a ColorString. Result is more like what you'd expect if you put a color on top of another color, meaning white surfaces get a lot of your new color while black parts don't change very much.

A Multiply blend can be applied between two textures by using the overlay modifier with a brightness adjustment:

textureA.png^[contrast:0:-64^[overlay:textureB.png

[screen:<color>

Apply a Screen blend with the given color. A Screen blend is the inverse of a Multiply blend, lightening images instead of darkening them.

<color> is specified as a ColorString.

A Screen blend can be applied between two textures by using the overlay modifier with a brightness adjustment:

textureA.png^[contrast:0:64^[overlay:textureB.png

[hsl:<hue>:<saturation>:<lightness>

Adjust the hue, saturation, and lightness of the texture. Like "Hue-Saturation" in GIMP, but with 0 as the mid-point.

<hue> should be from -180 to +180

<saturation> and <lightness> are optional, and both percentages.

<lightness> is from -100 to +100.

<saturation> goes down to -100 (fully desaturated) but may go above 100, allowing for even muted colors to become highly saturated.

[contrast:<contrast>:<brightness>

Adjust the brightness and contrast of the texture. Conceptually like GIMP's "Brightness-Contrast" feature but allows brightness to be wound all the way up to white or down to black.

<contrast> is a value from -127 to +127.

<brightness> is an optional value, from -127 to +127.

If only a boost in contrast is required, an alternative technique is to hardlight blend the texture with itself, this increases contrast in the same way as an S-shaped color-curve, which avoids dark colors clipping to black and light colors clipping to white:

texture.png^[hardlight:texture.png

[overlay:<file>

Applies an Overlay blend with the two textures, like the Overlay layer mode in GIMP. Overlay is the same as Hard light but with the role of the two textures swapped, see the [hardlight modifier description for more detail about these blend modes.

[hardlight:<file>

Applies a Hard light blend with the two textures, like the Hard light layer mode in GIMP.

Hard light combines Multiply and Screen blend modes. Light parts of the <file> texture will lighten (screen) the base texture, and dark parts of the <file> texture will darken (multiply) the base texture. This can be useful for applying embossing or chiselled effects to textures. A Hard light with the same texture acts like applying an S-shaped color-curve, and can be used to increase contrast without clipping.

Hard light is the same as Overlay but with the roles of the two textures swapped, i.e. A.png^[hardlight:B.png is the same as B.png^[overlay:A.png

[png:<base64>

Embed a base64 encoded PNG image in the texture string. You can produce a valid string for this by calling minetest.encode_base64(minetest.encode_png(tex)), where tex is pixel data. Refer to the documentation of these functions for details. You can use this to send disposable images such as captchas to individual clients, or render things that would be too expensive to compose with [combine:.

IMPORTANT: Avoid sending large images this way. This is not a replacement for asset files, do not use it to do anything that you could instead achieve by just using a file. In particular consider minetest.dynamic_add_media and test whether using other texture modifiers could result in a shorter string than embedding a whole image, this may vary by use case.

Hardware coloring

The goal of hardware coloring is to simplify the creation of colorful nodes. If your textures use the same pattern, and they only differ in their color (like colored wool blocks), you can use hardware coloring instead of creating and managing many texture files. All of these methods use color multiplication (so a white-black texture with red coloring will result in red-black color).

Static coloring

This method is useful if you wish to create nodes/items with the same texture, in different colors, each in a new node/item definition.

Global color

When you register an item or node, set its color field (which accepts a ColorSpec) to the desired color.

An ItemStack's static color can be overwritten by the color metadata field. If you set that field to a ColorString, that color will be used.

Tile color

Each tile may have an individual static color, which overwrites every other coloring method. To disable the coloring of a face, set its color to white (because multiplying with white does nothing). You can set the color property of the tiles in the node's definition if the tile is in table format.

Palettes

For nodes and items which can have many colors, a palette is more suitable. A palette is a texture, which can contain up to 256 pixels. Each pixel is one possible color for the node/item. You can register one node/item, which can have up to 256 colors.

Palette indexing

When using palettes, you always provide a pixel index for the given node or ItemStack. The palette is read from left to right and from top to bottom. If the palette has less than 256 pixels, then it is stretched to contain exactly 256 pixels (after arranging the pixels to one line). The indexing starts from 0.

Examples:

Using palettes with items

When registering an item, set the item definition's palette field to a texture. You can also use texture modifiers.

The ItemStack's color depends on the palette_index field of the stack's metadata. palette_index is an integer, which specifies the index of the pixel to use.

Linking palettes with nodes

When registering a node, set the item definition's palette field to a texture. You can also use texture modifiers. The node's color depends on its param2, so you also must set an appropriate paramtype2:

To colorize a node on the map, set its param2 value (according to the node's paramtype2).

Conversion between nodes in the inventory and on the map

Static coloring is the same for both cases, there is no need for conversion.

If the ItemStack's metadata contains the color field, it will be lost on placement, because nodes on the map can only use palettes.

If the ItemStack's metadata contains the palette_index field, it is automatically transferred between node and item forms by the engine, when a player digs or places a colored node. You can disable this feature by setting the drop field of the node to itself (without metadata). To transfer the color to a special drop, you need a drop table.

Example:

lua minetest.register_node("mod:stone", { description = "Stone", tiles = {"default_stone.png"}, paramtype2 = "color", palette = "palette.png", drop = { items = { -- assume that mod:cobblestone also has the same palette {items = {"mod:cobblestone"}, inherit_color = true }, } } })

Colored items in craft recipes

Craft recipes only support item strings, but fortunately item strings can also contain metadata. Example craft recipe registration:

lua minetest.register_craft({ output = minetest.itemstring_with_palette("wool:block", 3), type = "shapeless", recipe = { "wool:block", "dye:red", }, })

To set the color field, you can use minetest.itemstring_with_color.

Metadata field filtering in the recipe field are not supported yet, so the craft output is independent of the color of the ingredients.

Soft texture overlay

Sometimes hardware coloring is not enough, because it affects the whole tile. Soft texture overlays were added to Minetest to allow the dynamic coloring of only specific parts of the node's texture. For example a grass block may have colored grass, while keeping the dirt brown.

These overlays are 'soft', because unlike texture modifiers, the layers are not merged in the memory, but they are simply drawn on top of each other. This allows different hardware coloring, but also means that tiles with overlays are drawn slower. Using too much overlays might cause FPS loss.

For inventory and wield images you can specify overlays which hardware coloring does not modify. You have to set inventory_overlay and wield_overlay fields to an image name.

To define a node overlay, simply set the overlay_tiles field of the node definition. These tiles are defined in the same way as plain tiles: they can have a texture name, color etc. To skip one face, set that overlay tile to an empty string.

Example (colored grass block):

lua minetest.register_node("default:dirt_with_grass", { description = "Dirt with Grass", -- Regular tiles, as usual -- The dirt tile disables palette coloring tiles = {{name = "default_grass.png"}, {name = "default_dirt.png", color = "white"}}, -- Overlay tiles: define them in the same style -- The top and bottom tile does not have overlay overlay_tiles = {"", "", {name = "default_grass_side.png"}}, -- Global color, used in inventory color = "green", -- Palette in the world paramtype2 = "color", palette = "default_foilage.png", })

Sounds

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 sound files with modname_, e.g. given the mod name "foomod", a sound could be called:

foomod_foosound.ogg

Sound group

A sound group is the set of all sound files, whose filenames are of the following format: <sound-group name>[.<single digit>].ogg When a sound-group is played, one the files in the group is chosen at random. Sound files can only be referred to by their sound-group name.

Example: When playing the sound foomod_foosound, the sound is chosen randomly from the available ones of the following files:

SimpleSoundSpec

Specifies a sound name, gain (=volume), pitch and fade. This is either a string or a table.

In string form, you just specify the sound name or the empty string for no sound.

Table form has the following fields:

gain, pitch and fade are optional and default to 1.0, 1.0 and 0.0.

Examples:

Sound parameter table

Table used to specify how a sound is played:

``lua { gain = 1.0, -- Scales the gain specified inSimpleSoundSpec`.

pitch = 1.0,
-- Overwrites the pitch specified in `SimpleSoundSpec`.

fade = 0.0,
-- Overwrites the fade specified in `SimpleSoundSpec`.

start_time = 0.0,
-- Start with a time-offset into the sound.
-- The behavior is as if the sound was already playing for this many seconds.
-- Negative values are relative to the sound's length, so the sound reaches
-- its end in `-start_time` seconds.
-- It is unspecified what happens if `loop` is false and `start_time` is
-- smaller than minus the sound's length.
-- Available since feature `sound_params_start_time`.

loop = false,
-- If true, sound is played in a loop.

pos = {x = 1, y = 2, z = 3},
-- Play sound at a position.
-- Can't be used together with `object`.

object = <an ObjectRef>,
-- Attach the sound to an object.
-- Can't be used together with `pos`.

to_player = name,
-- Only play for this player.
-- Can't be used together with `exclude_player`.

exclude_player = name,
-- Don't play sound for this player.
-- Can't be used together with `to_player`.

max_hear_distance = 32,
-- Only play for players that are at most this far away when the sound
-- starts playing.
-- Needs `pos` or `object` to be set.
-- `32` is the default.

} ```

Examples:

lua -- Play locationless on all clients { gain = 1.0, -- default fade = 0.0, -- default pitch = 1.0, -- default } -- Play locationless to one player { to_player = name, gain = 1.0, -- default fade = 0.0, -- default pitch = 1.0, -- default } -- Play locationless to one player, looped { to_player = name, gain = 1.0, -- default loop = true, } -- Play at a location, start the sound at offset 5 seconds { pos = {x = 1, y = 2, z = 3}, gain = 1.0, -- default max_hear_distance = 32, -- default start_time = 5.0, } -- Play connected to an object, looped { object = <an ObjectRef>, gain = 1.0, -- default max_hear_distance = 32, -- default loop = true, } -- Play at a location, heard by anyone *but* the given player { pos = {x = 32, y = 0, z = 100}, max_hear_distance = 40, exclude_player = name, }

Special sound-groups

These sound-groups are played back by the engine if provided.

Registered definitions

Anything added using certain [Registration functions] gets added to one or more of the global [Registered definition tables].

Note that in some cases you will stumble upon things that are not contained in these tables (e.g. when a mod has been removed). Always check for existence before trying to access the fields.

Example:

All nodes registered with minetest.register_node get added to the table minetest.registered_nodes.

If you want to check the drawtype of a node, you could do it like this:

lua local def = minetest.registered_nodes[nodename] local drawtype = def and def.drawtype

Nodes

Nodes are the bulk data of the world: cubes and other things that take the space of a cube. Huge amounts of them are handled efficiently, but they are quite static.

The definition of a node is stored and can be accessed by using

lua minetest.registered_nodes[node.name]

See [Registered definitions].

Nodes are passed by value between Lua and the engine. They are represented by a table:

lua {name="name", param1=num, param2=num}

param1 and param2 are 8-bit integers ranging from 0 to 255. The engine uses them for certain automated functions. If you don't use these functions, you can use them to store arbitrary values.

Node paramtypes

The functions of param1 and param2 are determined by certain fields in the node definition.

The function of param1 is determined by paramtype in node definition. param1 is reserved for the engine when paramtype != "none".

The function of param2 is determined by paramtype2 in node definition. param2 is reserved for the engine when paramtype2 != "none".

Nodes can also contain extra data. See [Node Metadata].

Node drawtypes

There are a bunch of different looking node types.

Look for examples in games/devtest or games/minetest_game.

*_optional drawtypes need less rendering time if deactivated (always client-side).

Node boxes

Node selection boxes are defined using "node boxes".

A nodebox is defined as any of:

lua { -- A normal cube; the default in most things type = "regular" } { -- A fixed box (or boxes) (facedir param2 is used, if applicable) type = "fixed", fixed = box OR {box1, box2, ...} } { -- A variable height box (or boxes) with the top face position defined -- by the node parameter 'leveled = ', or if 'paramtype2 == "leveled"' -- by param2. -- Other faces are defined by 'fixed = {}' as with 'type = "fixed"'. type = "leveled", fixed = box OR {box1, box2, ...} } { -- A box like the selection box for torches -- (wallmounted param2 is used, if applicable) type = "wallmounted", wall_top = box, wall_bottom = box, wall_side = box } { -- A node that has optional boxes depending on neighboring nodes' -- presence and type. See also `connects_to`. type = "connected", fixed = box OR {box1, box2, ...} connect_top = box OR {box1, box2, ...} connect_bottom = box OR {box1, box2, ...} connect_front = box OR {box1, box2, ...} connect_left = box OR {box1, box2, ...} connect_back = box OR {box1, box2, ...} connect_right = box OR {box1, box2, ...} -- The following `disconnected_*` boxes are the opposites of the -- `connect_*` ones above, i.e. when a node has no suitable neighbor -- on the respective side, the corresponding disconnected box is drawn. disconnected_top = box OR {box1, box2, ...} disconnected_bottom = box OR {box1, box2, ...} disconnected_front = box OR {box1, box2, ...} disconnected_left = box OR {box1, box2, ...} disconnected_back = box OR {box1, box2, ...} disconnected_right = box OR {box1, box2, ...} disconnected = box OR {box1, box2, ...} -- when there is *no* neighbor disconnected_sides = box OR {box1, box2, ...} -- when there are *no* -- neighbors to the sides }

A box is defined as:

lua {x1, y1, z1, x2, y2, z2}

A box of a regular node would look like:

lua {-0.5, -0.5, -0.5, 0.5, 0.5, 0.5},

To avoid collision issues, keep each value within the range of +/- 1.45. This also applies to leveled nodeboxes, where the final height shall not exceed this soft limit.

Map terminology and coordinates

Nodes, mapblocks, mapchunks

A 'node' is the fundamental cubic unit of a world and appears to a player as roughly 1x1x1 meters in size.

A 'mapblock' (often abbreviated to 'block') is 16x16x16 nodes and is the fundamental region of a world that is stored in the world database, sent to clients and handled by many parts of the engine. 'mapblock' is preferred terminology to 'block' to help avoid confusion with 'node', however 'block' often appears in the API.

A 'mapchunk' (sometimes abbreviated to 'chunk') is usually 5x5x5 mapblocks (80x80x80 nodes) and is the volume of world generated in one operation by the map generator. The size in mapblocks has been chosen to optimize map generation.

Coordinates

Orientation of axes

For node and mapblock coordinates, +X is East, +Y is up, +Z is North.

Node coordinates

Almost all positions used in the API use node coordinates.

Mapblock coordinates

Occasionally the API uses 'blockpos' which refers to mapblock coordinates that specify a particular mapblock. For example blockpos (0,0,0) specifies the mapblock that extends from node position (0,0,0) to node position (15,15,15).

Converting node position to the containing blockpos

To calculate the blockpos of the mapblock that contains the node at 'nodepos', for each axis:

Converting blockpos to min/max node positions

To calculate the min/max node positions contained in the mapblock at 'blockpos', for each axis:

HUD

HUD element types

The position field is used for all element types. To account for differing resolutions, the position coordinates are the percentage of the screen, ranging in value from 0 to 1.

The name field is not yet used, but should contain a description of what the HUD element represents.

The direction field is the direction in which something is drawn. 0 draws from left to right, 1 draws from right to left, 2 draws from top to bottom, and 3 draws from bottom to top.

The alignment field specifies how the item will be aligned. It is a table where x and y range from -1 to 1, with 0 being central. -1 is moved to the left/up, and 1 is to the right/down. Fractional values can be used.

The offset field specifies a pixel offset from the position. Contrary to position, the offset is not scaled to screen size. This allows for some precisely positioned items in the HUD.

Note: offset will adapt to screen DPI as well as user defined scaling factor!

The z_index field specifies the order of HUD elements from back to front. Lower z-index elements are displayed behind higher z-index elements. Elements with same z-index are displayed in an arbitrary order. Default 0. Supports negative values. By convention, the following values are recommended:

If your HUD element doesn't fit into any category, pick a number between the suggested values

Below are the specific uses for fields in each type; fields not listed for that type are ignored.

image

Displays an image on the HUD.

text

Displays text on the HUD.

statbar

Displays a horizontal bar made up of half-images with an optional background.

inventory hotbar waypoint

Displays distance to selected world position.

image_waypoint

Same as image, but does not accept a position; the position is instead determined by world_pos, the world position of the waypoint.

compass

Displays an image oriented or translated according to current heading direction.

If translation is chosen, texture is repeated horizontally to fill the whole element.

minimap

Displays a minimap on the HUD.

Representations of simple things

Vector (ie. a position)

lua vector.new(x, y, z)

See [Spatial Vectors] for details.

pointed_thing

Exact pointing location (currently only Raycast supports these fields):

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

lua {place_center_x = true, place_center_y=false, place_center_z=true}

is equivalent to

lua {place_center_x = true, noplace_center_y=true, place_center_z=true}

which is equivalent to

lua "place_center_x, noplace_center_y, place_center_z"

or even

lua "place_center_x, place_center_z"

since, by default, no schematic attributes are set.

Items

Items are things that can be held by players, dropped in the map and stored in inventories. Items come in the form of item stacks, which are collections of equal items that occupy a single inventory slot.

Item types

There are three kinds of items: nodes, tools and craftitems.

Every registered node (the voxel in the world) has a corresponding item form (the thing in your inventory) that comes along with it. This item form can be placed which will create a node in the world (by default). Both the 'actual' node and its item form share the same identifier. For all practical purposes, you can treat the node and its item form interchangeably. We usually just say 'node' to the item form of the node as well.

Note the definition of tools is purely technical. The only really unique thing about tools is their wear, and that's basically it. Beyond that, you can't make any gameplay-relevant assumptions about tools or non-tools. It is perfectly valid to register something that acts as tool in a gameplay sense as a craftitem, and vice-versa.

Craftitems can be used for items that neither need to be a node nor a tool.

Amount and wear

All item stacks have an amount between 0 and 65535. It is 1 by default. Tool item stacks cannot have an amount greater than 1.

Tools use a wear (damage) value ranging from 0 to 65535. The value 0 is the default and is used for unworn tools. The values 1 to 65535 are used for worn tools, where a higher value stands for a higher wear. Non-tools technically also have a wear property, but it is always 0. There is also a special 'toolrepair' crafting recipe that is only available to tools.

Item formats

Items and item stacks can exist in three formats: Serializes, table format and ItemStack.

When an item must be passed to a function, it can usually be in any of these formats.

Serialized

This is called "stackstring" or "itemstring". It is a simple string with 1-4 components:

  1. Full item identifier ("item name")
  2. Optional amount
  3. Optional wear value
  4. Optional item metadata

Syntax:

<identifier> [<amount>[ <wear>[ <metadata>]]]

Examples:

You should ideally use the ItemStack format to build complex item strings (especially if they use item metadata) without relying on the serialization format. Example:

local stack = ItemStack("default:pick_wood")
stack:set_wear(21323)
stack:get_meta():set_string("description", "My worn out pick")
local itemstring = stack:to_string()

Additionally the methods minetest.itemstring_with_palette(item, palette_index) and minetest.itemstring_with_color(item, colorstring) may be used to create item strings encoding color information in their metadata.

Table format

Examples:

5 dirt nodes:

lua {name="default:dirt", count=5, wear=0, metadata=""}

A wooden pick about 1/3 worn out:

lua {name="default:pick_wood", count=1, wear=21323, metadata=""}

An apple:

lua {name="default:apple", count=1, wear=0, metadata=""}

ItemStack

A native C++ format with many helper methods. Useful for converting between formats. See the [Class reference] section for details.

Groups

In a number of places, there is a group table. Groups define the properties of a thing (item, node, armor of entity, tool capabilities) in such a way that the engine and other mods can can interact with the thing without actually knowing what the thing is.

Usage

Groups are stored in a table, having the group names with keys and the group ratings as values. Group ratings are integer values within the range [-32767, 32767]. For example:

```lua -- Default dirt groups = {crumbly=3, soil=1}

-- A more special dirt-kind of thing groups = {crumbly=2, soil=1, level=2, outerspace=1} ```

Groups always have a rating associated with them. If there is no useful meaning for a rating for an enabled group, it shall be 1.

When not defined, the rating of a group defaults to 0. Thus when you read groups, you must interpret nil and 0 as the same value, 0.

You can read the rating of a group for an item or a node by using

lua minetest.get_item_group(itemname, groupname)

Groups of items

Groups of items can define what kind of an item it is (e.g. wool).

Groups of nodes

In addition to the general item things, groups are used to define whether a node is destroyable and how long it takes to destroy by a tool.

Groups of entities

For entities, groups are, as of now, used only for calculating damage. The rating is the percentage of damage caused by items with this damage group. See [Entity damage mechanism].

lua object:get_armor_groups() --> a group-rating table (e.g. {fleshy=100}) object:set_armor_groups({fleshy=30, cracky=80})

Groups of tool capabilities

Groups in tool capabilities define which groups of nodes and entities they are effective towards.

Groups in crafting recipes

In crafting recipes, you can specify a group as an input item. This means that any item in that group will be accepted as input.

The basic syntax is:

lua "group:<group_name>"

For example, "group:meat" will accept any item in the meat group.

It is also possible to require an input item to be in multiple groups at once. The syntax for that is:

lua "group:<group_name_1>,<group_name_2>,(...),<group_name_n>"

For example, "group:leaves,birch,trimmed" accepts any item which is member of all the groups leaves and birch and trimmed.

An example recipe: Craft a raw meat soup from any meat, any water and any bowl:

lua { output = "food:meat_soup_raw", recipe = { {"group:meat"}, {"group:water"}, {"group:bowl"}, }, }

Another example: Craft red wool from white wool and red dye (here, "red dye" is defined as any item which is member of both the groups dye and basecolor_red).

lua { type = "shapeless", output = "wool:red", recipe = {"wool:white", "group:dye,basecolor_red"}, }

Special groups

The asterisk (*) after a group name describes that there is no engine functionality bound to it, and implementation is left up as a suggestion to games.

Node and item groups

Node-only groups

  • falling_node: if there is no walkable block under the node it will fall
  • float: the node will not fall through liquids (liquidtype ~= "none")

    • A liquid source with groups = {falling_node = 1, float = 1} will fall through flowing liquids.

  • level: Can be used to give an additional sense of progression in the game.

    • A larger level will cause e.g. a weapon of a lower level make much less damage, and get worn out much faster, or not be able to get drops from destroyed nodes.
    • 0 is something that is directly accessible at the start of gameplay
    • There is no upper limit
    • See also: leveldiff in [Tool Capabilities]

  • slippery: Players and items will slide on the node. Slipperiness rises steadily with slippery value, starting at 1.

    • Tool-only groups

    ObjectRef armor groups

    Known damage and digging time defining groups

    Examples of custom groups

    Item groups are often used for defining, well, groups of items.

    Digging time calculation specifics

    Groups such as crumbly, cracky and snappy are used for this purpose. Rating is 1, 2 or 3. A higher rating for such a group implies faster digging time.

    The level group is used to limit the toughness of nodes an item capable of digging can dig and to scale the digging times / damage to a greater extent.

    Please do understand this, otherwise you cannot use the system to it's full potential.

    Items define their properties by a list of parameters for groups. They cannot dig other groups; thus it is important to use a standard bunch of groups to enable interaction with items.

    Tool Capabilities

    'Tool capabilities' is a property of items that defines two things:

    1) Which nodes it can dig and how fast 2) Which objects it can hurt by punching and by how much

    Tool capabilities are available for all items, not just tools. But only tools can receive wear from digging and punching.

    Missing or incomplete tool capabilities will default to the player's hand.

    Tool capabilities definition

    Tool capabilities define:

    Full punch interval full_punch_interval

    When used as a weapon, the item will do full damage if this time is spent between punches. If e.g. half the time is spent, the item will do half damage.

    Maximum drop level max_drop_level

    Suggests the maximum level of node, when dug with the item, that will drop its useful item. (e.g. iron ore to drop a lump of iron).

    This value is not used in the engine; it is the responsibility of the game/mod code to implement this.

    Uses uses (tools only)

    Determines how many uses the tool has when it is used for digging a node, of this group, of the maximum level. The maximum supported number of uses is 65535. The special number 0 is used for infinite uses. For lower leveled nodes, the use count is multiplied by 3^leveldiff. leveldiff is the difference of the tool's maxlevel groupcaps and the node's level group. The node cannot be dug if leveldiff is less than zero.

    For non-tools, this has no effect.

    Maximum level maxlevel

    Tells what is the maximum level of a node of this group that the item will be able to dig.

    Digging times times

    List of digging times for different ratings of the group, for nodes of the maximum level.

    For example, as a Lua table, times={[2]=2.00, [3]=0.70}. This would result in the item to be able to dig nodes that have a rating of 2 or 3 for this group, and unable to dig the rating 1, which is the toughest. Unless there is a matching group that enables digging otherwise.

    If the result digging time is 0, a delay of 0.15 seconds is added between digging nodes. If the player releases LMB after digging, this delay is set to 0, i.e. players can more quickly click the nodes away instead of holding LMB.

    This extra delay is not applied in case of a digging time between 0 and 0.15, so a digging time of 0.01 is actually faster than a digging time of 0.

    Damage groups

    List of damage for groups of entities. See [Entity damage mechanism].

    Punch attack uses (tools only)

    Determines how many uses (before breaking) the tool has when dealing damage to an object, when the full punch interval (see above) was always waited out fully.

    Wear received by the tool is proportional to the time spent, scaled by the full punch interval.

    For non-tools, this has no effect.

    Example definition of the capabilities of an item

    lua tool_capabilities = { groupcaps={ crumbly={maxlevel=2, uses=20, times={[1]=1.60, [2]=1.20, [3]=0.80}} }, }

    This makes the item capable of digging nodes that fulfill both of these:

    Table of resulting digging times:

    crumbly        0     1     2     3     4  <- level
     ->  0     -     -     -     -     -
         1  0.80  1.60  1.60     -     -
         2  0.60  1.20  1.20     -     -
         3  0.40  0.80  0.80     -     -

level diff:    2     1     0    -1    -2

    Table of resulting tool uses:

    ->  0     -     -     -     -     -
    1   180    60    20     -     -
    2   180    60    20     -     -
    3   180    60    20     -     -

    Notes:

    Entity damage mechanism

    Damage calculation:

    damage = 0
foreach group in cap.damage_groups:
    damage += cap.damage_groups[group]
        * limit(actual_interval / cap.full_punch_interval, 0.0, 1.0)
        * (object.armor_groups[group] / 100.0)
        -- Where object.armor_groups[group] is 0 for inexistent values
return damage

    Client predicts damage based on damage groups. Because of this, it is able to give an immediate response when an entity is damaged or dies; the response is pre-defined somehow (e.g. by defining a sprite animation) (not implemented; TODO). Currently a smoke puff will appear when an entity dies.

    The group immortal completely disables normal damage.

    Entities can define a special armor group, which is punch_operable. This group disables the regular damage mechanism for players punching it by hand or a non-tool item, so that it can do something else than take damage.

    On the Lua side, every punch calls:

    lua entity:on_punch(puncher, time_from_last_punch, tool_capabilities, direction, damage)

    This should never be called directly, because damage is usually not handled by the entity itself.

    To punch an entity/object in Lua, call:

    lua object:punch(puncher, time_from_last_punch, tool_capabilities, direction)

    Metadata

    Node Metadata

    The instance of a node in the world normally only contains the three values mentioned in [Nodes]. However, it is possible to insert extra data into a node. It is called "node metadata"; See NodeMetaRef.

    Node metadata contains two things:

    Some of the values in the key-value store are handled specially:

    Example:

    ```lua local meta = minetest.get_meta(pos)

    -- Set node formspec and infotext meta:set_string("formspec", "size[8,9]".. "list[context;main;0,0;8,4;]".. "list[current_player;main;0,5;8,4;]") meta:set_string("infotext", "Chest");

    -- Set inventory list size of "main" list to 32 local inv = meta:get_inventory() inv:set_size("main", 32)

    -- Dump node metadata print(dump(meta:to_table()))

    -- Set node metadata from a metadata table meta:from_table({ inventory = { -- Set items of inventory in all 32 slots of the "main" list main = {[1] = "default:dirt", [2] = "", [3] = "", [4] = "", [5] = "", [6] = "", [7] = "", [8] = "", [9] = "", [10] = "", [11] = "", [12] = "", [13] = "", [14] = "default:cobble", [15] = "", [16] = "", [17] = "", [18] = "", [19] = "", [20] = "default:cobble", [21] = "", [22] = "", [23] = "", [24] = "", [25] = "", [26] = "", [27] = "", [28] = "", [29] = "", [30] = "", [31] = "", [32] = ""} }, -- metadata fields fields = { formspec = "size[8,9]list[context;main;0,0;8,4;]list[current_player;main;0,5;8,4;]", infotext = "Chest" } }) ```

    Item Metadata

    Item stacks can store metadata too. See [ItemStackMetaRef].

    Item metadata only contains a key-value store.

    Some of the values in the key-value store are handled specially:

    Example:

    lua local meta = stack:get_meta() meta:set_string("key", "value") print(dump(meta:to_table()))

    Example manipulations of "description" and expected output behaviors:

    ```lua print(ItemStack("default:pick_steel"):get_description()) --> Steel Pickaxe print(ItemStack("foobar"):get_description()) --> Unknown Item

    local stack = ItemStack("default:stone") stack:get_meta():set_string("description", "Custom description\nAnother line") print(stack:get_description()) --> Custom description\nAnother line print(stack:get_short_description()) --> Custom description

    stack:get_meta():set_string("short_description", "Short") print(stack:get_description()) --> Custom description\nAnother line print(stack:get_short_description()) --> Short

    print(ItemStack("mod:item_with_no_desc"):get_description()) --> mod:item_with_no_desc ```

    Formspec

    Formspec defines a menu. This supports inventories and some of the typical widgets like buttons, checkboxes, text input fields, etc. It is a string, with a somewhat strange format.

    A formspec is made out of formspec elements, which includes widgets like buttons but also can be used to set stuff like background color.

    Many formspec elements have a name, which is a unique identifier which is used when the server receives user input. You must not use the name "quit" for formspec elements.

    Spaces and newlines can be inserted between the blocks, as is used in the examples.

    Position and size units are inventory slots unless the new coordinate system is enabled. X and Y position the formspec element relative to the top left of the menu or container. W and H are its width and height values.

    If the new system is enabled, all elements have unified coordinates for all elements with no padding or spacing in between. This is highly recommended for new forms. See real_coordinates[<bool>] and Migrating to Real Coordinates.

    Inventories with a player:<name> inventory location are only sent to the player named <name>.

    When displaying text which can contain formspec code, e.g. text set by a player, use minetest.formspec_escape. For colored text you can use minetest.colorize.

    Since formspec version 3, elements drawn in the order they are defined. All background elements are drawn before all other elements.

    WARNING: do not use an element name starting with key_; those names are reserved to pass key press events to formspec!

    WARNING: names and values of elements cannot contain binary data such as ASCII control characters. For values, escape sequences used by the engine are an exception to this.

    WARNING: Minetest allows you to add elements to every single formspec instance using player:set_formspec_prepend(), which may be the reason backgrounds are appearing when you don't expect them to, or why things are styled differently to normal. See [no_prepend[]] and [Styling Formspecs].

    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;]

    Version History

    Elements

    formspec_version[<version>] size[<W>,<H>,<fixed_size>] position[<X>,<Y>] anchor[<X>,<Y>] padding[<X>,<Y>] no_prepend[] real_coordinates[<bool>] container[<X>,<Y>] container_end[] scroll_container[<X>,<Y>;<W>,<H>;<scrollbar name>;<orientation>;<scroll factor>] scroll_container_end[] list[<inventory location>;<list name>;<X>,<Y>;<W>,<H>;<starting item index>] listring[<inventory location>;<list name>] listring[] listcolors[<slot_bg_normal>;<slot_bg_hover>] listcolors[<slot_bg_normal>;<slot_bg_hover>;<slot_border>] listcolors[<slot_bg_normal>;<slot_bg_hover>;<slot_border>;<tooltip_bgcolor>;<tooltip_fontcolor>] tooltip[<gui_element_name>;<tooltip_text>;<bgcolor>;<fontcolor>] tooltip[<X>,<Y>;<W>,<H>;<tooltip_text>;<bgcolor>;<fontcolor>] image[<X>,<Y>;<W>,<H>;<texture name>;<middle>] animated_image[<X>,<Y>;<W>,<H>;<name>;<texture name>;<frame count>;<frame duration>;<frame start>;<middle>] model[<X>,<Y>;<W>,<H>;<name>;<mesh>;<textures>;<rotation>;<continuous>;<mouse control>;<frame loop range>;<animation speed>] item_image[<X>,<Y>;<W>,<H>;<item name>] bgcolor[<bgcolor>;<fullscreen>;<fbgcolor>] background[<X>,<Y>;<W>,<H>;<texture name>] background[<X>,<Y>;<W>,<H>;<texture name>;<auto_clip>] background9[<X>,<Y>;<W>,<H>;<texture name>;<auto_clip>;<middle>] pwdfield[<X>,<Y>;<W>,<H>;<name>;<label>] field[<X>,<Y>;<W>,<H>;<name>;<label>;<default>] field[<name>;<label>;<default>] field_enter_after_edit[<name>;<enter_after_edit>] field_close_on_enter[<name>;<close_on_enter>] textarea[<X>,<Y>;<W>,<H>;<name>;<label>;<default>] label[<X>,<Y>;<label>] hypertext[<X>,<Y>;<W>,<H>;<name>;<text>] vertlabel[<X>,<Y>;<label>] button[<X>,<Y>;<W>,<H>;<name>;<label>] button_url[<X>,<Y>;<W>,<H>;<name>;<label>;<url>] image_button[<X>,<Y>;<W>,<H>;<texture name>;<name>;<label>] image_button[<X>,<Y>;<W>,<H>;<texture name>;<name>;<label>;<noclip>;<drawborder>;<pressed texture name>] item_image_button[<X>,<Y>;<W>,<H>;<item name>;<name>;<label>] button_exit[<X>,<Y>;<W>,<H>;<name>;<label>] button_url_exit[<X>,<Y>;<W>,<H>;<name>;<label>;<url>] image_button_exit[<X>,<Y>;<W>,<H>;<texture name>;<name>;<label>] textlist[<X>,<Y>;<W>,<H>;<name>;<listelem 1>,<listelem 2>,...,<listelem n>] textlist[<X>,<Y>;<W>,<H>;<name>;<listelem 1>,<listelem 2>,...,<listelem n>;<selected idx>;<transparent>] tabheader[<X>,<Y>;<name>;<caption 1>,<caption 2>,...,<caption n>;<current_tab>;<transparent>;<draw_border>] tabheader[<X>,<Y>;<H>;<name>;<caption 1>,<caption 2>,...,<caption n>;<current_tab>;<transparent>;<draw_border>] tabheader[<X>,<Y>;<W>,<H>;<name>;<caption 1>,<caption 2>,...,<caption n>;<current_tab>;<transparent>;<draw_border>] box[<X>,<Y>;<W>,<H>;<color>] dropdown[<X>,<Y>;<W>;<name>;<item 1>,<item 2>, ...,<item n>;<selected idx>;<index event>] dropdown[<X>,<Y>;<W>,<H>;<name>;<item 1>,<item 2>, ...,<item n>;<selected idx>;<index event>] checkbox[<X>,<Y>;<name>;<label>;<selected>] scrollbar[<X>,<Y>;<W>,<H>;<orientation>;<name>;<value>] scrollbaroptions[opt1;opt2;...] table[<X>,<Y>;<W>,<H>;<name>;<cell 1>,<cell 2>,...,<cell n>;<selected idx>] tableoptions[<opt 1>;<opt 2>;...] tablecolumns[<type 1>,<opt 1a>,<opt 1b>,...;<type 2>,<opt 2a>,<opt 2b>;...] style[<selector 1>,<selector 2>,...;<prop1>;<prop2>;...] style_type[<selector 1>,<selector 2>,...;<prop1>;<prop2>;...] set_focus[<name>;<force>]

    Migrating to Real Coordinates

    In the old system, positions included padding and spacing. Padding is a gap between the formspec window edges and content, and spacing is the gaps between items. For example, two 1x1 elements at 0,0 and 1,1 would have a spacing of 5/4 between them, and a padding of 3/8 from the formspec edge. It may be easiest to recreate old layouts in the new coordinate system from scratch.

    To recreate an old layout with padding, you'll need to pass the positions and sizes through the following formula to re-introduce padding:

    pos = (oldpos + 1)*spacing + padding where padding = 3/8 spacing = 5/4

    You'll need to change the size[] tag like this:

    size = (oldsize-1)*spacing + padding*2 + 1

    A few elements had random offsets in the old system. Here is a table which shows these offsets when migrating:

    | Element | Position | Size | Notes |---------|------------|---------|------- | box | +0.3, +0.1 | 0, -0.4 | | button | | | Buttons now support height, so set h = 2 * 15/13 * 0.35, and reposition if h ~= 15/13 * 0.35 before | list | | | Spacing is now 0.25 for both directions, meaning lists will be taller in height | label | 0, +0.3 | | The first line of text is now positioned centered exactly at the position specified

    Styling Formspecs

    Formspec elements can be themed using the style elements:

    style[<name 1>,<name 2>,...;<prop1>;<prop2>;...]
style[<name 1>:<state>,<name 2>:<state>,...;<prop1>;<prop2>;...]
style_type[<type 1>,<type 2>,...;<prop1>;<prop2>;...]
style_type[<type 1>:<state>,<type 2>:<state>,...;<prop1>;<prop2>;...]

    Where a prop is:

    property_name=property_value

    For example:

    style_type[button;bgcolor=#006699]
style[world_delete;bgcolor=red;textcolor=yellow]
button[4,3.95;2.6,1;world_delete;Delete]

    A name/type can optionally be a comma separated list of names/types, like so:

    world_delete,world_create,world_configure
button,image_button

    A * type can be used to select every element in the formspec.

    Any name/type in the list can also be accompanied by a +-separated list of states, like so:

    world_delete:hovered+pressed
button:pressed

    States allow you to apply styles in response to changes in the element, instead of applying at all times.

    Setting a property to nothing will reset it to the default value. For example:

    style_type[button;bgimg=button.png;bgimg_pressed=button_pressed.png;border=false]
style[btn_exit;bgimg=;bgimg_pressed=;border=;bgcolor=red]

    Supported Element Types

    Some types may inherit styles from parent types.

    Valid Properties

    Valid States

    Markup Language

    Markup language used in hypertext[] elements uses tags that look like HTML tags. The markup language is currently unstable and subject to change. Use with caution. Some tags can enclose text, they open with <tagname> and close with </tagname>. Tags can have attributes, in that case, attributes are in the opening tag in form of a key/value separated with equal signs. Attribute values should be quoted using either " or '.

    If you want to insert a literal greater-than, less-than, or a backslash into the text, you must escape it by preceding it with a backslash. In a quoted attribute value, you can insert a literal quote mark by preceding it with a backslash.

    These are the technically basic tags but see below for usual tags. Base tags are:

    <style color=... font=... size=...>...</style>

    Changes the style of the text.

    <global background=... margin=... valign=... color=... hovercolor=... size=... font=... halign=... >

    Sets global style.

    Global only styles:

    Inheriting styles (affects child elements):

    This tag needs to be placed only once as it changes the global settings of the text. Anyway, if several tags are placed, each changed will be made in the order tags appear.

    <tag name=... color=... hovercolor=... font=... size=...>

    Defines or redefines tag style. This can be used to define new tags.

    Following tags are the usual tags for text layout. They are defined by default. Other tags can be added using <tag ...> tag.

    <normal>...</normal>: Normal size text

    <big>...</big>: Big text

    <bigger>...</bigger>: Bigger text

    <center>...</center>: Centered text

    <left>...</left>: Left-aligned text

    <right>...</right>: Right-aligned text

    <justify>...</justify>: Justified text

    <mono>...</mono>: Monospaced font

    <b>...</b>, <i>...</i>, <u>...</u>: Bold, italic, underline styles.

    <action name=...>...</action>

    Make that text a clickable text triggering an action.

    When clicked, the formspec is send to the server. The value of the text field sent to on_player_receive_fields will be "action:" concatenated to the action name.

    <img name=... float=... width=... height=...>

    Draws an image which is present in the client media cache.

    If only width or height given, texture aspect is kept.

    <item name=... float=... width=... height=... rotate=...>

    Draws an item image.

    Inventory

    Inventory locations

    Player Inventory lists

    Custom lists can be added and deleted with InvRef:set_size(name, size) like any other inventory.

    ItemStack transaction order

    This list describes the situation for non-empty ItemStacks in both slots that cannot be stacked at all, hence triggering an ItemStack swap operation. Put/take callbacks on empty ItemStack are not executed.

    1. The "allow take" and "allow put" callbacks are each run once for the source and destination inventory.
    2. The allowed ItemStacks are exchanged.
    3. The "on take" callbacks are run for the source and destination inventories
    4. The "on put" callbacks are run for the source and destination inventories

    Colors

    ColorString

    #RGB defines a color in hexadecimal format.

    #RGBA defines a color in hexadecimal format and alpha channel.

    #RRGGBB defines a color in hexadecimal format.

    #RRGGBBAA defines a color in hexadecimal format and alpha channel.

    Named colors are also supported and are equivalent to CSS Color Module Level 4. To specify the value of the alpha channel, append #A or #AA to the end of the color name (e.g. colorname#08).

    ColorSpec

    A ColorSpec specifies a 32-bit color. It can be written in any of the following forms:

    Escape sequences

    Most text can contain escape sequences, that can for example color the text. There are a few exceptions: tab headers, dropdowns and vertical labels can't. The following functions provide escape sequences:

    Spatial Vectors

    Minetest stores 3-dimensional spatial vectors in Lua as tables of 3 coordinates, and has a class to represent them (vector.*), which this chapter is about. For details on what a spatial vectors is, please refer to Wikipedia: https://en.wikipedia.org/wiki/Euclidean_vector.

    Spatial vectors are used for various things, including, but not limited to:

    Note that they are not used for:

    The API documentation may refer to spatial vectors, as produced by vector.new, by any of the following notations:

    Compatibility notes

    Vectors used to be defined as tables of the form {x = num, y = num, z = num}. Since Minetest 5.5.0, vectors additionally have a metatable to enable easier use. Note: Those old-style vectors can still be found in old mod code. Hence, mod and engine APIs still need to be able to cope with them in many places.

    Manually constructed tables are deprecated and highly discouraged. This interface should be used to ensure seamless compatibility between mods and the Minetest API. This is especially important to callback function parameters and functions overwritten by mods. Also, though not likely, the internal implementation of a vector might change in the future. In your own code, or if you define your own API, you can, of course, still use other representations of vectors.

    Vectors provided by API functions will provide an instance of this class if not stated otherwise. Mods should adapt this for convenience reasons.

    Special properties of the class

    Vectors can be indexed with numbers and allow method and operator syntax.

    All these forms of addressing a vector v are valid: v[1], v[3], v.x, v[1] = 42, v.y = 13 Note: Prefer letter over number indexing for performance and compatibility reasons.

    Where v is a vector and foo stands for any function name, v:foo(...) does the same as vector.foo(v, ...), apart from deprecated functionality.

    tostring is defined for vectors, see vector.to_string.

    The metatable that is used for vectors can be accessed via vector.metatable. Do not modify it!

    All vector.* functions allow vectors {x = X, y = Y, z = Z} without metatables. Returned vectors always have a metatable set.

    Common functions and methods

    For the following functions (and subchapters), v, v1, v2 are vectors, p1, p2 are position vectors, s is a scalar (a number), vectors are written like this: (x, y, z):

    For the following functions x can be either a vector or a number:

    Operators

    Operators can be used if all of the involved vectors have metatables:

    For the following functions a is an angle in radians and r is a rotation vector ({x = <pitch>, y = <yaw>, z = <roll>}) where pitch, yaw and roll are angles in radians.

    Further helpers

    There are more helper functions involving vectors, but they are listed elsewhere because they only work on specific sorts of vectors or involve things that are not vectors.

    For example:

    Helper functions

    Translations

    Texts can be translated client-side with the help of minetest.translate and translation files.

    Consider using the script mod_translation_updater.py in the Minetest modtools repository to generate and update translation files automatically from the Lua sources.

    Translating a string

    Two functions are provided to translate strings: minetest.translate and minetest.get_translator.

    For instance, suppose we want to greet players when they join. We can do the following:

    lua local S = minetest.get_translator("hello") minetest.register_on_joinplayer(function(player) local name = player:get_player_name() minetest.chat_send_player(name, S("Hello @1, how are you today?", name)) end)

    When someone called "CoolGuy" joins the game with an old client or a client that does not have localization enabled, they will see Hello CoolGuy, how are you today?

    However, if we have for instance a translation file named hello.de.tr containing the following:

    # textdomain: hello
Hello @1, how are you today?=Hallo @1, wie geht es dir heute?

    and CoolGuy has set a German locale, they will see Hallo CoolGuy, wie geht es dir heute?

    Operations on translated strings

    The output of minetest.translate is a string, with escape sequences adding additional information to that string so that it can be translated on the different clients. In particular, you can't expect operations like string.length to work on them like you would expect them to, or string.gsub to work in the expected manner. However, string concatenation will still work as expected (note that you should only use this for things like formspecs; do not translate sentences by breaking them into parts; arguments should be used instead), and operations such as minetest.colorize which are also concatenation.

    Translation file format

    A translation file has the suffix .[lang].tr, where [lang] is the language it corresponds to. It must be put into the locale subdirectory of the mod. The file should be a text file, with the following format:

    Escapes

    Strings that need to be translated can contain several escapes, preceded by @.

    Server side translations

    On some specific cases, server translation could be useful. For example, filter a list on labels and send results to client. A method is supplied to achieve that:

    minetest.get_translated_string(lang_code, string): resolves translations in the given string just like the client would, using the translation files for lang_code. For this to have any effect, the string needs to contain translation markup, e.g. minetest.get_translated_string("fr", S("Hello")).

    The lang_code to use for a given player can be retrieved from the table returned by minetest.get_player_information(name).

    IMPORTANT: This functionality should only be used for sorting, filtering or similar purposes. You do not need to use this to get translated strings to show up on the client.

    Translating content meta

    You can translate content meta, such as title and description, by placing translations in a locale/DOMAIN.LANG.tr file. The textdomain defaults to the content name, but can be customised using textdomain in the content's .conf.

    Mods and Texture Packs

    Say you have a mod called mymod with a short description in mod.conf:

    description = This is the short description

    Minetest will look for translations in the mymod textdomain as there's no textdomain specified in mod.conf. For example, mymod/locale/mymod.fr.tr:

    ```

    textdomain:mymod

    This is the short description=Voici la description succincte ```

    Games and Modpacks

    For games and modpacks, Minetest will look for the textdomain in all mods.

    Say you have a game called mygame with the following game.conf:

    description = This is the game's short description textdomain = mygame

    Minetest will then look for the textdomain mygame in all mods, for example, mygame/mods/anymod/locale/mygame.fr.tr. Note that it is still recommended that your textdomain match the mod name, but this isn't required.

    Perlin noise

    Perlin noise creates a continuously-varying value depending on the input values. Usually in Minetest the input values are either 2D or 3D coordinates in nodes. The result is used during map generation to create the terrain shape, vary heat and humidity to distribute biomes, vary the density of decorations or vary the structure of ores.

    Structure of perlin noise

    An 'octave' is a simple noise generator that outputs a value between -1 and 1. The smooth wavy noise it generates has a single characteristic scale, almost like a 'wavelength', so on its own does not create fine detail. Due to this perlin noise combines several octaves to create variation on multiple scales. Each additional octave has a smaller 'wavelength' than the previous.

    This combination results in noise varying very roughly between -2.0 and 2.0 and with an average value of 0.0, so scale and offset are then used to multiply and offset the noise variation.

    The final perlin noise variation is created as follows:

    noise = offset + scale * (octave1 + octave2 * persistence + octave3 * persistence ^ 2 + octave4 * persistence ^ 3 + ...)

    Noise Parameters

    Noise Parameters are commonly called NoiseParams.

    offset

    After the multiplication by scale this is added to the result and is the final step in creating the noise value. Can be positive or negative.

    scale

    Once all octaves have been combined, the result is multiplied by this. Can be positive or negative.

    spread

    For octave1, this is roughly the change of input value needed for a very large variation in the noise value generated by octave1. It is almost like a 'wavelength' for the wavy noise variation. Each additional octave has a 'wavelength' that is smaller than the previous octave, to create finer detail. spread will therefore roughly be the typical size of the largest structures in the final noise variation.

    spread is a vector with values for x, y, z to allow the noise variation to be stretched or compressed in the desired axes. Values are positive numbers.

    seed

    This is a whole number that determines the entire pattern of the noise variation. Altering it enables different noise patterns to be created. With other parameters equal, different seeds produce different noise patterns and identical seeds produce identical noise patterns.

    For this parameter you can randomly choose any whole number. Usually it is preferable for this to be different from other seeds, but sometimes it is useful to be able to create identical noise patterns.

    In some noise APIs the world seed is added to the seed specified in noise parameters. This is done to make the resulting noise pattern vary in different worlds, and be 'world-specific'.

    octaves

    The number of simple noise generators that are combined. A whole number, 1 or more. Each additional octave adds finer detail to the noise but also increases the noise calculation load. 3 is a typical minimum for a high quality, complex and natural-looking noise variation. 1 octave has a slight 'gridlike' appearance.

    Choose the number of octaves according to the spread and lacunarity, and the size of the finest detail you require. For example: if spread is 512 nodes, lacunarity is 2.0 and finest detail required is 16 nodes, octaves will be 6 because the 'wavelengths' of the octaves will be 512, 256, 128, 64, 32, 16 nodes. Warning: If the 'wavelength' of any octave falls below 1 an error will occur.

    persistence

    Each additional octave has an amplitude that is the amplitude of the previous octave multiplied by persistence, to reduce the amplitude of finer details, as is often helpful and natural to do so. Since this controls the balance of fine detail to large-scale detail persistence can be thought of as the 'roughness' of the noise.

    A positive or negative non-zero number, often between 0.3 and 1.0. A common medium value is 0.5, such that each octave has half the amplitude of the previous octave. This may need to be tuned when altering lacunarity; when doing so consider that a common medium value is 1 / lacunarity.

    Instead of persistence, the key persist may be used to the same effect.

    lacunarity

    Each additional octave has a 'wavelength' that is the 'wavelength' of the previous octave multiplied by 1 / lacunarity, to create finer detail. 'lacunarity' is often 2.0 so 'wavelength' often halves per octave.

    A positive number no smaller than 1.0. Values below 2.0 create higher quality noise at the expense of requiring more octaves to cover a particular range of 'wavelengths'.

    flags

    Leave this field unset for no special handling. Currently supported are defaults, eased and absvalue:

    defaults

    Specify this if you would like to keep auto-selection of eased/not-eased while specifying some other flags.

    eased

    Maps noise gradient values onto a quintic S-curve before performing interpolation. This results in smooth, rolling noise. Disable this (noeased) for sharp-looking noise with a slightly gridded appearance. If no flags are specified (or defaults is), 2D noise is eased and 3D noise is not eased. Easing a 3D noise significantly increases the noise calculation load, so use with restraint.

    absvalue

    The absolute value of each octave's noise variation is used when combining the octaves. The final perlin noise variation is created as follows:

    noise = offset + scale * (abs(octave1) + abs(octave2) * persistence + abs(octave3) * persistence ^ 2 + abs(octave4) * persistence ^ 3 + ...)

    Format example

    For 2D or 3D perlin noise or perlin noise maps:

    lua np_terrain = { offset = 0, scale = 1, spread = {x = 500, y = 500, z = 500}, seed = 571347, octaves = 5, persistence = 0.63, lacunarity = 2.0, flags = "defaults, absvalue", }

    For 2D noise the Z component of spread is still defined but is ignored. A single noise parameter table can be used for 2D or 3D noise.

    Ores

    Ore types

    These tell in what manner the ore is generated.

    All default ores are of the uniformly-distributed scatter type.

    scatter

    Randomly chooses a location and generates a cluster of ore.

    If noise_params is specified, the ore will be placed if the 3D perlin noise at that point is greater than the noise_threshold, giving the ability to create a non-equal distribution of ore.

    sheet

    Creates a sheet of ore in a blob shape according to the 2D perlin noise described by noise_params and noise_threshold. This is essentially an improved version of the so-called "stratus" ore seen in some unofficial mods.

    This sheet consists of vertical columns of uniform randomly distributed height, varying between the inclusive range column_height_min and column_height_max. If column_height_min is not specified, this parameter defaults to 1. If column_height_max is not specified, this parameter defaults to clust_size for reverse compatibility. New code should prefer column_height_max.

    The column_midpoint_factor parameter controls the position of the column at which ore emanates from. If 1, columns grow upward. If 0, columns grow downward. If 0.5, columns grow equally starting from each direction. column_midpoint_factor is a decimal number ranging in value from 0 to 1. If this parameter is not specified, the default is 0.5.

    The ore parameters clust_scarcity and clust_num_ores are ignored for this ore type.

    puff

    Creates a sheet of ore in a cloud-like puff shape.

    As with the sheet ore type, the size and shape of puffs are described by noise_params and noise_threshold and are placed at random vertical positions within the currently generated chunk.

    The vertical top and bottom displacement of each puff are determined by the noise parameters np_puff_top and np_puff_bottom, respectively.

    blob

    Creates a deformed sphere of ore according to 3d perlin noise described by noise_params. The maximum size of the blob is clust_size, and clust_scarcity has the same meaning as with the scatter type.

    vein

    Creates veins of ore varying in density by according to the intersection of two instances of 3d perlin noise with different seeds, both described by noise_params.

    random_factor varies the influence random chance has on placement of an ore inside the vein, which is 1 by default. Note that modifying this parameter may require adjusting noise_threshold.

    The parameters clust_scarcity, clust_num_ores, and clust_size are ignored by this ore type.

    This ore type is difficult to control since it is sensitive to small changes. The following is a decent set of parameters to work from:

    lua noise_params = { offset = 0, scale = 3, spread = {x=200, y=200, z=200}, seed = 5390, octaves = 4, persistence = 0.5, lacunarity = 2.0, flags = "eased", }, noise_threshold = 1.6

    WARNING: Use this ore type very sparingly since it is ~200x more computationally expensive than any other ore.

    stratum

    Creates a single undulating ore stratum that is continuous across mapchunk borders and horizontally spans the world.

    The 2D perlin noise described by noise_params defines the Y coordinate of the stratum midpoint. The 2D perlin noise described by np_stratum_thickness defines the stratum's vertical thickness (in units of nodes). Due to being continuous across mapchunk borders the stratum's vertical thickness is unlimited.

    If the noise parameter noise_params is omitted the ore will occur from y_min to y_max in a simple horizontal stratum.

    A parameter stratum_thickness can be provided instead of the noise parameter np_stratum_thickness, to create a constant thickness.

    Leaving out one or both noise parameters makes the ore generation less intensive, useful when adding multiple strata.

    y_min and y_max define the limits of the ore generation and for performance reasons should be set as close together as possible but without clipping the stratum's Y variation.

    Each node in the stratum has a 1-in-clust_scarcity chance of being ore, so a solid-ore stratum would require a clust_scarcity of 1.

    The parameters clust_num_ores, clust_size, noise_threshold and random_factor are ignored by this ore type.

    Ore attributes

    See section [Flag Specifier Format].

    Currently supported flags: puff_cliffs, puff_additive_composition.

    puff_cliffs

    If set, puff ore generation will not taper down large differences in displacement when approaching the edge of a puff. This flag has no effect for ore types other than puff.

    puff_additive_composition

    By default, when noise described by np_puff_top or np_puff_bottom results in a negative displacement, the sub-column at that point is not generated. With this attribute set, puff ore generation will instead generate the absolute difference in noise displacement values. This flag has no effect for ore types other than puff.

    Decoration types

    The varying types of decorations that can be placed.

    simple

    Creates a 1 times H times 1 column of a specified node (or a random node from a list, if a decoration list is specified). Can specify a certain node it must spawn next to, such as water or lava, for example. Can also generate a decoration of random height between a specified lower and upper bound. This type of decoration is intended for placement of grass, flowers, cacti, papyri, waterlilies and so on.

    schematic

    Copies a box of MapNodes from a specified schematic file (or raw description). Can specify a probability of a node randomly appearing when placed. This decoration type is intended to be used for multi-node sized discrete structures, such as trees, cave spikes, rocks, and so on.

    lsystem

    Generates a L-system tree at the position where the decoration is placed. Uses the same L-system as minetest.spawn_tree, but is faster than using it manually. The treedef field in the decoration definition is used for the tree definition.

    Schematics

    Schematic specifier

    A schematic specifier identifies a schematic by either a filename to a Minetest Schematic file (.mts) or through raw data supplied through Lua, in the form of a table. This table specifies the following fields:

    About probability values:

    Schematic attributes

    See section [Flag Specifier Format].

    Currently supported flags: place_center_x, place_center_y, place_center_z, force_placement.

    Lua Voxel Manipulator

    About VoxelManip

    VoxelManip is a scripting interface to the internal 'Map Voxel Manipulator' facility. The purpose of this object is for fast, low-level, bulk access to reading and writing Map content. As such, setting map nodes through VoxelManip will lack many of the higher level features and concepts you may be used to with other methods of setting nodes. For example, nodes will not have their construction and destruction callbacks run, and no rollback information is logged.

    It is important to note that VoxelManip is designed for speed, and not ease of use or flexibility. If your mod requires a map manipulation facility that will handle 100% of all edge cases, or the use of high level node placement features, perhaps minetest.set_node() is better suited for the job.

    In addition, VoxelManip might not be faster, or could even be slower, for your specific use case. VoxelManip is most effective when setting large areas of map at once - for example, if only setting a 3x3x3 node area, a minetest.set_node() loop may be more optimal. Always profile code using both methods of map manipulation to determine which is most appropriate for your usage.

    A recent simple test of setting cubic areas showed that minetest.set_node() is faster than a VoxelManip for a 3x3x3 node cube or smaller.

    Using VoxelManip

    A VoxelManip object can be created any time using either: VoxelManip([p1, p2]), or minetest.get_voxel_manip([p1, p2]).

    If the optional position parameters are present for either of these routines, the specified region will be pre-loaded into the VoxelManip object on creation. Otherwise, the area of map you wish to manipulate must first be loaded into the VoxelManip object using VoxelManip:read_from_map().

    Note that VoxelManip:read_from_map() returns two position vectors. The region formed by these positions indicate the minimum and maximum (respectively) positions of the area actually loaded in the VoxelManip, which may be larger than the area requested. For convenience, the loaded area coordinates can also be queried any time after loading map data with VoxelManip:get_emerged_area().

    Now that the VoxelManip object is populated with map data, your mod can fetch a copy of this data using either of two methods. VoxelManip:get_node_at(), which retrieves an individual node in a MapNode formatted table at the position requested is the simplest method to use, but also the slowest.

    Nodes in a VoxelManip object may also be read in bulk to a flat array table using:

    See section [Flat array format] for more details.

    It is very important to understand that the tables returned by any of the above three functions represent a snapshot of the VoxelManip's internal state at the time of the call. This copy of the data will not magically update itself if another function modifies the internal VoxelManip state. Any functions that modify a VoxelManip's contents work on the VoxelManip's internal state unless otherwise explicitly stated.

    Once the bulk data has been edited to your liking, the internal VoxelManip state can be set using:

    The parameter to each of the above three functions can use any table at all in the same flat array format as produced by get_data() etc. and is not required to be a table retrieved from get_data().

    Once the internal VoxelManip state has been modified to your liking, the changes can be committed back to the map by calling VoxelManip:write_to_map()

    Flat array format

    Let Nx = p2.X - p1.X + 1, Ny = p2.Y - p1.Y + 1, and Nz = p2.Z - p1.Z + 1.

    Then, for a loaded region of p1..p2, this array ranges from 1 up to and including the value of the expression Nx * Ny * Nz.

    Positions offset from p1 are present in the array with the format of:

    [
    (0, 0, 0),   (1, 0, 0),   (2, 0, 0),   ... (Nx, 0, 0),
    (0, 1, 0),   (1, 1, 0),   (2, 1, 0),   ... (Nx, 1, 0),
    ...
    (0, Ny, 0),  (1, Ny, 0),  (2, Ny, 0),  ... (Nx, Ny, 0),
    (0, 0, 1),   (1, 0, 1),   (2, 0, 1),   ... (Nx, 0, 1),
    ...
    (0, Ny, 2),  (1, Ny, 2),  (2, Ny, 2),  ... (Nx, Ny, 2),
    ...
    (0, Ny, Nz), (1, Ny, Nz), (2, Ny, Nz), ... (Nx, Ny, Nz)
]

    and the array index for a position p contained completely in p1..p2 is:

    (p.Z - p1.Z) * Ny * Nx + (p.Y - p1.Y) * Nx + (p.X - p1.X) + 1

    Note that this is the same "flat 3D array" format as PerlinNoiseMap:get3dMap_flat(). VoxelArea objects (see section [VoxelArea]) can be used to simplify calculation of the index for a single point in a flat VoxelManip array.

    Content IDs

    A Content ID is a unique integer identifier for a specific node type. These IDs are used by VoxelManip in place of the node name string for VoxelManip:get_data() and VoxelManip:set_data(). You can use minetest.get_content_id() to look up the Content ID for the specified node name, and minetest.get_name_from_content_id() to look up the node name string for a given Content ID. After registration of a node, its Content ID will remain the same throughout execution of the mod. Note that the node being queried needs to have already been been registered.

    The following builtin node types have their Content IDs defined as constants:

    Mapgen VoxelManip objects

    Inside of on_generated() callbacks, it is possible to retrieve the same VoxelManip object used by the core's Map Generator (commonly abbreviated Mapgen). Most of the rules previously described still apply but with a few differences:

    Other API functions operating on a VoxelManip

    If any VoxelManip contents were set to a liquid node (liquidtype ~= "none"), VoxelManip:update_liquids() must be called for these liquid nodes to begin flowing. It is recommended to call this function only after having written all buffered data back to the VoxelManip object, save for special situations where the modder desires to only have certain liquid nodes begin flowing.

    The functions minetest.generate_ores() and minetest.generate_decorations() will generate all registered decorations and ores throughout the full area inside of the specified VoxelManip object.

    minetest.place_schematic_on_vmanip() is otherwise identical to minetest.place_schematic(), except instead of placing the specified schematic directly on the map at the specified position, it will place the schematic inside the VoxelManip.

    Notes

    Methods

    VoxelArea

    A helper class for voxel areas. It can be created via VoxelArea(pmin, pmax) or VoxelArea:new({MinEdge = pmin, MaxEdge = pmax}). The coordinates are inclusive, like most other things in Minetest.

    Methods

    Y stride and z stride of a flat array

    For a particular position in a voxel area, whose flat array index is known, it is often useful to know the index of a neighboring or nearby position. The table below shows the changes of index required for 1 node movements along the axes in a voxel area:

    Movement    Change of index
+x          +1
-x          -1
+y          +ystride
-y          -ystride
+z          +zstride
-z          -zstride

    If, for example:

    local area = VoxelArea(emin, emax)

    The values of ystride and zstride can be obtained using area.ystride and area.zstride.

    Mapgen objects

    A mapgen object is a construct used in map generation. Mapgen objects can be used by an on_generated callback to speed up operations by avoiding unnecessary recalculations, these can be retrieved using the minetest.get_mapgen_object() function. If the requested Mapgen object is unavailable, or get_mapgen_object() was called outside of an on_generated callback, nil is returned.

    The following Mapgen objects are currently available:

    voxelmanip

    This returns three values; the VoxelManip object to be used, minimum and maximum emerged position, in that order. All mapgens support this object.

    heightmap

    Returns an array containing the y coordinates of the ground levels of nodes in the most recently generated chunk by the current mapgen.

    biomemap

    Returns an array containing the biome IDs of nodes in the most recently generated chunk by the current mapgen.

    heatmap

    Returns an array containing the temperature values of nodes in the most recently generated chunk by the current mapgen.

    humiditymap

    Returns an array containing the humidity values of nodes in the most recently generated chunk by the current mapgen.

    gennotify

    Returns a table. You need to announce your interest in a specific field by calling minetest.set_gen_notify() before map generation happens.

    Available generation notification types:

    Decorations have a key in the format of "decoration#id", where id is the numeric unique decoration ID as returned by minetest.get_decoration_id(). For example, decoration#123.

    The returned positions are the ground surface 'place_on' nodes, not the decorations themselves. A 'simple' type decoration is often 1 node above the returned position and possibly displaced by 'place_offset_y'.

    Registered entities

    Functions receive a "luaentity" table as self:

    Callbacks:

    Collision info passed to on_step (moveresult argument):

    ```lua { touching_ground = boolean, -- Note that touching_ground is only true if the entity was moving and -- collided with ground.

    collides = boolean,
standing_on_object = boolean,

collisions = {
    {
        type = string, -- "node" or "object",
        axis = string, -- "x", "y" or "z"
        node_pos = vector, -- if type is "node"
        object = ObjectRef, -- if type is "object"
        -- The position of the entity when the collision occurred.
        -- Available since feature "moveresult_new_pos".
        new_pos = vector,
        old_velocity = vector,
        new_velocity = vector,
    },
    ...
}
-- `collisions` does not contain data of unloaded mapblock collisions
-- or when the velocity changes are negligibly small

    } ```

    L-system trees

    Tree definition

    lua treedef={ axiom, --string initial tree axiom rules_a, --string rules set A rules_b, --string rules set B rules_c, --string rules set C rules_d, --string rules set D trunk, --string trunk node name leaves, --string leaves node name leaves2, --string secondary leaves node name leaves2_chance,--num chance (0-100) to replace leaves with leaves2 angle, --num angle in deg iterations, --num max # of iterations, usually 2 -5 random_level, --num factor to lower number of iterations, usually 0 - 3 trunk_type, --string single/double/crossed) type of trunk: 1 node, -- 2x2 nodes or 3x3 in cross shape thin_branches, --boolean true -> use thin (1 node) branches fruit, --string fruit node name fruit_chance, --num chance (0-100) to replace leaves with fruit node seed, --num random seed, if no seed is provided, the engine will create one. }

    Key for special L-System symbols used in axioms

    Example

    Spawn a small apple tree:

    lua pos = {x=230,y=20,z=4} apple_tree={ axiom="FFFFFAFFBF", rules_a="[&&&FFFFF&&FFFF][&&&++++FFFFF&&FFFF][&&&----FFFFF&&FFFF]", rules_b="[&&&++FFFFF&&FFFF][&&&--FFFFF&&FFFF][&&&------FFFFF&&FFFF]", trunk="default:tree", leaves="default:leaves", angle=30, iterations=2, random_level=0, trunk_type="single", thin_branches=true, fruit_chance=10, fruit="default:apple" } minetest.spawn_tree(pos,apple_tree)

    Privileges

    Privileges provide a means for server administrators to give certain players access to special abilities in the engine, games or mods. For example, game moderators may need to travel instantly to any place in the world, this ability is implemented in /teleport command which requires teleport privilege.

    Registering privileges

    A mod can register a custom privilege using minetest.register_privilege function to give server administrators fine-grained access control over mod functionality.

    For consistency and practical reasons, privileges should strictly increase the abilities of the user. Do not register custom privileges that e.g. restrict the player from certain in-game actions.

    Checking privileges

    A mod can call minetest.check_player_privs to test whether a player has privileges to perform an operation. Also, when registering a chat command with minetest.register_chatcommand a mod can declare privileges that the command requires using the privs field of the command definition.

    Managing player privileges

    A mod can update player privileges using minetest.set_player_privs function. Players holding the privs privilege can see and manage privileges for all players on the server.

    A mod can subscribe to changes in player privileges using minetest.register_on_priv_grant and minetest.register_on_priv_revoke functions.

    Built-in privileges

    Minetest includes a set of built-in privileges that control capabilities provided by the Minetest engine and can be used by mods:

    Minetest includes the following settings to control behavior of privileges:

    'minetest' namespace reference

    Utilities

    Logging

    Registration functions

    Call these functions only at load time!

    Environment

    Gameplay

    Global callback registration functions

    Call these functions only at load time!

    Authentication

    minetest.set_player_password, minetest.set_player_privs, minetest.get_player_privs and minetest.auth_reload call the authentication handler.

    Chat

    Environment access

    Mod channels

    You can find mod channels communication scheme in doc/mod_channels.png.

    Inventory

    minetest.get_inventory(location): returns an InvRef

    Formspec

    Item handling

    Rollback

    Defaults for the

    on_place and

    on_drop item definition functions

    Defaults for the

    on_punch and

    on_dig node definition callbacks

    Sounds

    Timing

    Async environment

    The engine allows you to submit jobs to be ran in an isolated environment concurrently with normal server operation. A job consists of a function to be ran in the async environment, any amount of arguments (will be serialized) and a callback that will be called with the return value of the job function once it is finished.

    The async environment does not have access to the map, entities, players or any globals defined in the 'usual' environment. Consequently, functions like minetest.get_node() or minetest.get_player_by_name() simply do not exist in it.

    Arguments and return values passed through this can contain certain userdata objects that will be seamlessly copied (not shared) to the async environment. This allows you easy interoperability for delegating work to jobs.

    List of APIs available in an async environment

    Classes:

    Class instances that can be transferred between environments:

    Functions:

    Variables:

    Mapgen environment

    The engine runs the map generator on separate threads, each of these also has a Lua environment. Its primary purpose is to allow mods to operate on newly generated parts of the map to e.g. generate custom structures. Internally it is referred to as "emerge environment".

    Refer to [Async environment] for the usual disclaimer on what environment isolation entails.

    The map generator threads, which also contain the above mentioned Lua environment, are initialized after all mods have been loaded by the server. After that the registered scripts (not all mods!) - see below - are run during initialization of the mapgen environment. After that only callbacks happen. The mapgen env does not have a global step or timer.

    List of APIs exclusive to the mapgen env

    List of APIs available in the mapgen env

    Classes:

    Functions:

    Variables:

    Note that node metadata does not exist in the mapgen env, we suggest deferring setting any metadata you need to the on_generated callback in the regular env. You can use the gennotify mechanism to transfer this information.

    Server

    Bans

    Particles

    Schematics

    HTTP Requests

    Storage API

    Misc.

    Global objects

    Global tables

    Registered definition tables

    Registered callback tables

    All callbacks registered with [Global callback registration functions] are added to corresponding minetest.registered_* tables.

    For historical reasons, the use of an -s suffix in these names is inconsistent.

    Class reference

    Sorted alphabetically.

    AreaStore

    AreaStore is a data structure to calculate intersections of 3D cuboid volumes and points. The data field (string) may be used to store and retrieve any mod-relevant information to the specified area.

    Despite its name, mods must take care of persisting AreaStore data. They may use the provided load and write functions for this.

    Methods

    InvRef

    An InvRef is a reference to an inventory.

    Methods

    Callbacks

    Detached & nodemeta inventories provide the following callbacks for move actions:

    Before

    The allow_* callbacks return how many items can be moved.

    After

    The on_* callbacks are called after the items have been placed in the inventories.

    Swapping

    When a player tries to put an item to a place where another item is, the items are swapped. This means that all callbacks will be called twice (once for each action).

    ItemStack

    An ItemStack is a stack of items.

    It can be created via ItemStack(x), where x is an ItemStack, an itemstring, a table or nil.

    Methods

    Operators

    ItemStackMetaRef

    ItemStack metadata: reference extra data and functionality stored in a stack. Can be obtained via item:get_meta().

    Methods

    MetaDataRef

    Base class used by [StorageRef], [NodeMetaRef], [ItemStackMetaRef], and [PlayerMetaRef].

    Note: If a metadata value is in the format ${k}, an attempt to get the value will return the value associated with key k. There is a low recursion limit. This behavior is deprecated and will be removed in a future version. Usage of the ${k} syntax in formspecs is not deprecated.

    Methods

    Metadata tables

    Metadata tables represent MetaDataRef in a Lua table form (see from_table/to_table).

    A metadata table is a table that has the following keys:

    Example:

    ```lua metadata_table = { -- metadata fields (key/value store) fields = { infotext = "Container", another_key = "Another Value", },

    -- inventory data (for nodes)
inventory = {
    -- inventory list "main" with 4 slots
    main = {
        -- list of all item slots
        [1] = "example:dirt",
        [2] = "example:stone 25",
        [3] = "", -- empty slot
        [4] = "example:pickaxe",
    },
    -- inventory list "hidden" with 1 slot
    hidden = {
        [1] = "example:diamond",
    },
},

    } ```

    ModChannel

    An interface to use mod channels on client and server

    Methods

    NodeMetaRef

    Node metadata: reference extra data and functionality stored in a node. Can be obtained via minetest.get_meta(pos).

    Methods

    NodeTimerRef

    Node Timers: a high resolution persistent per-node timer. Can be gotten via minetest.get_node_timer(pos).

    Methods

    ObjectRef

    Moving things in the game are generally these. This is basically a reference to a C++ ServerActiveObject.

    Advice on handling ObjectRefs

    When you receive an ObjectRef as a callback argument or from another API function, it is possible to store the reference somewhere and keep it around. It will keep functioning until the object is unloaded or removed.

    However, doing this is NOT recommended - ObjectRefs should be "let go" of as soon as control is returned from Lua back to the engine.

    Doing so is much less error-prone and you will never need to wonder if the object you are working with still exists.

    If this is not feasible, you can test whether an ObjectRef is still valid via object:is_valid().

    Getters may be called for invalid objects and will return nothing then. All other methods should not be called on invalid objects.

    Attachments

    It is possible to attach objects to other objects (set_attach method).

    When an object is attached, it is positioned relative to the parent's position and rotation. get_pos and get_rotation will always return the parent's values and changes via their setter counterparts are ignored.

    To change position or rotation call set_attach again with the new values.

    Note: Just like model dimensions, the relative position in set_attach must be multiplied by 10 compared to world positions.

    It is also possible to attach to a bone of the parent object. In that case the child will follow movement and rotation of that bone.

    Methods

    Lua entity only (no-op for other objects)

    Player only (no-op for other objects)

    PcgRandom

    A 32-bit pseudorandom number generator. Uses PCG32, an algorithm of the permuted congruential generator family, offering very strong randomness.

    Methods

    PerlinNoise

    A perlin noise generator. It can be created via PerlinNoise() or minetest.get_perlin(). For minetest.get_perlin(), the actual seed used is the noiseparams seed plus the world seed, to create world-specific noise.

    PerlinNoise(noiseparams) PerlinNoise(seed, octaves, persistence, spread) (Deprecated).

    minetest.get_perlin(noiseparams) minetest.get_perlin(seeddiff, octaves, persistence, spread) (Deprecated).

    Methods

    PerlinNoiseMap

    A fast, bulk perlin noise generator.

    It can be created via PerlinNoiseMap(noiseparams, size) or minetest.get_perlin_map(noiseparams, size). For minetest.get_perlin_map(), the actual seed used is the noiseparams seed plus the world seed, to create world-specific noise.

    Format of size is {x=dimx, y=dimy, z=dimz}. The z component is omitted for 2D noise, and it must be must be larger than 1 for 3D noise (otherwise nil is returned).

    For each of the functions with an optional buffer parameter: If buffer is not nil, this table will be used to store the result instead of creating a new table.

    Methods

    PlayerMetaRef

    Player metadata. Uses the same method of storage as the deprecated player attribute API, so data there will also be in player meta. Can be obtained using player:get_meta().

    Methods

    PseudoRandom

    A 16-bit pseudorandom number generator. Uses a well-known LCG algorithm introduced by K&R.

    Note: PseudoRandom is slower and has worse random distribution than PcgRandom. Use PseudoRandom only if you need output to match the well-known LCG algorithm introduced by K&R. Otherwise, use PcgRandom.

    Methods

    Raycast

    A raycast on the map. It works with selection boxes. Can be used as an iterator in a for loop as:

    lua local ray = Raycast(...) for pointed_thing in ray do ... end

    The map is loaded as the ray advances. If the map is modified after the Raycast is created, the changes may or may not have an effect on the object.

    It can be created via Raycast(pos1, pos2, objects, liquids) or minetest.raycast(pos1, pos2, objects, liquids) where:

    Limitations

    Raycasts don't always work properly for attached objects as the server has no knowledge of models & bones.

    Rotated selectionboxes paired with automatic_rotate are not reliable either since the server can't reliably know the total rotation of the objects on different clients (which may differ on a per-client basis). The server calculates the total rotation incurred through automatic_rotate as a "best guess" assuming the object was active & rotating on the client all the time since its creation. This may be significantly out of sync with what clients see. Additionally, network latency and delayed property sending may create a mismatch of client- & server rotations.

    In singleplayer mode, raycasts on objects with rotated selectionboxes & automatic rotate will usually only be slightly off; toggling automatic rotation may however cause errors to add up.

    In multiplayer mode, the error may be arbitrarily large.

    Methods

    SecureRandom

    Interface for the operating system's crypto-secure PRNG.

    It can be created via SecureRandom(). The constructor throws an error if a secure random device cannot be found on the system.

    Methods

    Settings

    An interface to read config files in the format of minetest.conf.

    minetest.settings is a Settings instance that can be used to access the main config file (minetest.conf). Instances for other config files can be created via Settings(filename).

    Engine settings on the minetest.settings object have internal defaults that will be returned if a setting is unset. The engine does not (yet) read settingtypes.txt for this purpose. This means that no defaults will be returned for mod settings.

    Methods

    Format

    The settings have the format key = value. Example:

    foo = example text
bar = """
Multiline
value
"""

    StorageRef

    Mod metadata: per mod metadata, saved automatically. Can be obtained via minetest.get_mod_storage() during load time.

    WARNING: This storage backend is incapable of saving raw binary data due to restrictions of JSON.

    Methods

    Definition tables

    Object properties

    Used by ObjectRef methods. Part of an Entity definition. These properties are not persistent, but are applied automatically to the corresponding Lua entity using the given registration fields. Player properties need to be saved manually.

    ``lua { hp_max = 10, -- Defines the maximum and default HP of the entity -- For Lua entities the maximum is not enforced. -- For players this defaults tominetest.PLAYER_MAX_HP_DEFAULT`.

    breath_max = 0,
-- For players only. Defaults to `minetest.PLAYER_MAX_BREATH_DEFAULT`.

zoom_fov = 0.0,
-- For players only. Zoom FOV in degrees.
-- Note that zoom loads and/or generates world beyond the server's
-- maximum send and generate distances, so acts like a telescope.
-- Smaller zoom_fov values increase the distance loaded/generated.
-- Defaults to 15 in creative mode, 0 in survival mode.
-- zoom_fov = 0 disables zooming for the player.

eye_height = 1.625,
-- For players only. Camera height above feet position in nodes.

physical = false,
-- Collide with `walkable` nodes.

collide_with_objects = true,
-- Collide with other objects if physical = true

collisionbox = { -0.5, -0.5, -0.5, 0.5, 0.5, 0.5 },  -- default
selectionbox = { -0.5, -0.5, -0.5, 0.5, 0.5, 0.5, rotate = false },
-- { xmin, ymin, zmin, xmax, ymax, zmax } in nodes from object position.
-- Collision boxes cannot rotate, setting `rotate = true` on it has no effect.
-- If not set, the selection box copies the collision box, and will also not rotate.
-- If `rotate = false`, the selection box will not rotate with the object itself, remaining fixed to the axes.
-- If `rotate = true`, it will match the object's rotation and any attachment rotations.
-- Raycasts use the selection box and object's rotation, but do *not* obey attachment rotations.
-- For server-side raycasts to work correctly,
-- the selection box should extend at most 5 units in each direction.


pointable = true,
-- Can be `true` if it is pointable, `false` if it can be pointed through,
-- or `"blocking"` if it is pointable but not selectable.
-- Clients older than 5.9.0 interpret `pointable = "blocking"` as `pointable = true`.
-- Can be overridden by the `pointabilities` of the held item.

visual = "cube" / "sprite" / "upright_sprite" / "mesh" / "wielditem" / "item",
-- "cube" is a node-sized cube.
-- "sprite" is a flat texture always facing the player.
-- "upright_sprite" is a vertical flat texture.
-- "mesh" uses the defined mesh model.
-- "wielditem" is used for dropped items.
--   (see builtin/game/item_entity.lua).
--   For this use 'wield_item = itemname'.
--   Setting 'textures = {itemname}' has the same effect, but is deprecated.
--   If the item has a 'wield_image' the object will be an extrusion of
--   that, otherwise:
--   If 'itemname' is a cubic node or nodebox the object will appear
--   identical to 'itemname'.
--   If 'itemname' is a plantlike node the object will be an extrusion
--   of its texture.
--   Otherwise for non-node items, the object will be an extrusion of
--   'inventory_image'.
--   If 'itemname' contains a ColorString or palette index (e.g. from
--   `minetest.itemstring_with_palette()`), the entity will inherit the color.
--   Wielditems are scaled a bit. If you want a wielditem to appear
--   to be as large as a node, use `0.667` in `visual_size`
-- "item" is similar to "wielditem" but ignores the 'wield_image' parameter.

visual_size = {x = 1, y = 1, z = 1},
-- Multipliers for the visual size. If `z` is not specified, `x` will be used
-- to scale the entity along both horizontal axes.

mesh = "model.obj",
-- File name of mesh when using "mesh" visual

textures = {},
-- Number of required textures depends on visual.
-- "cube" uses 6 textures just like a node, but all 6 must be defined.
-- "sprite" uses 1 texture.
-- "upright_sprite" uses 2 textures: {front, back}.
-- "mesh" requires one texture for each mesh buffer/material (in order)
-- Deprecated usage of "wielditem" expects 'textures = {itemname}' (see 'visual' above).

colors = {},
-- Number of required colors depends on visual

use_texture_alpha = false,
-- Use texture's alpha channel.
-- Excludes "upright_sprite" and "wielditem".
-- Note: currently causes visual issues when viewed through other
-- semi-transparent materials such as water.

spritediv = {x = 1, y = 1},
-- Used with spritesheet textures for animation and/or frame selection
-- according to position relative to player.
-- Defines the number of columns and rows in the spritesheet:
-- {columns, rows}.

initial_sprite_basepos = {x = 0, y = 0},
-- Used with spritesheet textures.
-- Defines the {column, row} position of the initially used frame in the
-- spritesheet.

is_visible = true,
-- If false, object is invisible and can't be pointed.

makes_footstep_sound = false,
-- If true, is able to make footstep sounds of nodes
-- (see node sound definition for details).

automatic_rotate = 0,
-- Set constant rotation in radians per second, positive or negative.
-- Object rotates along the local Y-axis, and works with set_rotation.
-- Set to 0 to disable constant rotation.

stepheight = 0,
-- If positive number, object will climb upwards when it moves
-- horizontally against a `walkable` node, if the height difference
-- is within `stepheight`.

automatic_face_movement_dir = 0.0,
-- Automatically set yaw to movement direction, offset in degrees.
-- 'false' to disable.

automatic_face_movement_max_rotation_per_sec = -1,
-- Limit automatic rotation to this value in degrees per second.
-- No limit if value <= 0.

backface_culling = true,
-- Set to false to disable backface_culling for model

glow = 0,
-- Add this much extra lighting when calculating texture color.
-- Value < 0 disables light's effect on texture color.
-- For faking self-lighting, UI style entities, or programmatic coloring
-- in mods.

nametag = "",
-- The name to display on the head of the object. By default empty.
-- If the object is a player, a nil or empty nametag is replaced by the player's name.
-- For all other objects, a nil or empty string removes the nametag.
-- To hide a nametag, set its color alpha to zero. That will disable it entirely.

nametag_color = <ColorSpec>,
-- Sets text color of nametag

nametag_bgcolor = <ColorSpec>,
-- Sets background color of nametag
-- `false` will cause the background to be set automatically based on user settings.
-- Default: false

infotext = "",
-- Same as infotext for nodes. Empty by default

static_save = true,
-- If false, never save this object statically. It will simply be
-- deleted when the block gets unloaded.
-- The get_staticdata() callback is never called then.
-- Defaults to 'true'.

damage_texture_modifier = "^[brighten",
-- Texture modifier to be applied for a short duration when object is hit

shaded = true,
-- Setting this to 'false' disables diffuse lighting of entity

show_on_minimap = false,
-- Defaults to true for players, false for other entities.
-- If set to true the entity will show as a marker on the minimap.

    } ```

    Entity definition

    Used by minetest.register_entity. The entity definition table becomes a metatable of a newly created per-entity luaentity table, meaning its fields (e.g. initial_properties) will be shared between all instances of an entity.

    ``lua { initial_properties = { visual = "mesh", mesh = "boats_boat.obj", ..., }, -- A table of object properties, see theObject properties` section. -- The properties in this table are applied to the object -- once when it is spawned.

    -- Refer to the "Registered entities" section for explanations
on_activate = function(self, staticdata, dtime_s) end,
on_deactivate = function(self, removal) end,
on_step = function(self, dtime, moveresult) end,
on_punch = function(self, puncher, time_from_last_punch, tool_capabilities, dir, damage) end,
on_death = function(self, killer) end,
on_rightclick = function(self, clicker) end,
on_attach_child = function(self, child) end,
on_detach_child = function(self, child) end,
on_detach = function(self, parent) end,
get_staticdata = function(self) end,

_custom_field = whatever,
-- You can define arbitrary member variables here (see Item definition
-- for more info) by using a '_' prefix

    } ```

    ABM (ActiveBlockModifier) definition

    Used by minetest.register_abm.

    ```lua { label = "Lava cooling", -- Descriptive label for profiling purposes (optional). -- Definitions with identical labels will be listed as one.

    nodenames = {"default:lava_source"},
-- Apply `action` function to these nodes.
-- `group:groupname` can also be used here.

neighbors = {"default:water_source", "default:water_flowing"},
-- Only apply `action` to nodes that have one of, or any
-- combination of, these neighbors.
-- If left out or empty, any neighbor will do.
-- `group:groupname` can also be used here.

interval = 10.0,
-- Operation interval in seconds

chance = 50,
-- Probability of triggering `action` per-node per-interval is 1.0 / chance (integers only)

min_y = -32768,
max_y = 32767,
-- min and max height levels where ABM will be processed (inclusive)
-- can be used to reduce CPU usage

catch_up = true,
-- If true, catch-up behavior is enabled: The `chance` value is
-- temporarily reduced when returning to an area to simulate time lost
-- by the area being unattended. Note that the `chance` value can often
-- be reduced to 1.

action = function(pos, node, active_object_count, active_object_count_wider),
-- Function triggered for each qualifying node.
-- `active_object_count` is number of active objects in the node's
-- mapblock.
-- `active_object_count_wider` is number of active objects in the node's
-- mapblock plus all 26 neighboring mapblocks. If any neighboring
-- mapblocks are unloaded an estimate is calculated for them based on
-- loaded mapblocks.

    } ```

    LBM (LoadingBlockModifier) definition

    Used by minetest.register_lbm.

    A loading block modifier (LBM) is used to define a function that is called for specific nodes (defined by nodenames) when a mapblock which contains such nodes gets activated (not loaded!)

    ```lua { label = "Upgrade legacy doors", -- Descriptive label for profiling purposes (optional). -- Definitions with identical labels will be listed as one.

    name = "modname:replace_legacy_door",
-- Identifier of the LBM, should follow the modname:<whatever> convention

nodenames = {"default:lava_source"},
-- List of node names to trigger the LBM on.
-- Names of non-registered nodes and groups (as group:groupname)
-- will work as well.

run_at_every_load = false,
-- Whether to run the LBM's action every time a block gets activated,
-- and not only the first time the block gets activated after the LBM
-- was introduced.

action = function(pos, node, dtime_s) end,
-- Function triggered for each qualifying node.
-- `dtime_s` is the in-game time (in seconds) elapsed since the block
-- was last active

    } ```

    Tile definition

    Tile animation definition

    ```lua { type = "vertical_frames",

    aspect_w = 16,
-- Width of a frame in pixels

aspect_h = 16,
-- Height of a frame in pixels

length = 3.0,
-- Full loop length

    }

    { type = "sheet_2d",

    frames_w = 5,
-- Width in number of frames

frames_h = 3,
-- Height in number of frames

frame_length = 0.5,
-- Length of a single frame

    } ```

    Item definition

    Used by minetest.register_node, minetest.register_craftitem, and minetest.register_tool.

    ``lua { description = "", -- Can contain new lines. "\n" has to be used as new line character. -- See also:get_descriptionin [ItemStack`]

    short_description = "",
-- Must not contain new lines.
-- Defaults to nil.
-- Use an [`ItemStack`] to get the short description, e.g.:
--   ItemStack(itemname):get_short_description()

groups = {},
-- key = name, value = rating; rating = <number>.
-- If rating not applicable, use 1.
-- e.g. {wool = 1, fluffy = 3}
--      {soil = 2, outerspace = 1, crumbly = 1}
--      {bendy = 2, snappy = 1},
--      {hard = 1, metal = 1, spikes = 1}

inventory_image = "",
-- Texture shown in the inventory GUI
-- Defaults to a 3D rendering of the node if left empty.

inventory_overlay = "",
-- An overlay texture which is not affected by colorization

wield_image = "",
-- Texture shown when item is held in hand
-- Defaults to a 3D rendering of the node if left empty.

wield_overlay = "",
-- Like inventory_overlay but only used in the same situation as wield_image

wield_scale = {x = 1, y = 1, z = 1},
-- Scale for the item when held in hand

palette = "",
-- An image file containing the palette of a node.
-- You can set the currently used color as the "palette_index" field of
-- the item stack metadata.
-- The palette is always stretched to fit indices between 0 and 255, to
-- ensure compatibility with "colorfacedir" (and similar) nodes.

color = "#ffffffff",
-- Color the item is colorized with. The palette overrides this.

stack_max = 99,
-- Maximum amount of items that can be in a single stack.
-- The default can be changed by the setting `default_stack_max`

range = 4.0,
-- Range of node and object pointing that is possible with this item held
-- Can be overridden with itemstack meta.

liquids_pointable = false,
-- If true, item can point to all liquid nodes (`liquidtype ~= "none"`),
-- even those for which `pointable = false`

pointabilities = {
    nodes = {
        ["default:stone"] = "blocking",
        ["group:leaves"] = false,
    },
    objects = {
        ["modname:entityname"] = true,
        ["group:ghosty"] = true, -- (an armor group)
    },
},
-- Contains lists to override the `pointable` property of nodes and objects.
-- The index can be a node/entity name or a group with the prefix `"group:"`.
-- (For objects `armor_groups` are used and for players the entity name is irrelevant.)
-- If multiple fields fit, the following priority order is applied:
-- 1. value of matching node/entity name
-- 2. `true` for any group
-- 3. `false` for any group
-- 4. `"blocking"` for any group
-- 5. `liquids_pointable` if it is a liquid node
-- 6. `pointable` property of the node or object

light_source = 0,
-- When used for nodes: Defines amount of light emitted by node.
-- Otherwise: Defines texture glow when viewed as a dropped item
-- To set the maximum (14), use the value 'minetest.LIGHT_MAX'.
-- A value outside the range 0 to minetest.LIGHT_MAX causes undefined
-- behavior.

-- See "Tool Capabilities" section for an example including explanation
tool_capabilities = {
    full_punch_interval = 1.0,
    max_drop_level = 0,
    groupcaps = {
        -- For example:
        choppy = {times = {2.50, 1.40, 1.00}, uses = 20, maxlevel = 2},
    },
    damage_groups = {groupname = damage},
    -- Damage values must be between -32768 and 32767 (2^15)

    punch_attack_uses = nil,
    -- Amount of uses this tool has for attacking players and entities
    -- by punching them (0 = infinite uses).
    -- For compatibility, this is automatically set from the first
    -- suitable groupcap using the formula "uses * 3^(maxlevel - 1)".
    -- It is recommend to set this explicitly instead of relying on the
    -- fallback behavior.
},

-- Set wear bar color of the tool by setting color stops and blend mode
-- See "Wear Bar Color" section for further explanation including an example
wear_color = {
    -- interpolation mode: 'constant' or 'linear'
    -- (nil defaults to 'constant')
    blend = "linear",
    color_stops = {
        [0.0] = "#ff0000",
        [0.5] = "#ffff00",
        [1.0] = "#00ff00",
    }
},

node_placement_prediction = nil,
-- If nil and item is node, prediction is made automatically.
-- If nil and item is not a node, no prediction is made.
-- If "" and item is anything, no prediction is made.
-- Otherwise should be name of node which the client immediately places
-- on ground when the player places the item. Server will always update
-- with actual result shortly.

node_dig_prediction = "air",
-- if "", no prediction is made.
-- if "air", node is removed.
-- Otherwise should be name of node which the client immediately places
-- upon digging. Server will always update with actual result shortly.

touch_interaction = <TouchInteractionMode> OR {
    pointed_nothing = <TouchInteractionMode>,
    pointed_node    = <TouchInteractionMode>,
    pointed_object  = <TouchInteractionMode>,
},
  -- Only affects touchscreen clients.
  -- Defines the meaning of short and long taps with the item in hand.
  -- If specified as a table, the field to be used is selected according to
  -- the current `pointed_thing`.
  -- There are three possible TouchInteractionMode values:
  -- * "user"                 (meaning depends on client-side settings)
  -- * "long_dig_short_place" (long tap  = dig, short tap = place)
  -- * "short_dig_long_place" (short tap = dig, long tap  = place)
  -- The default value is "user".

sound = {
    -- Definition of item sounds to be played at various events.
    -- All fields in this table are optional.

    breaks = <SimpleSoundSpec>,
    -- When tool breaks due to wear. Ignored for non-tools

    eat = <SimpleSoundSpec>,
    -- When item is eaten with `minetest.do_item_eat`

    punch_use = <SimpleSoundSpec>,
    -- When item is used with the 'punch/mine' key pointing at a node or entity

    punch_use_air = <SimpleSoundSpec>,
    -- When item is used with the 'punch/mine' key pointing at nothing (air)
},

on_place = function(itemstack, placer, pointed_thing),
-- When the 'place' key was pressed with the item in hand
-- and a node was pointed at.
-- Shall place item and return the leftover itemstack
-- or nil to not modify the inventory.
-- The placer may be any ObjectRef or nil.
-- default: minetest.item_place

on_secondary_use = function(itemstack, user, pointed_thing),
-- Same as on_place but called when not pointing at a node.
-- Function must return either nil if inventory shall not be modified,
-- or an itemstack to replace the original itemstack.
-- The user may be any ObjectRef or nil.
-- default: nil

on_drop = function(itemstack, dropper, pos),
-- Shall drop item and return the leftover itemstack.
-- The dropper may be any ObjectRef or nil.
-- default: minetest.item_drop

on_pickup = function(itemstack, picker, pointed_thing, time_from_last_punch, ...),
-- Called when a dropped item is punched by a player.
-- Shall pick-up the item and return the leftover itemstack or nil to not
-- modify the dropped item.
-- Parameters:
-- * `itemstack`: The `ItemStack` to be picked up.
-- * `picker`: Any `ObjectRef` or `nil`.
-- * `pointed_thing` (optional): The dropped item (a `"__builtin:item"`
--   luaentity) as `type="object"` `pointed_thing`.
-- * `time_from_last_punch, ...` (optional): Other parameters from
--   `luaentity:on_punch`.
-- default: `minetest.item_pickup`

on_use = function(itemstack, user, pointed_thing),
-- default: nil
-- When user pressed the 'punch/mine' key with the item in hand.
-- Function must return either nil if inventory shall not be modified,
-- or an itemstack to replace the original itemstack.
-- e.g. itemstack:take_item(); return itemstack
-- Otherwise, the function is free to do what it wants.
-- The user may be any ObjectRef or nil.
-- The default functions handle regular use cases.

after_use = function(itemstack, user, node, digparams),
-- default: nil
-- If defined, should return an itemstack and will be called instead of
-- wearing out the item (if tool). If returns nil, does nothing.
-- If after_use doesn't exist, it is the same as:
--   function(itemstack, user, node, digparams)
--     itemstack:add_wear(digparams.wear)
--     return itemstack
--   end
-- The user may be any ObjectRef or nil.

_custom_field = whatever,
-- Add your own custom fields. By convention, all custom field names
-- should start with `_` to avoid naming collisions with future engine
-- usage.

    } ```

    Node definition

    Used by minetest.register_node.

    ```lua { -- 

    drawtype = "normal",  -- See "Node drawtypes"

visual_scale = 1.0,
-- Supported for drawtypes "plantlike", "signlike", "torchlike",
-- "firelike", "mesh", "nodebox", "allfaces".
-- For plantlike and firelike, the image will start at the bottom of the
-- node. For torchlike, the image will start at the surface to which the
-- node "attaches". For the other drawtypes the image will be centered
-- on the node.

tiles = {tile definition 1, def2, def3, def4, def5, def6},
-- Textures of node; +Y, -Y, +X, -X, +Z, -Z
-- List can be shortened to needed length.

overlay_tiles = {tile definition 1, def2, def3, def4, def5, def6},
-- Same as `tiles`, but these textures are drawn on top of the base
-- tiles. You can use this to colorize only specific parts of your
-- texture. If the texture name is an empty string, that overlay is not
-- drawn. Since such tiles are drawn twice, it is not recommended to use
-- overlays on very common nodes.

special_tiles = {tile definition 1, Tile definition 2},
-- Special textures of node; used rarely.
-- List can be shortened to needed length.

color = ColorSpec,
-- The node's original color will be multiplied with this color.
-- If the node has a palette, then this setting only has an effect in
-- the inventory and on the wield item.

use_texture_alpha = ...,
-- Specifies how the texture's alpha channel will be used for rendering.
-- possible values:
-- * "opaque": Node is rendered opaque regardless of alpha channel
-- * "clip": A given pixel is either fully see-through or opaque
--           depending on the alpha channel being below/above 50% in value
-- * "blend": The alpha channel specifies how transparent a given pixel
--            of the rendered node is
-- The default is "opaque" for drawtypes normal, liquid and flowingliquid,
-- mesh and nodebox or "clip" otherwise.
-- If set to a boolean value (deprecated): true either sets it to blend
-- or clip, false sets it to clip or opaque mode depending on the drawtype.

palette = "",
-- The node's `param2` is used to select a pixel from the image.
-- Pixels are arranged from left to right and from top to bottom.
-- The node's color will be multiplied with the selected pixel's color.
-- Tiles can override this behavior.
-- Only when `paramtype2` supports palettes.

post_effect_color = "#00000000",
-- Screen tint if a player is inside this node, see `ColorSpec`.
-- Color is alpha-blended over the screen.

post_effect_color_shaded = false,
-- Determines whether `post_effect_color` is affected by lighting.

paramtype = "none",  -- See "Nodes"

paramtype2 = "none",  -- See "Nodes"

place_param2 = 0,
-- Value for param2 that is set when player places node

wallmounted_rotate_vertical = false,
-- If true, place_param2 is nil, and this is a wallmounted node,
-- this node might use the special 90° rotation when placed
-- on the floor or ceiling, depending on the direction.
-- See the explanation about wallmounted for details.
-- Otherwise, the rotation is always the same on vertical placement.

is_ground_content = true,
-- If false, the cave generator and dungeon generator will not carve
-- through this node.
-- Specifically, this stops mod-added nodes being removed by caves and
-- dungeons when those generate in a neighbor mapchunk and extend out
-- beyond the edge of that mapchunk.

sunlight_propagates = false,
-- If true, sunlight will go infinitely through this node

walkable = true,  -- If true, objects collide with node

pointable = true,
-- Can be `true` if it is pointable, `false` if it can be pointed through,
-- or `"blocking"` if it is pointable but not selectable.
-- Clients older than 5.9.0 interpret `pointable = "blocking"` as `pointable = true`.
-- Can be overridden by the `pointabilities` of the held item.
-- A client may be able to point non-pointable nodes, since it isn't checked server-side.

diggable = true,  -- If false, can never be dug

climbable = false,  -- If true, can be climbed on like a ladder

move_resistance = 0,
-- Slows down movement of players through this node (max. 7).
-- If this is nil, it will be equal to liquid_viscosity.
-- Note: If liquid movement physics apply to the node
-- (see `liquid_move_physics`), the movement speed will also be
-- affected by the `movement_liquid_*` settings.

buildable_to = false,  -- If true, placed nodes can replace this node

floodable = false,
-- If true, liquids flow into and replace this node.
-- Warning: making a liquid node 'floodable' will cause problems.

liquidtype = "none",  -- specifies liquid flowing physics
-- * "none":    no liquid flowing physics
-- * "source":  spawns flowing liquid nodes at all 4 sides and below;
--              recommended drawtype: "liquid".
-- * "flowing": spawned from source, spawns more flowing liquid nodes
--              around it until `liquid_range` is reached;
--              will drain out without a source;
--              recommended drawtype: "flowingliquid".
-- If it's "source" or "flowing", then the
-- `liquid_alternative_*` fields _must_ be specified

liquid_alternative_flowing = "",
liquid_alternative_source = "",
-- These fields may contain node names that represent the
-- flowing version (`liquid_alternative_flowing`) and
-- source version (`liquid_alternative_source`) of a liquid.
--
-- Specifically, these fields are required if `liquidtype ~= "none"` or
-- `drawtype == "flowingliquid"`.
--
-- Liquids consist of up to two nodes: source and flowing.
--
-- There are two ways to define a liquid:
-- 1) Source node and flowing node. This requires both fields to be
--    specified for both nodes.
-- 2) Standalone source node (cannot flow). `liquid_alternative_source`
--    must be specified and `liquid_range` must be set to 0.
--
-- Example:
--     liquid_alternative_flowing = "example:water_flowing",
--     liquid_alternative_source = "example:water_source",

liquid_viscosity = 0,
-- Controls speed at which the liquid spreads/flows (max. 7).
-- 0 is fastest, 7 is slowest.
-- By default, this also slows down movement of players inside the node
-- (can be overridden using `move_resistance`)

liquid_renewable = true,
-- If true, a new liquid source can be created by placing two or more
-- sources nearby

liquid_move_physics = nil, -- specifies movement physics if inside node
-- * false: No liquid movement physics apply.
-- * true: Enables liquid movement physics. Enables things like
--   ability to "swim" up/down, sinking slowly if not moving,
--   smoother speed change when falling into, etc. The `movement_liquid_*`
--   settings apply.
-- * nil: Will be treated as true if `liquidtype ~= "none"`
--   and as false otherwise.

air_equivalent = nil,
-- unclear meaning, the engine sets this to true for 'air' and 'ignore'
-- deprecated.

leveled = 0,
-- Only valid for "nodebox" drawtype with 'type = "leveled"'.
-- Allows defining the nodebox height without using param2.
-- The nodebox height is 'leveled' / 64 nodes.
-- The maximum value of 'leveled' is `leveled_max`.

leveled_max = 127,
-- Maximum value for `leveled` (0-127), enforced in
-- `minetest.set_node_level` and `minetest.add_node_level`.
-- Values above 124 might causes collision detection issues.

liquid_range = 8,
-- Maximum distance that flowing liquid nodes can spread around
-- source on flat land;
-- maximum = 8; set to 0 to disable liquid flow

drowning = 0,
-- Player will take this amount of damage if no bubbles are left

damage_per_second = 0,
-- If player is inside node, this damage is caused

node_box = {type = "regular"},  -- See "Node boxes"

connects_to = {},
-- Used for nodebox nodes with the type == "connected".
-- Specifies to what neighboring nodes connections will be drawn.
-- e.g. `{"group:fence", "default:wood"}` or `"default:stone"`

connect_sides = {},
-- Tells connected nodebox nodes to connect only to these sides of this
-- node. possible: "top", "bottom", "front", "left", "back", "right"

mesh = "",
-- File name of mesh when using "mesh" drawtype

selection_box = {
    -- see [Node boxes] for possibilities
},
-- Custom selection box definition. Multiple boxes can be defined.
-- If "nodebox" drawtype is used and selection_box is nil, then node_box
-- definition is used for the selection box.

collision_box = {
    -- see [Node boxes] for possibilities
},
-- Custom collision box definition. Multiple boxes can be defined.
-- If "nodebox" drawtype is used and collision_box is nil, then node_box
-- definition is used for the collision box.

-- Support maps made in and before January 2012
legacy_facedir_simple = false,
legacy_wallmounted = false,

waving = 0,
-- Valid for drawtypes:
-- mesh, nodebox, plantlike, allfaces_optional, liquid, flowingliquid.
-- 1 - wave node like plants (node top moves side-to-side, bottom is fixed)
-- 2 - wave node like leaves (whole node moves side-to-side)
-- 3 - wave node like liquids (whole node moves up and down)
-- Not all models will properly wave.
-- plantlike drawtype can only wave like plants.
-- allfaces_optional drawtype can only wave like leaves.
-- liquid, flowingliquid drawtypes can only wave like liquids.

sounds = {
    -- Definition of node sounds to be played at various events.
    -- All fields in this table are optional.

    footstep = <SimpleSoundSpec>,
    -- If walkable, played when object walks on it. If node is
    -- climbable or a liquid, played when object moves through it.
    -- Sound is played at the base of the object's collision-box.
    -- Gain is multiplied by `0.6`.
    -- For local player, it's played position-less, with normal gain.

    dig = <SimpleSoundSpec> or "__group",
    -- While digging node.
    -- If `"__group"`, then the sound will be
    -- `{name = "default_dig_<groupname>", gain = 0.5}` , where `<groupname>` is the
    -- name of the item's digging group with the fastest digging time.
    -- In case of a tie, one of the sounds will be played (but we
    -- cannot predict which one)
    -- Default value: `"__group"`

    dug = <SimpleSoundSpec>,
    -- Node was dug

    place = <SimpleSoundSpec>,
    -- Node was placed. Also played after falling

    place_failed = <SimpleSoundSpec>,
    -- When node placement failed.
    -- Note: This happens if the _built-in_ node placement failed.
    -- This sound will still be played if the node is placed in the
    -- `on_place` callback manually.

    fall = <SimpleSoundSpec>,
    -- When node starts to fall or is detached
},

drop = "",
-- Name of dropped item when dug.
-- Default dropped item is the node itself.

-- Using a table allows multiple items, drop chances and item filtering:
drop = {
    max_items = 1,
    -- Maximum number of item lists to drop.
    -- The entries in 'items' are processed in order. For each:
    -- Item filtering is applied, chance of drop is applied, if both are
    -- successful the entire item list is dropped.
    -- Entry processing continues until the number of dropped item lists
    -- equals 'max_items'.
    -- Therefore, entries should progress from low to high drop chance.
    items = {
        -- Examples:
        {
            -- 1 in 1000 chance of dropping a diamond.
            -- Default rarity is '1'.
            rarity = 1000,
            items = {"default:diamond"},
        },
        {
            -- Only drop if using an item whose name is identical to one
            -- of these.
            tools = {"default:shovel_mese", "default:shovel_diamond"},
            rarity = 5,
            items = {"default:dirt"},
            -- Whether all items in the dropped item list inherit the
            -- hardware coloring palette color from the dug node.
            -- Default is 'false'.
            inherit_color = true,
        },
        {
            -- Only drop if using an item whose name contains
            -- "default:shovel_" (this item filtering by string matching
            -- is deprecated, use tool_groups instead).
            tools = {"~default:shovel_"},
            rarity = 2,
            -- The item list dropped.
            items = {"default:sand", "default:desert_sand"},
        },
        {
            -- Only drop if using an item in the "magicwand" group, or
            -- an item that is in both the "pickaxe" and the "lucky"
            -- groups.
            tool_groups = {
                "magicwand",
                {"pickaxe", "lucky"}
            },
            items = {"default:coal_lump"},
        },
    },
},

on_construct = function(pos),
-- Node constructor; called after adding node.
-- Can set up metadata and stuff like that.
-- Not called for bulk node placement (i.e. schematics and VoxelManip).
-- Note: Within an on_construct callback, minetest.set_node can cause an
-- infinite loop if it invokes the same callback.
--  Consider using minetest.swap_node instead.
-- default: nil

on_destruct = function(pos),
-- Node destructor; called before removing node.
-- Not called for bulk node placement.
-- default: nil

after_destruct = function(pos, oldnode),
-- Node destructor; called after removing node.
-- Not called for bulk node placement.
-- default: nil

on_flood = function(pos, oldnode, newnode),
-- Called when a liquid (newnode) is about to flood oldnode, if it has
-- `floodable = true` in the nodedef. Not called for bulk node placement
-- (i.e. schematics and VoxelManip) or air nodes. If return true the
-- node is not flooded, but on_flood callback will most likely be called
-- over and over again every liquid update interval.
-- Default: nil
-- Warning: making a liquid node 'floodable' will cause problems.

preserve_metadata = function(pos, oldnode, oldmeta, drops),
-- Called when `oldnode` is about be converted to an item, but before the
-- node is deleted from the world or the drops are added. This is
-- generally the result of either the node being dug or an attached node
-- becoming detached.
-- * `pos`: node position
-- * `oldnode`: node table of node before it was deleted
-- * `oldmeta`: metadata of node before it was deleted, as a metadata table
-- * `drops`: a table of `ItemStack`s, so any metadata to be preserved can
--   be added directly to one or more of the dropped items. See
--   "ItemStackMetaRef".
-- default: `nil`

after_place_node = function(pos, placer, itemstack, pointed_thing),
-- Called after constructing node when node was placed using
-- minetest.item_place_node / minetest.place_node.
-- If return true no item is taken from itemstack.
-- `placer` may be any valid ObjectRef or nil.
-- default: nil

after_dig_node = function(pos, oldnode, oldmetadata, digger),
-- Called after destructing the node when node was dug using
-- `minetest.node_dig` / `minetest.dig_node`.
-- * `pos`: node position
-- * `oldnode`: node table of node before it was dug
-- * `oldmetadata`: metadata of node before it was dug,
--                  as a metadata table
-- * `digger`: ObjectRef of digger
-- default: nil

can_dig = function(pos, [player]),
-- Returns true if node can be dug, or false if not.
-- default: nil

on_punch = function(pos, node, puncher, pointed_thing),
-- default: minetest.node_punch
-- Called when puncher (an ObjectRef) punches the node at pos.
-- By default calls minetest.register_on_punchnode callbacks.

on_rightclick = function(pos, node, clicker, itemstack, pointed_thing),
-- default: nil
-- Called when clicker (an ObjectRef) used the 'place/build' key
-- (not necessarily an actual rightclick)
-- while pointing at the node at pos with 'node' being the node table.
-- itemstack will hold clicker's wielded item.
-- Shall return the leftover itemstack.
-- Note: pointed_thing can be nil, if a mod calls this function.
-- This function does not get triggered by clients <=0.4.16 if the
-- "formspec" node metadata field is set.

on_dig = function(pos, node, digger),
-- default: minetest.node_dig
-- By default checks privileges, wears out item (if tool) and removes node.
-- return true if the node was dug successfully, false otherwise.
-- Deprecated: returning nil is the same as returning true.

on_timer = function(pos, elapsed),
-- default: nil
-- called by NodeTimers, see minetest.get_node_timer and NodeTimerRef.
-- elapsed is the total time passed since the timer was started.
-- return true to run the timer for another cycle with the same timeout
-- value.

on_receive_fields = function(pos, formname, fields, sender),
-- fields = {name1 = value1, name2 = value2, ...}
-- formname should be the empty string; you **must not** use formname.
-- Called when an UI form (e.g. sign text input) returns data.
-- See minetest.register_on_player_receive_fields for more info.
-- default: nil

allow_metadata_inventory_move = function(pos, from_list, from_index, to_list, to_index, count, player),
-- Called when a player wants to move items inside the inventory.
-- Return value: number of items allowed to move.

allow_metadata_inventory_put = function(pos, listname, index, stack, player),
-- Called when a player wants to put something into the inventory.
-- Return value: number of items allowed to put.
-- Return value -1: Allow and don't modify item count in inventory.

allow_metadata_inventory_take = function(pos, listname, index, stack, player),
-- Called when a player wants to take something out of the inventory.
-- Return value: number of items allowed to take.
-- Return value -1: Allow and don't modify item count in inventory.

on_metadata_inventory_move = function(pos, from_list, from_index, to_list, to_index, count, player),
on_metadata_inventory_put = function(pos, listname, index, stack, player),
on_metadata_inventory_take = function(pos, listname, index, stack, player),
-- Called after the actual action has happened, according to what was
-- allowed.
-- No return value.

on_blast = function(pos, intensity),
-- intensity: 1.0 = mid range of regular TNT.
-- If defined, called when an explosion touches the node, instead of
-- removing the node.

mod_origin = "modname",
-- stores which mod actually registered a node
-- If the source could not be determined it contains "??"
-- Useful for getting which mod truly registered something
-- example: if a node is registered as ":othermodname:nodename",
-- nodename will show "othermodname", but mod_origin will say "modname"

    } ```

    Wear Bar Color

    'Wear Bar' is a property of items that defines the coloring of the bar that appears under damaged tools. If it is absent, the default behavior of green-yellow-red is used.

    Wear bar colors definition

    Syntax

    lua { -- 'constant' or 'linear' -- (nil defaults to 'constant') blend = "linear", color_stops = { [0.0] = "#ff0000", [0.5] = "slateblue", [1.0] = {r=0, g=255, b=0, a=150}, } }

    Blend mode blend

    Color stops color_stops

    Specified as ColorSpec color values assigned to float durability keys.

    "Durability" is defined as 1 - (wear / 65535).

    Shortcut usage

    Wear bar color can also be specified as a single ColorSpec instead of a table.

    Crafting recipes

    Crafting converts one or more inputs to one output itemstack of arbitrary count (except for fuels, which don't have an output). The conversion reduces each input ItemStack by 1.

    Craft recipes are registered by minetest.register_craft and use a table format. The accepted parameters are listed below.

    Recipe input items can either be specified by item name (item count = 1) or by group (see "Groups in crafting recipes" for details).

    The following sections describe the types and syntaxes of recipes.

    Shaped

    This is the default recipe type (when no type is specified).

    A shaped recipe takes one or multiple items as input and has a single item stack as output. The input items must be specified in a 2-dimensional matrix (see parameters below) to specify the exact arrangement (the "shape") in which the player must place them in the crafting grid.

    For example, for a 3x3 recipe, the recipes table must have 3 rows and 3 columns.

    In order to craft the recipe, the players' crafting grid must have equal or larger dimensions (both width and height).

    Parameters:

    Examples

    A typical shaped recipe:

    lua -- Stone pickaxe { output = "example:stone_pickaxe", -- A 3x3 recipe which needs 3 stone in the 1st row, -- and 1 stick in the horizontal middle in each of the 2nd and 3nd row. -- The 4 remaining slots have to be empty. recipe = { {"example:stone", "example:stone", "example:stone"}, -- row 1 {"", "example:stick", "" }, -- row 2 {"", "example:stick", "" }, -- row 3 -- ^ column 1 ^ column 2 ^ column 3 }, -- There is no replacements table, so every input item -- will be consumed. }

    Simple replacement example:

    lua -- Wet sponge { output = "example:wet_sponge", -- 1x2 recipe with a water bucket above a dry sponge recipe = { {"example:water_bucket"}, {"example:dry_sponge"}, }, -- When the wet sponge is crafted, the water bucket -- in the input slot is replaced with an empty -- bucket replacements = { {"example:water_bucket", "example:empty_bucket"}, }, }

    Complex replacement example 1:

    lua -- Very wet sponge { output = "example:very_wet_sponge", -- 3x3 recipe with a wet sponge in the center -- and 4 water buckets around it recipe = { {"","example:water_bucket",""}, {"example:water_bucket","example:wet_sponge","example:water_bucket"}, {"","example:water_bucket",""}, }, -- When the wet sponge is crafted, all water buckets -- in the input slot become empty replacements = { -- Without these repetitions, only the first -- water bucket would be replaced. {"example:water_bucket", "example:empty_bucket"}, {"example:water_bucket", "example:empty_bucket"}, {"example:water_bucket", "example:empty_bucket"}, {"example:water_bucket", "example:empty_bucket"}, }, }

    Complex replacement example 2:

    lua -- Magic book: -- 3 magic orbs + 1 book crafts a magic book, -- and the orbs will be replaced with 3 different runes. { output = "example:magic_book", -- 3x2 recipe recipe = { -- 3 items in the group `magic_orb` on top of a book in the middle {"group:magic_orb", "group:magic_orb", "group:magic_orb"}, {"", "example:book", ""}, }, -- When the book is crafted, the 3 magic orbs will be turned into -- 3 runes: ice rune, earth rune and fire rune (from left to right) replacements = { {"group:magic_orb", "example:ice_rune"}, {"group:magic_orb", "example:earth_rune"}, {"group:magic_orb", "example:fire_rune"}, }, }

    Shapeless

    Takes a list of input items (at least 1). The order or arrangement of input items does not matter.

    In order to craft the recipe, the players' crafting grid must have matching or larger count of slots. The grid dimensions do not matter.

    Parameters:

    Example

    lua { -- Craft a mushroom stew from a bowl, a brown mushroom and a red mushroom -- (no matter where in the input grid the items are placed) type = "shapeless", output = "example:mushroom_stew", recipe = { "example:bowl", "example:mushroom_brown", "example:mushroom_red", }, }

    Tool repair

    Syntax:

    {
    type = "toolrepair",
    additional_wear = -0.02, -- multiplier of 65536
}

    Adds a shapeless recipe for every tool that doesn't have the disable_repair=1 group. If this recipe is used, repairing is possible with any crafting grid with at least 2 slots. The player can put 2 equal tools in the craft grid to get one "repaired" tool back. The wear of the output is determined by the wear of both tools, plus a 'repair bonus' given by additional_wear. To reduce the wear (i.e. 'repair'), you want additional_wear to be negative.

    The formula used to calculate the resulting wear is:

    65536 * (1 - ( (1 - tool_1_wear) + (1 - tool_2_wear) + additional_wear))

    The result is rounded and can't be lower than 0. If the result is 65536 or higher, no crafting is possible.

    Cooking

    A cooking recipe has a single input item, a single output item stack and a cooking time. It represents cooking/baking/smelting/etc. items in an oven, furnace, or something similar; the exact meaning is up for games to decide, if they choose to use cooking at all.

    The engine does not implement anything specific to cooking recipes, but the recipes can be retrieved later using minetest.get_craft_result to have a consistent interface across different games/mods.

    Parameters:

    Note: Games and mods are free to re-interpret the cooktime in special cases, e.g. for a super furnace that cooks items twice as fast.

    Example

    Cooking sand to glass in 3 seconds:

    lua { type = "cooking", output = "example:glass", recipe = "example:sand", cooktime = 3.0, }

    Fuel

    A fuel recipe is an item associated with a "burning time" and an optional item replacement. There is no output. This is usually used as fuel for furnaces, ovens, stoves, etc.

    Like with cooking recipes, the engine does not do anything specific with fuel recipes and it's up to games and mods to use them by retrieving them via minetest.get_craft_result.

    Parameters:

    Note: Games and mods are free to re-interpret the burntime in special cases, e.g. for an efficient furnace in which fuels burn twice as long.

    Examples

    Coal lump with a burntime of 20 seconds. Will be consumed when used.

    lua { type = "fuel", recipe = "example:coal_lump", burntime = 20.0, }

    Lava bucket with a burn time of 60 seconds. Will become an empty bucket if used:

    lua { type = "fuel", recipe = "example:lava_bucket", burntime = 60.0, replacements = {{"example:lava_bucket", "example:empty_bucket"}}, }

    Ore definition

    Used by minetest.register_ore.

    See [Ores] section above for essential information.

    ```lua { ore_type = "", -- Supported: "scatter", "sheet", "puff", "blob", "vein", "stratum"

    ore = "",
-- Ore node to place

ore_param2 = 0,
-- Param2 to set for ore (e.g. facedir rotation)

wherein = "",
-- Node to place ore in. Multiple are possible by passing a list.

clust_scarcity = 8 * 8 * 8,
-- Ore has a 1 out of clust_scarcity chance of spawning in a node.
-- If the desired average distance between ores is 'd', set this to
-- d * d * d.

clust_num_ores = 8,
-- Number of ores in a cluster

clust_size = 3,
-- Size of the bounding box of the cluster.
-- In this example, there is a 3 * 3 * 3 cluster where 8 out of the 27
-- nodes are coal ore.

y_min = -31000,
y_max = 31000,
-- Lower and upper limits for ore (inclusive)

flags = "",
-- Attributes for the ore generation, see 'Ore attributes' section above

noise_threshold = 0,
-- If noise is above this threshold, ore is placed. Not needed for a
-- uniform distribution.

noise_params = {
    offset = 0,
    scale = 1,
    spread = {x = 100, y = 100, z = 100},
    seed = 23,
    octaves = 3,
    persistence = 0.7
},
-- NoiseParams structure describing one of the perlin noises used for
-- ore distribution.
-- Needed by "sheet", "puff", "blob" and "vein" ores.
-- Omit from "scatter" ore for a uniform ore distribution.
-- Omit from "stratum" ore for a simple horizontal strata from y_min to
-- y_max.

biomes = {"desert", "rainforest"},
-- List of biomes in which this ore occurs.
-- Occurs in all biomes if this is omitted, and ignored if the Mapgen
-- being used does not support biomes.
-- Can be a list of (or a single) biome names, IDs, or definitions.

-- Type-specific parameters

-- "sheet"
column_height_min = 1,
column_height_max = 16,
column_midpoint_factor = 0.5,

-- "puff"
np_puff_top = {
    offset = 4,
    scale = 2,
    spread = {x = 100, y = 100, z = 100},
    seed = 47,
    octaves = 3,
    persistence = 0.7
},
np_puff_bottom = {
    offset = 4,
    scale = 2,
    spread = {x = 100, y = 100, z = 100},
    seed = 11,
    octaves = 3,
    persistence = 0.7
},

-- "vein"
random_factor = 1.0,

-- "stratum"
np_stratum_thickness = {
    offset = 8,
    scale = 4,
    spread = {x = 100, y = 100, z = 100},
    seed = 17,
    octaves = 3,
    persistence = 0.7
},
stratum_thickness = 8, -- only used if no noise defined

    } ```

    Biome definition

    Used by minetest.register_biome.

    The maximum number of biomes that can be used is 65535. However, using an excessive number of biomes will slow down map generation. Depending on desired performance and computing power the practical limit is much lower.

    ```lua { name = "tundra",

    node_dust = "default:snow",
-- Node dropped onto upper surface after all else is generated

node_top = "default:dirt_with_snow",
depth_top = 1,
-- Node forming surface layer of biome and thickness of this layer

node_filler = "default:permafrost",
depth_filler = 3,
-- Node forming lower layer of biome and thickness of this layer

node_stone = "default:bluestone",
-- Node that replaces all stone nodes between roughly y_min and y_max.

node_water_top = "default:ice",
depth_water_top = 10,
-- Node forming a surface layer in seawater with the defined thickness

node_water = "",
-- Node that replaces all seawater nodes not in the surface layer

node_river_water = "default:ice",
-- Node that replaces river water in mapgens that use
-- default:river_water

node_riverbed = "default:gravel",
depth_riverbed = 2,
-- Node placed under river water and thickness of this layer

node_cave_liquid = "default:lava_source",
node_cave_liquid = {"default:water_source", "default:lava_source"},
-- Nodes placed inside 50% of the medium size caves.
-- Multiple nodes can be specified, each cave will use a randomly
-- chosen node from the list.
-- If this field is left out or 'nil', cave liquids fall back to
-- classic behavior of lava and water distributed using 3D noise.
-- For no cave liquid, specify "air".

node_dungeon = "default:cobble",
-- Node used for primary dungeon structure.
-- If absent, dungeon nodes fall back to the 'mapgen_cobble' mapgen
-- alias, if that is also absent, dungeon nodes fall back to the biome
-- 'node_stone'.
-- If present, the following two nodes are also used.

node_dungeon_alt = "default:mossycobble",
-- Node used for randomly-distributed alternative structure nodes.
-- If alternative structure nodes are not wanted leave this absent.

node_dungeon_stair = "stairs:stair_cobble",
-- Node used for dungeon stairs.
-- If absent, stairs fall back to 'node_dungeon'.

y_max = 31000,
y_min = 1,
-- Upper and lower limits for biome.
-- Alternatively you can use xyz limits as shown below.

max_pos = {x = 31000, y = 128, z = 31000},
min_pos = {x = -31000, y = 9, z = -31000},
-- xyz limits for biome, an alternative to using 'y_min' and 'y_max'.
-- Biome is limited to a cuboid defined by these positions.
-- Any x, y or z field left undefined defaults to -31000 in 'min_pos' or
-- 31000 in 'max_pos'.

vertical_blend = 8,
-- Vertical distance in nodes above 'y_max' over which the biome will
-- blend with the biome above.
-- Set to 0 for no vertical blend. Defaults to 0.

heat_point = 0,
humidity_point = 50,
-- Characteristic temperature and humidity for the biome.
-- These values create 'biome points' on a voronoi diagram with heat and
-- humidity as axes. The resulting voronoi cells determine the
-- distribution of the biomes.
-- Heat and humidity have average values of 50, vary mostly between
-- 0 and 100 but can exceed these values.

    } ```

    Decoration definition

    See [Decoration types]. Used by minetest.register_decoration.

    ```lua { deco_type = "simple", -- Type. "simple", "schematic" or "lsystem" supported

    place_on = "default:dirt_with_grass",
-- Node (or list of nodes) that the decoration can be placed on

sidelen = 8,
-- Size of the square (X / Z) divisions of the mapchunk being generated.
-- Determines the resolution of noise variation if used.
-- If the chunk size is not evenly divisible by sidelen, sidelen is made
-- equal to the chunk size.

fill_ratio = 0.02,
-- The value determines 'decorations per surface node'.
-- Used only if noise_params is not specified.
-- If >= 10.0 complete coverage is enabled and decoration placement uses
-- a different and much faster method.

noise_params = {
    offset = 0,
    scale = 0.45,
    spread = {x = 100, y = 100, z = 100},
    seed = 354,
    octaves = 3,
    persistence = 0.7,
    lacunarity = 2.0,
    flags = "absvalue"
},
-- NoiseParams structure describing the perlin noise used for decoration
-- distribution.
-- A noise value is calculated for each square division and determines
-- 'decorations per surface node' within each division.
-- If the noise value >= 10.0 complete coverage is enabled and
-- decoration placement uses a different and much faster method.

biomes = {"Oceanside", "Hills", "Plains"},
-- List of biomes in which this decoration occurs. Occurs in all biomes
-- if this is omitted, and ignored if the Mapgen being used does not
-- support biomes.
-- Can be a list of (or a single) biome names, IDs, or definitions.

y_min = -31000,
y_max = 31000,
-- Lower and upper limits for decoration (inclusive).
-- These parameters refer to the Y coordinate of the 'place_on' node.

spawn_by = "default:water",
-- Node (or list of nodes) that the decoration only spawns next to.
-- Checks the 8 neighboring nodes on the same height,
-- and also the ones at the height plus the check_offset, excluding both center nodes.

check_offset = -1,
-- Specifies the offset that spawn_by should also check
-- The default value of -1 is useful to e.g check for water next to the base node.
-- 0 disables additional checks, valid values: {-1, 0, 1}

num_spawn_by = 1,
-- Number of spawn_by nodes that must be surrounding the decoration
-- position to occur.
-- If absent or -1, decorations occur next to any nodes.

flags = "liquid_surface, force_placement, all_floors, all_ceilings",
-- Flags for all decoration types.
-- "liquid_surface": Instead of placement on the highest solid surface
--   in a mapchunk column, placement is on the highest liquid surface.
--   Placement is disabled if solid nodes are found above the liquid
--   surface.
-- "force_placement": Nodes other than "air" and "ignore" are replaced
--   by the decoration.
-- "all_floors", "all_ceilings": Instead of placement on the highest
--   surface in a mapchunk the decoration is placed on all floor and/or
--   ceiling surfaces, for example in caves and dungeons.
--   Ceiling decorations act as an inversion of floor decorations so the
--   effect of 'place_offset_y' is inverted.
--   Y-slice probabilities do not function correctly for ceiling
--   schematic decorations as the behavior is unchanged.
--   If a single decoration registration has both flags the floor and
--   ceiling decorations will be aligned vertically.

----- Simple-type parameters

decoration = "default:grass",
-- The node name used as the decoration.
-- If instead a list of strings, a randomly selected node from the list
-- is placed as the decoration.

height = 1,
-- Decoration height in nodes.
-- If height_max is not 0, this is the lower limit of a randomly
-- selected height.

height_max = 0,
-- Upper limit of the randomly selected height.
-- If absent, the parameter 'height' is used as a constant.

param2 = 0,
-- Param2 value of decoration nodes.
-- If param2_max is not 0, this is the lower limit of a randomly
-- selected param2.

param2_max = 0,
-- Upper limit of the randomly selected param2.
-- If absent, the parameter 'param2' is used as a constant.

place_offset_y = 0,
-- Y offset of the decoration base node relative to the standard base
-- node position.
-- Can be positive or negative. Default is 0.
-- Effect is inverted for "all_ceilings" decorations.
-- Ignored by 'y_min', 'y_max' and 'spawn_by' checks, which always refer
-- to the 'place_on' node.

----- Schematic-type parameters

schematic = "foobar.mts",
-- If schematic is a string, it is the filepath relative to the current
-- working directory of the specified Minetest schematic file.
-- Could also be the ID of a previously registered schematic.

schematic = {
    size = {x = 4, y = 6, z = 4},
    data = {
        {name = "default:cobble", param1 = 255, param2 = 0},
        {name = "default:dirt_with_grass", param1 = 255, param2 = 0},
        {name = "air", param1 = 255, param2 = 0},
          ...
    },
    yslice_prob = {
        {ypos = 2, prob = 128},
        {ypos = 5, prob = 64},
          ...
    },
},
-- Alternative schematic specification by supplying a table. The fields
-- size and data are mandatory whereas yslice_prob is optional.
-- See 'Schematic specifier' for details.

replacements = {["oldname"] = "convert_to", ...},
-- Map of node names to replace in the schematic after reading it.

flags = "place_center_x, place_center_y, place_center_z",
-- Flags for schematic decorations. See 'Schematic attributes'.

rotation = "90",
-- Rotation can be "0", "90", "180", "270", or "random"

place_offset_y = 0,
-- If the flag 'place_center_y' is set this parameter is ignored.
-- Y offset of the schematic base node layer relative to the 'place_on'
-- node.
-- Can be positive or negative. Default is 0.
-- Effect is inverted for "all_ceilings" decorations.
-- Ignored by 'y_min', 'y_max' and 'spawn_by' checks, which always refer
-- to the 'place_on' node.

----- L-system-type parameters

treedef = {},
-- Same as for `minetest.spawn_tree`.
-- See section [L-system trees] for more details.

    } ```

    Chat command definition

    Used by minetest.register_chatcommand.

    Specifies the function to be called and the privileges required when a player issues the command. A help message that is the concatenation of the params and description fields is shown when the "/help" chatcommand is issued.

    ```lua { params = "", -- Short parameter description. See the below note.

    description = "",
-- General description of the command's purpose.

privs = {},
-- Required privileges to run. See `minetest.check_player_privs()` for
-- the format and see [Privileges] for an overview of privileges.

func = function(name, param),
-- Called when command is run.
-- * `name` is the name of the player who issued the command.
-- * `param` is a string with the full arguments to the command.
-- Returns a boolean for success and a string value.
-- The string is shown to the issuing player upon exit of `func` or,
-- if `func` returns `false` and no string, the help message is shown.

    } ```

    Note that in params, the conventional use of symbols is as follows:

    Example:

    ```lua { params = " ",

    description = "Remove privilege from player",

privs = {privs=true},  -- Require the "privs" privilege to run

func = function(name, param),

    } ```

    Privilege definition

    Used by minetest.register_privilege.

    ```lua { description = "", -- Privilege description

    give_to_singleplayer = true,
-- Whether to grant the privilege to singleplayer.

give_to_admin = true,
-- Whether to grant the privilege to the server admin.
-- Uses value of 'give_to_singleplayer' by default.

on_grant = function(name, granter_name),
-- Called when given to player 'name' by 'granter_name'.
-- 'granter_name' will be nil if the priv was granted by a mod.

on_revoke = function(name, revoker_name),
-- Called when taken from player 'name' by 'revoker_name'.
-- 'revoker_name' will be nil if the priv was revoked by a mod.

-- Note that the above two callbacks will be called twice if a player is
-- responsible, once with the player name, and then with a nil player
-- name.
-- Return true in the above callbacks to stop register_on_priv_grant or
-- revoke being called.

    } ```

    Detached inventory callbacks

    Used by minetest.create_detached_inventory.

    ```lua { allow_move = function(inv, from_list, from_index, to_list, to_index, count, player), -- Called when a player wants to move items inside the inventory. -- Return value: number of items allowed to move.

    allow_put = function(inv, listname, index, stack, player),
-- Called when a player wants to put something into the inventory.
-- Return value: number of items allowed to put.
-- Return value -1: Allow and don't modify item count in inventory.

allow_take = function(inv, listname, index, stack, player),
-- Called when a player wants to take something out of the inventory.
-- Return value: number of items allowed to take.
-- Return value -1: Allow and don't modify item count in inventory.

on_move = function(inv, from_list, from_index, to_list, to_index, count, player),
on_put = function(inv, listname, index, stack, player),
on_take = function(inv, listname, index, stack, player),
-- Called after the actual action has happened, according to what was
-- allowed.
-- No return value.

    } ```

    HUD Definition

    Since most values have multiple different functions, please see the documentation in [HUD] section.

    Used by ObjectRef:hud_add. Returned by ObjectRef:hud_get.

    ```lua { type = "image", -- Type of element, can be "compass", "hotbar" (46 ¹), "image", "image_waypoint", -- "inventory", "minimap" (44 ¹), "statbar", "text" or "waypoint" -- ¹: minimal protocol version for client-side support -- If undefined "text" will be used.

    hud_elem_type = "image",
-- Deprecated, same as `type`.
-- In case both are specified `type` will be used.

position = {x=0.5, y=0.5},
-- Top left corner position of element

name = "<name>",

scale = {x = 1, y = 1},

text = "<text>",

text2 = "<text>",

number = 0,

item = 0,

direction = 0,
-- Direction: 0: left-right, 1: right-left, 2: top-bottom, 3: bottom-top

alignment = {x=0, y=0},

offset = {x=0, y=0},

world_pos = {x=0, y=0, z=0},

size = {x=0, y=0},

z_index = 0,
-- Z index: lower z-index HUDs are displayed behind higher z-index HUDs

style = 0,

    } ```

    Particle definition

    Used by minetest.add_particle.

    ```lua { pos = {x=0, y=0, z=0}, velocity = {x=0, y=0, z=0}, acceleration = {x=0, y=0, z=0}, -- Spawn particle at pos with velocity and acceleration

    expirationtime = 1,
-- Disappears after expirationtime seconds

size = 1,
-- Scales the visual size of the particle texture.
-- If `node` is set, size can be set to 0 to spawn a randomly-sized
-- particle (just like actual node dig particles).

collisiondetection = false,
-- If true collides with `walkable` nodes and, depending on the
-- `object_collision` field, objects too.

collision_removal = false,
-- If true particle is removed when it collides.
-- Requires collisiondetection = true to have any effect.

object_collision = false,
-- If true particle collides with objects that are defined as
-- `physical = true,` and `collide_with_objects = true,`.
-- Requires collisiondetection = true to have any effect.

vertical = false,
-- If true faces player using y axis only

texture = "image.png",
-- The texture of the particle
-- v5.6.0 and later: also supports the table format described in the
-- following section, but due to a bug this did not take effect
-- (beyond the texture name).
-- v5.9.0 and later: fixes the bug.
-- Note: "texture.animation" is ignored here. Use "animation" below instead.

playername = "singleplayer",
-- Optional, if specified spawns particle only on the player's client

animation = {Tile Animation definition},
-- Optional, specifies how to animate the particle texture

glow = 0
-- Optional, specify particle self-luminescence in darkness.
-- Values 0-14.

node = {name = "ignore", param2 = 0},
-- Optional, if specified the particle will have the same appearance as
-- node dig particles for the given node.
-- `texture` and `animation` will be ignored if this is set.

node_tile = 0,
-- Optional, only valid in combination with `node`
-- If set to a valid number 1-6, specifies the tile from which the
-- particle texture is picked.
-- Otherwise, the default behavior is used. (currently: any random tile)

drag = {x=0, y=0, z=0},
-- v5.6.0 and later: Optional drag value, consult the following section
-- Note: Only a vector is supported here. Alternative forms like a single
-- number are not supported.

jitter = {min = ..., max = ..., bias = 0},
-- v5.6.0 and later: Optional jitter range, consult the following section

bounce = {min = ..., max = ..., bias = 0},
-- v5.6.0 and later: Optional bounce range, consult the following section

    } ```

    ParticleSpawner definition

    Used by minetest.add_particlespawner.

    Before v5.6.0, particlespawners used a different syntax and had a more limited set of features. Definition fields that are the same in both legacy and modern versions are shown in the next listing, and the fields that are used by legacy versions are shown separated by a comment; the modern fields are too complex to compactly describe in this manner and are documented after the listing.

    The older syntax can be used in combination with the newer syntax (e.g. having minpos, maxpos, and pos all set) to support older servers. On newer servers, the new syntax will override the older syntax; on older servers, the newer syntax will be ignored.

    ```lua { ------------------- -- Common fields -- ------------------- -- (same name and meaning in both new and legacy syntax)

    amount = 1,
-- Number of particles spawned over the time period `time`.

time = 1,
-- Lifespan of spawner in seconds.
-- If time is 0 spawner has infinite lifespan and spawns the `amount` on
-- a per-second basis.

collisiondetection = false,
-- If true collide with `walkable` nodes and, depending on the
-- `object_collision` field, objects too.

collision_removal = false,
-- If true particles are removed when they collide.
-- Requires collisiondetection = true to have any effect.

object_collision = false,
-- If true particles collide with objects that are defined as
-- `physical = true,` and `collide_with_objects = true,`.
-- Requires collisiondetection = true to have any effect.

attached = ObjectRef,
-- If defined, particle positions, velocities and accelerations are
-- relative to this object's position and yaw

vertical = false,
-- If true face player using y axis only

texture = "image.png",
-- The texture of the particle
-- v5.6.0 and later: also supports the table format described in the
-- following section.

playername = "singleplayer",
-- Optional, if specified spawns particles only on the player's client

animation = {Tile Animation definition},
-- Optional, specifies how to animate the particles' texture
-- v5.6.0 and later: set length to -1 to synchronize the length
-- of the animation with the expiration time of individual particles.
-- (-2 causes the animation to be played twice, and so on)

glow = 0,
-- Optional, specify particle self-luminescence in darkness.
-- Values 0-14.

node = {name = "ignore", param2 = 0},
-- Optional, if specified the particles will have the same appearance as
-- node dig particles for the given node.
-- `texture` and `animation` will be ignored if this is set.

node_tile = 0,
-- Optional, only valid in combination with `node`
-- If set to a valid number 1-6, specifies the tile from which the
-- particle texture is picked.
-- Otherwise, the default behavior is used. (currently: any random tile)

-------------------
-- Legacy fields --
-------------------

minpos = {x=0, y=0, z=0},
maxpos = {x=0, y=0, z=0},
minvel = {x=0, y=0, z=0},
maxvel = {x=0, y=0, z=0},
minacc = {x=0, y=0, z=0},
maxacc = {x=0, y=0, z=0},
minexptime = 1,
maxexptime = 1,
minsize = 1,
maxsize = 1,
-- The particles' properties are random values between the min and max
-- values.
-- applies to: pos, velocity, acceleration, expirationtime, size
-- If `node` is set, min and maxsize can be set to 0 to spawn
-- randomly-sized particles (just like actual node dig particles).

    } ```

    Modern definition fields

    After v5.6.0, spawner properties can be defined in several different ways depending on the level of control you need. pos for instance can be set as a single vector, in which case all particles will appear at that exact point throughout the lifetime of the spawner. Alternately, it can be specified as a min-max pair, specifying a cubic range the particles can appear randomly within. Finally, some properties can be animated by suffixing their key with _tween (e.g. pos_tween) and supplying a tween table.

    The following definitions are all equivalent, listed in order of precedence from lowest (the legacy syntax) to highest (tween tables). If multiple forms of a property definition are present, the highest-precedence form will be selected and all lower-precedence fields will be ignored, allowing for graceful degradation in older clients).

    ```lua { -- old syntax maxpos = {x = 0, y = 0, z = 0}, minpos = {x = 0, y = 0, z = 0},

    -- absolute value pos = 0, -- all components of every particle's position vector will be set to this -- value

    -- vec3 pos = vector.new(0,0,0), -- all particles will appear at this exact position throughout the lifetime -- of the particlespawner

    -- vec3 range pos = { -- the particle will appear at a position that is picked at random from -- within a cubic range

        min = vector.new(0,0,0),
    -- `min` is the minimum value this property will be set to in particles
    -- spawned by the generator

    max = vector.new(0,0,0),
    -- `max` is the minimum value this property will be set to in particles
    -- spawned by the generator

    bias = 0,
    -- when `bias` is 0, all random values are exactly as likely as any
    -- other. when it is positive, the higher it is, the more likely values
    -- will appear towards the minimum end of the allowed spectrum. when
    -- it is negative, the lower it is, the more likely values will appear
    -- towards the maximum end of the allowed spectrum. the curve is
    -- exponential and there is no particular maximum or minimum value
},

-- tween table
pos_tween = {...},
-- a tween table should consist of a list of frames in the same form as the
-- untweened pos property above, which the engine will interpolate between,
-- and optionally a number of properties that control how the interpolation
-- takes place. currently **only two frames**, the first and the last, are
-- used, but extra frames are accepted for the sake of forward compatibility.
-- any of the above definition styles can be used here as well in any combination
-- supported by the property type

pos_tween = {
    style = "fwd",
    -- linear animation from first to last frame (default)
    style = "rev",
    -- linear animation from last to first frame
    style = "pulse",
    -- linear animation from first to last then back to first again
    style = "flicker",
    -- like "pulse", but slightly randomized to add a bit of stutter

    reps = 1,
    -- number of times the animation is played over the particle's lifespan

    start = 0.0,
    -- point in the spawner's lifespan at which the animation begins. 0 is
    -- the very beginning, 1 is the very end

    -- frames can be defined in a number of different ways, depending on the
    -- underlying type of the property. for now, all but the first and last
    -- frame are ignored

    -- frames

        -- floats
        0, 0,

        -- vec3s
        vector.new(0,0,0),
        vector.new(0,0,0),

        -- vec3 ranges
        { min = vector.new(0,0,0), max = vector.new(0,0,0), bias = 0 },
        { min = vector.new(0,0,0), max = vector.new(0,0,0), bias = 0 },

        -- mixed
        0, { min = vector.new(0,0,0), max = vector.new(0,0,0), bias = 0 },
},

    } ```

    All of the properties that can be defined in this way are listed in the next section, along with the datatypes they accept.

    List of particlespawner properties

    All properties in this list of type "vec3 range", "float range" or "vec3" can be animated with *_tween tables. For example, jitter can be tweened by setting a jitter_tween table instead of (or in addition to) a jitter table/value.

    In this section, a float range is a table defined as so: { min = A, max = B } A and B are your supplemented values. For a vec3 range this means they are vectors. Types used are defined in the previous section.

    Textures

    In versions before v5.6.0, particle/particlespawner textures could only be specified as a single texture string. After v5.6.0, textures can now be specified as a table as well. This table contains options that allow simple animations to be applied to the texture.

    ```lua texture = { name = "mymod_particle_texture.png", -- the texture specification string

    alpha = 1.0,
-- controls how visible the particle is; at 1.0 the particle is fully
-- visible, at 0, it is completely invisible.

alpha_tween = {1, 0},
-- can be used instead of `alpha` to animate the alpha value over the
-- particle's lifetime. these tween tables work identically to the tween
-- tables used in particlespawner properties, except that time references
-- are understood with respect to the particle's lifetime, not the
-- spawner's. {1,0} fades the particle out over its lifetime.

scale = 1,
scale = {x = 1, y = 1},
-- scales the texture onscreen

scale_tween = {
    {x = 1, y = 1},
    {x = 0, y = 1},
},
-- animates the scale over the particle's lifetime. works like the
-- alpha_tween table, but can accept two-dimensional vectors as well as
-- integer values. the example value would cause the particle to shrink
-- in one dimension over the course of its life until it disappears

blend = "alpha",
-- (default) blends transparent pixels with those they are drawn atop
-- according to the alpha channel of the source texture. useful for
-- e.g. material objects like rocks, dirt, smoke, or node chunks
blend = "add",
-- adds the value of pixels to those underneath them, modulo the sources
-- alpha channel. useful for e.g. bright light effects like sparks or fire
blend = "screen",
-- like "add" but less bright. useful for subtler light effects. note that
-- this is NOT formally equivalent to the "screen" effect used in image
-- editors and compositors, as it does not respect the alpha channel of
-- of the image being blended
blend = "sub",
-- the inverse of "add"; the value of the source pixel is subtracted from
-- the pixel underneath it. a white pixel will turn whatever is underneath
-- it black; a black pixel will be "transparent". useful for creating
-- darkening effects

animation = {Tile Animation definition},
-- overrides the particlespawner's global animation property for a single
-- specific texture

    } ```

    For particlespawners, it is also possible to set the texpool property instead of a single texture definition. A texpool consists of a list of possible particle textures. Every time a particle is spawned, the engine will pick a texture at random from the texpool and assign it as that particle's texture. You can also specify a texture in addition to a texpool; the texture value will be ignored on newer clients but will be sent to older (pre-v5.6.0) clients that do not implement texpools.

    ```lua texpool = { "mymod_particle_texture.png"; { name = "mymod_spark.png", alpha_tween = {1, 0} }, { name = "mymod_dust.png", alpha = 0.3, scale = 1.5, animation = { type = "vertical_frames", aspect_w = 16, aspect_h = 16,

            length = 3,
        -- the animation lasts for 3s and then repeats
        length = -3,
        -- repeat the animation three times over the particle's lifetime
        -- (post-v5.6.0 clients only)
  },
},

    } ```

    List of animatable texture properties

    While animated particlespawner values vary over the course of the particlespawner's lifetime, animated texture properties vary over the lifespans of the individual particles spawned with that texture. So a particle with the texture property

    lua alpha_tween = { 0.0, 1.0, style = "pulse", reps = 4, }

    would be invisible at its spawning, pulse visible four times throughout its lifespan, and then vanish again before expiring.

    HTTPRequest definition

    Used by HTTPApiTable.fetch and HTTPApiTable.fetch_async.

    ```lua { url = "http://example.org",

    timeout = 10,
-- Timeout for request to be completed in seconds. Default depends on engine settings.

method = "GET", "POST", "PUT" or "DELETE"
-- The http method to use. Defaults to "GET".

data = "Raw request data string" OR {field1 = "data1", field2 = "data2"},
-- Data for the POST, PUT or DELETE request.
-- Accepts both a string and a table. If a table is specified, encodes
-- table as x-www-form-urlencoded key-value pairs.

user_agent = "ExampleUserAgent",
-- Optional, if specified replaces the default minetest user agent with
-- given string

extra_headers = { "Accept-Language: en-us", "Accept-Charset: utf-8" },
-- Optional, if specified adds additional headers to the HTTP request.
-- You must make sure that the header strings follow HTTP specification
-- ("Key: Value").

multipart = boolean
-- Optional, if true performs a multipart HTTP request.
-- Default is false.
-- Post only, data must be array

post_data = "Raw POST request data string" OR {field1 = "data1", field2 = "data2"},
-- Deprecated, use `data` instead. Forces `method = "POST"`.

    } ```

    HTTPRequestResult definition

    Passed to HTTPApiTable.fetch callback. Returned by HTTPApiTable.fetch_async_get.

    ```lua { completed = true, -- If true, the request has finished (either succeeded, failed or timed -- out)

    succeeded = true,
-- If true, the request was successful

timeout = false,
-- If true, the request timed out

code = 200,
-- HTTP status code

data = "response"

    } ```

    Authentication handler definition

    Used by minetest.register_authentication_handler.

    ``lua { get_auth = function(name), -- Get authentication data for existing playername(nilif player -- doesn't exist). -- Returns following structure: --{password=, privileges=, last_login=}`

    create_auth = function(name, password),
-- Create new auth data for player `name`.
-- Note that `password` is not plain-text but an arbitrary
-- representation decided by the engine.

delete_auth = function(name),
-- Delete auth data of player `name`.
-- Returns boolean indicating success (false if player is nonexistent).

set_password = function(name, password),
-- Set password of player `name` to `password`.
-- Auth data should be created if not present.

set_privileges = function(name, privileges),
-- Set privileges of player `name`.
-- `privileges` is in table form: keys are privilege names, values are `true`;
-- auth data should be created if not present.

reload = function(),
-- Reload authentication data from the storage location.
-- Returns boolean indicating success.

record_login = function(name),
-- Called when player joins, used for keeping track of last_login

iterate = function(),
-- Returns an iterator (use with `for` loops) for all player names
-- currently in the auth database

    } ```

    Bit Library

    Functions: bit.tobit, bit.tohex, bit.bnot, bit.band, bit.bor, bit.bxor, bit.lshift, bit.rshift, bit.arshift, bit.rol, bit.ror, bit.bswap

    See http://bitop.luajit.org/ for advanced information.

    Error Handling

    When an error occurs that is not caught, Minetest calls the function minetest.error_handler with the error object as its first argument. The second argument is the stack level where the error occurred. The return value is the error string that should be shown. By default this is a backtrace from debug.traceback. If the error object is not a string, it is first converted with tostring before being displayed. This means that you can use tables as error objects so long as you give them __tostring metamethods.

    You can override minetest.error_handler. You should call the previous handler with the correct stack level in your implementation.

    Generated in ~9000 seconds using ReadTheBlocks