X-Git-Url: https://git.librecmc.org/?a=blobdiff_plain;f=doc%2Flua_api.txt;h=ae8263c6c3a4b6eed9560ce1c02ecd0458547ed4;hb=80dc961d24e1964e25d57039ddb2ba639f9f4d22;hp=7b956dc74263c05c9d69f33119f9616a50f2c0c7;hpb=6de83a2756316653ed67b23bbeb0fb43aa2a68c6;p=oweals%2Fminetest.git diff --git a/doc/lua_api.txt b/doc/lua_api.txt index 7b956dc74..ae8263c6c 100644 --- a/doc/lua_api.txt +++ b/doc/lua_api.txt @@ -1,4 +1,4 @@ -Minetest Lua Modding API Reference 0.4.15 +Minetest Lua Modding API Reference 0.4.16 ========================================= * More information at * Developer Wiki: @@ -172,8 +172,8 @@ The main Lua script. Running this script should register everything it wants to register. Subsequent execution depends on minetest calling the registered callbacks. -`minetest.setting_get(name)` and `minetest.setting_getbool(name)` can be used -to read custom or existing settings at load time, if necessary. +`minetest.settings` can be used to read custom or existing settings at load +time, if necessary. (See `Settings`) ### `models` Models for entities or meshnodes. @@ -186,7 +186,11 @@ Naming convention for registered textual names ---------------------------------------------- Registered names should generally be in this format: - "modname:" ( can have characters a-zA-Z0-9_) + `modname:` + +`` can have these characters: + + a-zA-Z0-9_ This is to prevent conflicting names from corrupting maps and is enforced by the mod loader. @@ -209,7 +213,7 @@ The `:` prefix can also be used for maintaining backwards compatibility. ### Aliases Aliases can be added by using `minetest.register_alias(name, convert_to)` or -`minetest.register_alias_force(name, convert_to). +`minetest.register_alias_force(name, convert_to)`. This will make Minetest to convert things called name to things called `convert_to`. @@ -309,10 +313,10 @@ Example: default_sandstone.png^[resize:16x16 #### `[opacity:` - Makes the base image transparent according to the given ratio. - r must be between 0 and 255. - 0 means totally transparent. - 255 means totally opaque. +Makes the base image transparent according to the given ratio. + +`r` must be between 0 and 255. +0 means totally transparent. 255 means totally opaque. Example: @@ -426,6 +430,167 @@ 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. +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 methods. 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: +* 16x16 palette, index = 0: the top left corner +* 16x16 palette, index = 4: the fifth pixel in the first row +* 16x16 palette, index = 16: the pixel below the top left corner +* 16x16 palette, index = 255: the bottom right corner +* 2 (width)x4 (height) palette, index=31: the top left corner. + The palette has 8 pixels, so each pixel is stretched to 32 pixels, + to ensure the total 256 pixels. +* 2x4 palette, index=32: the top right corner +* 2x4 palette, index=63: the top right corner +* 2x4 palette, index=64: the pixel below the top left corner + +#### 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 `drawtype`: +* `drawtype = "color"` for nodes which use their full `param2` for + palette indexing. These nodes can have 256 different colors. + The palette should contain 256 pixels. +* `drawtype = "colorwallmounted"` for nodes which use the first + five bits (most significant) of `param2` for palette indexing. + The remaining three bits are describing rotation, as in `wallmounted` + draw type. Division by 8 yields the palette index (without stretching the + palette). These nodes can have 32 different colors, and the palette + should contain 32 pixels. + Examples: + * `param2 = 17` is 2 * 8 + 1, so the rotation is 1 and the third (= 2 + 1) + pixel will be picked from the palette. + * `param2 = 35` is 4 * 8 + 3, so the rotation is 3 and the fifth (= 4 + 1) + pixel will be picked from the palette. +* `drawtype = "colorfacedir"` for nodes which use the first + three bits of `param2` for palette indexing. The remaining + five bits are describing rotation, as in `facedir` draw type. + Division by 32 yields the palette index (without stretching the + palette). These nodes can have 8 different colors, and the + palette should contain 8 pixels. + Examples: + * `param2 = 17` is 0 * 32 + 17, so the rotation is 17 and the + first (= 0 + 1) pixel will be picked from the palette. + * `param2 = 35` is 1 * 32 + 3, so the rotation is 3 and the + second (= 1 + 1) pixel will be picked from the palette. + +To colorize a node on the map, set its `param2` value (according +to the node's draw type). + +### Conversion between nodes in the inventory and the 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, you +currently must manually convert between it and the node's `param2` with +custom `on_place` and `on_dig` callbacks. + +### Colored items in craft recipes +Craft recipes only support item strings, but fortunately item strings +can also contain metadata. Example craft recipe registration: + + local stack = ItemStack("wool:block") + dyed:get_meta():set_int("palette_index", 3) -- add index + minetest.register_craft({ + output = dyed:to_string(), -- convert to string + type = "shapeless", + recipe = { + "wool:block", + "dye:red", + }, + }) + +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. + +To define an 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): + + 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", tileable_vertical = false}}, + -- Global color, used in inventory + color = "green", + -- Palette in the world + paramtype2 = "color", + palette = "default_foilage.png", + }) + Sounds ------ Only Ogg Vorbis files are supported. @@ -456,11 +621,13 @@ Examples of sound parameter tables: -- Play locationless on all clients { gain = 1.0, -- default + fade = 0.0, -- default, change to a value > 0 to fade the sound in } -- Play locationless to one player { to_player = name, gain = 1.0, -- default + fade = 0.0, -- default, change to a value > 0 to fade the sound in } -- Play locationless to one player, looped { @@ -513,7 +680,7 @@ the global `minetest.registered_*` tables. * `minetest.unregister_item(name)` * Unregisters the item name from engine, and deletes the entry with key * `name` from `minetest.registered_items` and from the associated item - * table according to its nature: minetest.registered_nodes[] etc + * table according to its nature: `minetest.registered_nodes[]` etc * `minetest.register_biome(biome definition)` * returns an integer uniquely identifying the registered biome @@ -591,9 +758,9 @@ They are represented by a table: {name="name", param1=num, param2=num} -`param1` and `param2` are 8-bit integers. The engine uses them for certain -automated functions. If you don't use these functions, you can use them to -store arbitrary values. +`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. The functions of `param1` and `param2` are determined by certain fields in the node definition: @@ -658,15 +825,10 @@ node definition: The first five bits of `param2` tells which color is picked from the palette. The palette should have 32 pixels. - collision_box = { - type = "fixed", - fixed = { - {-0.5, -0.5, -0.5, 0.5, 0.5, 0.5}, - }, - }, - ^ defines list of collision boxes for the node. If empty, collision boxes - will be the same as nodeboxes, in case of any other nodes will be full cube - as in the example above. + paramtype2 == "glasslikeliquidlevel" + ^ Only valid for "glasslike_framed" or "glasslike_framed_optional" drawtypes. + param2 defines 64 levels of internal liquid. + Liquid texture is defined using `special_tiles = {"modname_tilename.png"},` Nodes can also contain extra data. See "Node Metadata". @@ -817,6 +979,7 @@ If no flags are specified (or defaults is), 2D noise is eased and 3D noise is no Accumulates the absolute value of each noise gradient result. Noise parameters format example for 2D or 3D perlin noise or perlin noise maps: + np_terrain = { offset = 0, scale = 1, @@ -827,8 +990,8 @@ Noise parameters format example for 2D or 3D perlin noise or perlin noise maps: lacunarity = 2.0, flags = "defaults, absvalue" } - ^ A single noise parameter table can be used to get 2D or 3D noise, - when getting 2D noise spread.z is ignored. + ^ A single noise parameter table can be used to get 2D or 3D noise, + when getting 2D noise spread.z is ignored. Ore types @@ -900,14 +1063,15 @@ to small changes. The following is a decent set of parameters to work from: }, noise_threshold = 1.6 -WARNING: Use this ore type *very* sparingly since it is ~200x more +**WARNING**: Use this ore type *very* sparingly since it is ~200x more computationally expensive than any other ore. Ore attributes -------------- See section "Flag Specifier Format". -Currently supported flags: `absheight` +Currently supported flags: +`absheight`, `puff_cliffs`, `puff_additive_composition`. ### `absheight` Also produce this same ore between the height range of `-y_max` and `-y_min`. @@ -963,6 +1127,7 @@ in the form of a table. This table specifies the following fields: previous contents (default: false) About probability values: + * A probability value of `0` or `1` means that node will never appear (0% chance). * A probability value of `254` or `255` means the node will always appear (100% chance). * If the probability value `p` is greater than `1`, then there is a @@ -1117,16 +1282,32 @@ There are three kinds of items: nodes, tools and craftitems. things according to `tool_capabilities`. * Craftitem (`register_craftitem`): A miscellaneous item. +### Amount and wear +All item stacks have an amount between 0 to 65535. It is 1 by +default. Tool item stacks can not have an amount greater than 1. + +Tools use a wear (=damage) value ranging from 0 to 65535. The +value 0 is the default and used is for unworn tools. The values +1 to 65535 are used for worn tools, where a higher value stands for +a higher wear. Non-tools always have a wear value of 0. + ### Item formats Items and item stacks can exist in three formats: Serializes, table format and `ItemStack`. #### Serialized -This is called "stackstring" or "itemstring": +This is called "stackstring" or "itemstring". It is a simple string with +1-3 components: the full item identifier, an optional amount and an optional +wear value. Syntax: + + [[ ]] -* e.g. `'default:dirt 5'` -* e.g. `'default:pick_wood 21323'` -* e.g. `'default:apple'` +Examples: + +* `'default:apple'`: 1 apple +* `'default:dirt 5'`: 5 dirt +* `'default:pick_stone'`: a new stone pickaxe +* `'default:pick_wood 1 21323'`: a wooden pickaxe, ca. 1/3 worn out #### Table format Examples: @@ -1220,16 +1401,18 @@ Another example: Make red wool from white wool and red dye: ### Special groups * `immortal`: Disables the group damage system for an entity +* `punch_operable`: For entities; 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. * `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 -* `dig_immediate`: (player can always pick up node without tool wear) - * `2`: node is removed without tool wear after 0.5 seconds or so - (rail, sign) - * `3`: node is removed without tool wear immediately (torch) +* `dig_immediate`: (player can always pick up node without reducing tool wear) + * `2`: the node always gets the digging time 0.5 seconds (rail, sign) + * `3`: the node always gets the digging time 0 seconds (torch) * `disable_jump`: Player (and possibly other things) cannot jump from node * `fall_damage_add_percent`: damage speed = `speed * (1 + value/100)` * `bouncy`: value is bounce speed in percent @@ -1259,6 +1442,7 @@ Another example: Make red wool from white wool and red dye: ### Examples of custom groups Item groups are often used for defining, well, _groups of items_. + * `meat`: any meat-kind of a thing (rating might define the size or healing ability or be irrelevant -- it is not defined as of yet) * `eatable`: anything that can be eaten. Rating might define HP gain in half @@ -1330,6 +1514,10 @@ result in the tool 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. + #### Damage groups List of damage for groups of entities. See "Entity damage mechanism". @@ -1475,7 +1663,10 @@ Item metadata only contains a key-value store. Some of the values in the key-value store are handled specially: -* `description`: Set the itemstack's description. Defaults to idef.description +* `description`: Set the item stack's description. Defaults to `idef.description` +* `color`: A `ColorString`, which sets the stack's color. +* `palette_index`: If the item has a palette, this is used to get the + current color from the palette. Example stuff: @@ -1534,7 +1725,7 @@ examples. #### `container[,]` * Start of a container block, moves all physical elements in the container by (X, Y) -* Must have matching container_end +* Must have matching `container_end` * Containers can be nested, in which case the offsets are added (child containers are relative to parent containers) @@ -1574,7 +1765,7 @@ examples. * Sets default background color of tooltips * Sets default font color of tooltips -#### `tooltip[;;,]` +#### `tooltip[;;;]` * Adds tooltip for an element * `` tooltip background color as `ColorString` (optional) * `` tooltip font color as `ColorString` (optional) @@ -1619,7 +1810,7 @@ examples. #### `field[,;,;;