The game directory can contain the file minetest.conf, which will be used
to set default settings when running the particular game.
It can also contain a settingtypes.txt in the same format as the one in builtin.
This settingtypes.txt will be parsed by the menu and the settings will be displayed in the "Games" category in the settings tab.
This settingtypes.txt will be parsed by the menu and the settings will be displayed
in the "Games" category in the settings tab.
### Menu images
Games can provide custom main menu images. They are put inside a `menu` directory inside the game directory.
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.
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.
Mod load path
...
...
@@ -243,7 +247,8 @@ Example:
default_dirt.png^default_grass_side.png
`default_grass_side.png` is overlayed over `default_dirt.png`.
The texture with the lower resolution will be automatically upscaled to the higher resolution texture.
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 `)`.
...
...
@@ -468,8 +473,8 @@ the global `minetest.registered_*` tables.
* added to `minetest.registered_schematic` with the key of `schematic.name`
* if `schematic.name` is nil, the key is the returned ID
* if the schematic is loaded from a file, schematic.name is set to the filename
* if the function is called when loading the mod, and schematic.name is a relative path,
* then the current mod path will be prepended to the schematic filename
* if the function is called when loading the mod, and schematic.name is a relative
path, then the current mod path will be prepended to the schematic filename
* `minetest.clear_registered_biomes()`
* clears all biomes currently registered
...
...
@@ -1416,13 +1421,13 @@ examples.
#### `listring[<inventory location>;<list name>]`
* Allows to create a ring of inventory lists
* Shift-clicking on items in one element of the ring
* will send them to the next inventory list inside the ring
will send them to the next inventory list inside the ring
* The first occurrence of an element inside the ring will
* determine the inventory where items will be sent to
determine the inventory where items will be sent to
#### `listring[]`
* Shorthand for doing `listring[<inventory location>;<list name>]`
* for the last two inventory lists added by list[...]
for the last two inventory lists added by list[...]
* See `minetest.builtin_auth_handler` in `builtin.lua` for reference
...
...
@@ -2669,7 +2675,8 @@ This is basically a reference to a C++ `ServerActiveObject`
##### Player-only (no-op for other objects)
* `get_player_name()`: returns `""` if is not a player
* `get_player_velocity()`: returns `nil` if is not a player otherwise a table {x, y, z} representing the player's instantaneous velocity in nodes/s
* `get_player_velocity()`: returns `nil` if is not a player, otherwise a
table {x, y, z} representing the player's instantaneous velocity in nodes/s
* `get_look_dir()`: get camera direction as a unit vector
* `get_look_pitch()`: pitch in radians
* `get_look_yaw()`: yaw in radians (wraps around pretty randomly as of now)
...
...
@@ -2783,25 +2790,40 @@ An `InvRef` is a reference to an inventory.
A fast access data structure to store areas, and find areas near a given position or area.
Every area has a `data` string attribute to store additional information.
You can create an empty `AreaStore` by calling `AreaStore()`, or `AreaStore(type_name)`.
If you chose the parameter-less constructor, a fast implementation will be automatically chosen for you.
If you chose the parameter-less constructor, a fast implementation will be automatically
chosen for you.
#### Methods
* `get_area(id, include_borders, include_data)`: returns the area with the id `id`. (optional) Boolean values `include_borders` and `include_data` control what's copied.
* `get_areas_for_pos(pos, include_borders, include_data)`: returns all areas that contain the position `pos`. (optional) Boolean values `include_borders` and `include_data` control what's copied.
* `get_areas_in_area(edge1, edge2, accept_overlap, include_borders, include_data)`: returns all areas that contain all nodes inside the area specified by `edge1` and `edge2` (inclusive). If `accept_overlap` is true, also areas are returned that have nodes in common with the specified area. (optional) Boolean values `include_borders` and `include_data` control what's copied.
* `insert_area(edge1, edge2, data, [id])`: inserts an area into the store. Returns the new area's ID, or nil if the insertion failed. The (inclusive) positions `edge1` and `edge2` describe the area. `data` is a string stored with the area. If passed, `id` will be used as the internal area ID, it must be a unique number between 0 and 2^32-2. If you use the `id` parameter you must always use it, or insertions are likely to fail due to conflicts.
* `reserve(count)`: reserves resources for at most `count` many contained areas. Only needed for efficiency, and only some implementations profit.
* `get_area(id, include_borders, include_data)`: returns the area with the id `id`.
(optional) Boolean values `include_borders` and `include_data` control what's copied.
* `get_areas_for_pos(pos, include_borders, include_data)`: returns all areas that contain
the position `pos`. (optional) Boolean values `include_borders` and `include_data` control
returns all areas that contain all nodes inside the area specified by `edge1` and `edge2` (inclusive).
If `accept_overlap` is true, also areas are returned that have nodes in common with the specified area.
(optional) Boolean values `include_borders` and `include_data` control what's copied.
* `insert_area(edge1, edge2, data, [id])`: inserts an area into the store. Returns the new area's ID,
or nil if the insertion failed. The (inclusive) positions `edge1` and `edge2` describe the area.
`data` is a string stored with the area. If passed, `id` will be used as the internal area ID,
it must be a unique number between 0 and 2^32-2. If you use the `id` parameter you must always use it,
or insertions are likely to fail due to conflicts.
* `reserve(count)`: reserves resources for at most `count` many contained areas.
Only needed for efficiency, and only some implementations profit.
* `remove_area(id)`: removes the area with the given id from the store, returns success.
* `set_cache_params(params)`: sets params for the included prefiltering cache. Calling invalidates the cache, so that its elements have to be newly generated.
* `set_cache_params(params)`: sets params for the included prefiltering cache.
Calling invalidates the cache, so that its elements have to be newly generated.
* `params`:
{
enabled = boolean, -- whether to enable, default true
block_radius = number, -- the radius (in nodes) of the areas the cache generates prefiltered lists for, minimum 16, default 64
block_radius = number, -- the radius (in nodes) of the areas the cache generates
