Fix a load of typos and grammatical issues
This commit is contained in:
parent
7a78ee8643
commit
d2c94dc825
@ -96,7 +96,7 @@ a = a + 10
|
|||||||
print("Sum is "..result)
|
print("Sum is "..result)
|
||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
Woah, what happened there? a, b, and result are **variables**. They're like what
|
Whoa, what happened there? a, b, and result are **variables**. They're like what
|
||||||
you get in mathematics, A = w * h. The equals signs are **assignments**, so
|
you get in mathematics, A = w * h. The equals signs are **assignments**, so
|
||||||
"result" is set to a + b. Variable names can be longer than one character
|
"result" is set to a + b. Variable names can be longer than one character
|
||||||
unlike in mathematics, as seen with the "result" variable. Lua is **case sensitive**.
|
unlike in mathematics, as seen with the "result" variable. Lua is **case sensitive**.
|
||||||
@ -280,7 +280,7 @@ one()
|
|||||||
two()
|
two()
|
||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
Nil means **not initalised**. The variable hasn't been assigned a value yet,
|
Nil means **not initialised**. The variable hasn't been assigned a value yet,
|
||||||
doesn't exist, or has been uninitialised. (ie: set to nil)
|
doesn't exist, or has been uninitialised. (ie: set to nil)
|
||||||
|
|
||||||
The same goes for functions. Functions are variables of a special type.
|
The same goes for functions. Functions are variables of a special type.
|
||||||
|
@ -15,13 +15,13 @@ In this chapter you will learn how to use ItemStacks.
|
|||||||
* Adding and Taking Items
|
* Adding and Taking Items
|
||||||
* Wear
|
* Wear
|
||||||
* Lua Tables
|
* Lua Tables
|
||||||
* Meta data
|
* Metadata
|
||||||
* More Methods
|
* More Methods
|
||||||
|
|
||||||
## Creating ItemStacks
|
## Creating ItemStacks
|
||||||
|
|
||||||
An item stack is a... stack of items. It's basically just an item type with
|
An item stack is a... stack of items.
|
||||||
a count of items in the stack.
|
It's basically just an item type with a count of items in the stack.
|
||||||
|
|
||||||
You can create a stack like so:
|
You can create a stack like so:
|
||||||
|
|
||||||
@ -120,9 +120,9 @@ local data = items:to_table()
|
|||||||
local items2 = ItemStack(data)
|
local items2 = ItemStack(data)
|
||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
## Meta data
|
## Metadata
|
||||||
|
|
||||||
ItemStacks can have meta data, and use the same API as [Node Metadata](node_metadata.html).
|
ItemStacks can have metadata, and use the same API as [Node Metadata](node_metadata.html).
|
||||||
|
|
||||||
{% highlight lua %}
|
{% highlight lua %}
|
||||||
local meta = items:get_meta()
|
local meta = items:get_meta()
|
||||||
|
@ -341,7 +341,7 @@ The most important part is the nodebox table:
|
|||||||
{-0.5, 0, 0, 0.5, 0.5, 0.5}
|
{-0.5, 0, 0, 0.5, 0.5, 0.5}
|
||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
Each row is a cubiod which are joined to make a single node.
|
Each row is a cuboid which are joined to make a single node.
|
||||||
The first three numbers are the co-ordinates, from -0.5 to 0.5 inclusive, of
|
The first three numbers are the co-ordinates, from -0.5 to 0.5 inclusive, of
|
||||||
the bottom front left most corner, the last three numbers are the opposite corner.
|
the bottom front left most corner, the last three numbers are the opposite corner.
|
||||||
They are in the form X, Y, Z, where Y is up.
|
They are in the form X, Y, Z, where Y is up.
|
||||||
|
@ -194,8 +194,7 @@ The is_ground_content attribute allows caves to be generated over the stone.
|
|||||||
|
|
||||||
## Crafting
|
## Crafting
|
||||||
|
|
||||||
There are several different types of crafting,
|
There are several types of crafting, identified by the ``type`` property.
|
||||||
identified by the ``type`` property.
|
|
||||||
|
|
||||||
* shaped - Ingredients must be in the correct position.
|
* shaped - Ingredients must be in the correct position.
|
||||||
* shapeless - It doesn't matter where the ingredients are,
|
* shapeless - It doesn't matter where the ingredients are,
|
||||||
@ -285,7 +284,7 @@ minetest.register_craft({
|
|||||||
As you can see from this example, the only real difference in the code
|
As you can see from this example, the only real difference in the code
|
||||||
is that the recipe is just a single item, compared to being in a table
|
is that the recipe is just a single item, compared to being in a table
|
||||||
(between braces). They also have an optional "cooktime" parameter which
|
(between braces). They also have an optional "cooktime" parameter which
|
||||||
defines how long the item takes to cook. If this is not set it defaults to 3.
|
defines how long the item takes to cook. If this is not set, it defaults to 3.
|
||||||
|
|
||||||
The recipe above works when the coal block is in the input slot,
|
The recipe above works when the coal block is in the input slot,
|
||||||
with some form of a fuel below it.
|
with some form of a fuel below it.
|
||||||
|
@ -12,7 +12,7 @@ redirect_from: /en/chapters/abms.html
|
|||||||
An **A**ctive **B**lock **M**odifier (**ABM**) allows you to run code on
|
An **A**ctive **B**lock **M**odifier (**ABM**) allows you to run code on
|
||||||
certain nodes at specific intervals.
|
certain nodes at specific intervals.
|
||||||
|
|
||||||
Please be warned, ABMs which are too frequent or act on a large number of nodes
|
Please be warned, ABMs which are too frequent or act on many nodes
|
||||||
cause massive amounts of lag. Use them sparingly.
|
cause massive amounts of lag. Use them sparingly.
|
||||||
|
|
||||||
* [Example: Growing Alien Grass](#example-growing-alien-grass)
|
* [Example: Growing Alien Grass](#example-growing-alien-grass)
|
||||||
@ -47,12 +47,12 @@ minetest.register_abm({
|
|||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
This ABM runs every ten seconds. There is a 1 in 5 chance of the ABM running on each
|
This ABM runs every ten seconds. There is a 1 in 5 chance of the ABM running on each
|
||||||
node that has the correct name and the correct neighbors. If the ABM runs on a
|
node that has the correct name and the correct neighbours. If the ABM runs on a
|
||||||
node, an alien grass node is placed above it. Please be warned, this will delete any
|
node, an alien grass node is placed above it. Please be warned, this will delete any
|
||||||
node previously located in that position. To prevent this you should include a check
|
node previously located in that position. To prevent this you should include a check
|
||||||
using minetest.get_node to make sure there is space for the grass.
|
using minetest.get_node to make sure there is space for the grass.
|
||||||
|
|
||||||
Specifying a neighbor is optional. If you specify multiple neighbors, only one of them
|
Specifying a neighbour is optional. If you specify multiple neighbours, only one of them
|
||||||
needs to be present to meet the requirements.
|
needs to be present to meet the requirements.
|
||||||
|
|
||||||
Specifying chance is also optional. If you don't specify the chance, the ABM will
|
Specifying chance is also optional. If you don't specify the chance, the ABM will
|
||||||
@ -61,6 +61,6 @@ always run when the other conditions are met.
|
|||||||
## Your Turn
|
## Your Turn
|
||||||
|
|
||||||
* **Midas touch**: Make water turn to gold blocks with a 1 in 100 chance, every 5 seconds.
|
* **Midas touch**: Make water turn to gold blocks with a 1 in 100 chance, every 5 seconds.
|
||||||
* **Decay**: Make wood turn into dirt when water is a neighbor.
|
* **Decay**: Make wood turn into dirt when water is a neighbour.
|
||||||
* **Burnin'**: Make every air node catch on fire. (Tip: "air" and "fire:basic_flame").
|
* **Burnin'**: Make every air node catch on fire. (Tip: "air" and "fire:basic_flame").
|
||||||
Warning: expect the game to crash.
|
Warning: expect the game to crash.
|
||||||
|
@ -29,7 +29,7 @@ Areas of the map which are not yet loaded are full of *ignore* nodes, an impassa
|
|||||||
unselectable placeholder node. Empty space is full of *air* nodes, an invisible node
|
unselectable placeholder node. Empty space is full of *air* nodes, an invisible node
|
||||||
you can walk through.
|
you can walk through.
|
||||||
|
|
||||||
Loaded map blocks are often refered to as *active blocks*. Active Blocks can be
|
Loaded map blocks are often referred to as *active blocks*. Active Blocks can be
|
||||||
read from or written to by mods or players, have active entities. The Engine also
|
read from or written to by mods or players, have active entities. The Engine also
|
||||||
performs operations on the map, such as performing liquid physics.
|
performs operations on the map, such as performing liquid physics.
|
||||||
|
|
||||||
@ -60,7 +60,7 @@ print(dump(node)) --> { name=.., param1=.., param2=.. }
|
|||||||
If the position is a decimal, it will be rounded to the containing node.
|
If the position is a decimal, it will be rounded to the containing node.
|
||||||
The function will always return a table containing the node information:
|
The function will always return a table containing the node information:
|
||||||
|
|
||||||
* `name` - The node name, will be ignore when the area is unloaded.
|
* `name` - The node name, will be ignored when the area is unloaded.
|
||||||
* `param1` - See the node definition, will commonly be light.
|
* `param1` - See the node definition, will commonly be light.
|
||||||
* `param2` - See the node definition.
|
* `param2` - See the node definition.
|
||||||
|
|
||||||
@ -91,7 +91,7 @@ if node_pos then
|
|||||||
end
|
end
|
||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
Lets say, for example, that the growth rate increases the more mese there is
|
Let's say, for example, that the growth rate increases the more mese there is
|
||||||
nearby. You should then use a function which can find multiple nodes in area:
|
nearby. You should then use a function which can find multiple nodes in area:
|
||||||
|
|
||||||
{% highlight lua %}
|
{% highlight lua %}
|
||||||
@ -124,8 +124,8 @@ rooting it to obtain the actual distance. This is because computers find square
|
|||||||
roots computationally expensive, so you should avoid them as much as possible.
|
roots computationally expensive, so you should avoid them as much as possible.
|
||||||
|
|
||||||
There are more variations of the above two functions, such as
|
There are more variations of the above two functions, such as
|
||||||
`find_nodes_with_meta` and `find_nodes_in_area_under_air`, which work in a
|
`find_nodes_with_meta` and `find_nodes_in_area_under_air`, which work similarly
|
||||||
similar way and are useful in other circumstances.
|
and are useful in other circumstances.
|
||||||
|
|
||||||
## Writing
|
## Writing
|
||||||
|
|
||||||
@ -142,13 +142,13 @@ local node = minetest.get_node({ x = 1, y = 3, z = 4 })
|
|||||||
print(node.name) --> default:mese
|
print(node.name) --> default:mese
|
||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
set_node will remove any associated meta data or inventory from that position.
|
set_node will remove any associated metadata or inventory from that position.
|
||||||
This isn't desirable in all circumstances, especially if you're using multiple
|
This isn't desirable in all circumstances, especially if you're using multiple
|
||||||
node definitions to represent one conceptual node. An example of this is the
|
node definitions to represent one conceptual node. An example of this is the
|
||||||
furnace node - whilst you think conceptually of it as one node, it's actually
|
furnace node - whilst you think conceptually of it as one node, it's actually
|
||||||
two.
|
two.
|
||||||
|
|
||||||
You can set a node without deleting meta data or the inventory like so:
|
You can set a node without deleting metadata or the inventory like so:
|
||||||
|
|
||||||
{% highlight lua %}
|
{% highlight lua %}
|
||||||
minetest.swap_node({ x = 1, y = 3, z = 4 }, { name = "default:mese" })
|
minetest.swap_node({ x = 1, y = 3, z = 4 }, { name = "default:mese" })
|
||||||
@ -156,8 +156,7 @@ minetest.swap_node({ x = 1, y = 3, z = 4 }, { name = "default:mese" })
|
|||||||
|
|
||||||
### Removing Nodes
|
### Removing Nodes
|
||||||
|
|
||||||
A node must always be present. When someone says to remove a node, what
|
A node must always be present. To remove a node, you set the position to `air`.
|
||||||
is usually meant is they want to set the node to `air`.
|
|
||||||
|
|
||||||
The following two lines will both remove a node, and are both identical:
|
The following two lines will both remove a node, and are both identical:
|
||||||
|
|
||||||
@ -171,7 +170,7 @@ In fact, remove_node will call set_node with name being air.
|
|||||||
## Loading Blocks
|
## Loading Blocks
|
||||||
|
|
||||||
You can use `minetest.emerge_area` to load map blocks. Emerge area is asynchronous,
|
You can use `minetest.emerge_area` to load map blocks. Emerge area is asynchronous,
|
||||||
meaning the the blocks won't be loaded instantly. Instead they will be loaded
|
meaning the blocks won't be loaded instantly. Instead, they will be loaded
|
||||||
soon in the future, and the callback will be called each time.
|
soon in the future, and the callback will be called each time.
|
||||||
|
|
||||||
{% highlight lua %}
|
{% highlight lua %}
|
||||||
|
@ -42,7 +42,7 @@ local emin, emax = vm:read_from_map(pos1, pos2)
|
|||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
An LVM may not read exactly the area you tell it to, for performance reasons.
|
An LVM may not read exactly the area you tell it to, for performance reasons.
|
||||||
Instead it may read a larger area. The larger area is given by `emin` and `emax`,
|
Instead, it may read a larger area. The larger area is given by `emin` and `emax`,
|
||||||
which stand for *emerged min pos* and *emerged max pos*. An LVM will load the area
|
which stand for *emerged min pos* and *emerged max pos*. An LVM will load the area
|
||||||
it contains for you - whether that involves loading from memory, from disk, or
|
it contains for you - whether that involves loading from memory, from disk, or
|
||||||
calling the map generator.
|
calling the map generator.
|
||||||
@ -95,7 +95,7 @@ end
|
|||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
It is recommended that you find out and store the content IDs of nodes types
|
It is recommended that you find out and store the content IDs of nodes types
|
||||||
uring load time, as the IDs of a node type will never change. Make sure to store
|
using load time, as the IDs of a node type will never change. Make sure to store
|
||||||
the IDs in a local for performance reasons.
|
the IDs in a local for performance reasons.
|
||||||
|
|
||||||
Nodes in an LVM data are stored in reverse co-ordinate order, so you should
|
Nodes in an LVM data are stored in reverse co-ordinate order, so you should
|
||||||
@ -152,7 +152,7 @@ vm:write_to_map(true)
|
|||||||
For setting lighting and param2 data, there are the appropriately named
|
For setting lighting and param2 data, there are the appropriately named
|
||||||
`set_light_data()` and `set_param2_data()` methods.
|
`set_light_data()` and `set_param2_data()` methods.
|
||||||
|
|
||||||
`write_to_map()` takes a boolean which is true if you want lighting to be
|
`write_to_map()` takes a Boolean which is true if you want lighting to be
|
||||||
calculated. If you pass false, you need to recalculate lighting at some future
|
calculated. If you pass false, you need to recalculate lighting at some future
|
||||||
date using `minetest.fix_light`.
|
date using `minetest.fix_light`.
|
||||||
|
|
||||||
|
@ -72,7 +72,7 @@ The functions available include:
|
|||||||
* get_float
|
* get_float
|
||||||
* get_inventory
|
* get_inventory
|
||||||
|
|
||||||
To get booleans, you should use `get_string` and `minetest.is_yes`:
|
To get a Boolean, you should use `get_string` and `minetest.is_yes`:
|
||||||
|
|
||||||
{% highlight lua %}
|
{% highlight lua %}
|
||||||
local value = minetest.is_yes(meta:get_string("key"))
|
local value = minetest.is_yes(meta:get_string("key"))
|
||||||
@ -103,7 +103,7 @@ This can be done using the following functions:
|
|||||||
|
|
||||||
## Lua Tables
|
## Lua Tables
|
||||||
|
|
||||||
You can convert to and from lua tables using `to_table` and `from_table`:
|
You can convert to and from Lua tables using `to_table` and `from_table`:
|
||||||
|
|
||||||
{% highlight lua %}
|
{% highlight lua %}
|
||||||
local tmp = meta:to_table()
|
local tmp = meta:to_table()
|
||||||
|
@ -48,7 +48,7 @@ only visible to the named player, in this case player1.
|
|||||||
### Older Mods
|
### Older Mods
|
||||||
|
|
||||||
Occasionally you'll see mods where the chat_send_player function includes a
|
Occasionally you'll see mods where the chat_send_player function includes a
|
||||||
boolean:
|
Boolean:
|
||||||
|
|
||||||
{% highlight lua %}
|
{% highlight lua %}
|
||||||
minetest.chat_send_player("player1", "This is a server message", true)
|
minetest.chat_send_player("player1", "This is a server message", true)
|
||||||
@ -93,7 +93,7 @@ will run and the message will be sent:
|
|||||||
return true, "You said " .. param .. "!"
|
return true, "You said " .. param .. "!"
|
||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
This returns two values, a boolean which shows the command succeeded
|
This returns two values, a Boolean which shows the command succeeded
|
||||||
and the chat message to send to the player.
|
and the chat message to send to the player.
|
||||||
|
|
||||||
A player name, instead of a player object, is passed because
|
A player name, instead of a player object, is passed because
|
||||||
@ -121,7 +121,7 @@ Patterns are a way of extracting stuff from text using rules.
|
|||||||
local to, msg = string.match(param, "^([%a%d_-]+) (*+)$")
|
local to, msg = string.match(param, "^([%a%d_-]+) (*+)$")
|
||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
The above implements `/msg <to> <message>`. Lets go through left to right:
|
The above implements `/msg <to> <message>`. Let's go through left to right:
|
||||||
|
|
||||||
* `^` means match the start of the string.
|
* `^` means match the start of the string.
|
||||||
* `()` is a matching group - anything that matches stuff in here will be
|
* `()` is a matching group - anything that matches stuff in here will be
|
||||||
|
@ -59,10 +59,10 @@ sub commands. Each `cmd:sub(route, func)` is a sub command.
|
|||||||
|
|
||||||
A sub command is a particular response to an input param. When a player runs
|
A sub command is a particular response to an input param. When a player runs
|
||||||
the chat command, the first sub command that matches their input will be run,
|
the chat command, the first sub command that matches their input will be run,
|
||||||
and no others. If no subcommands match then the user will be told of the invalid
|
and no others. If no subcommands match, then the user will be told of the invalid
|
||||||
syntax. For example, in the above code snippet if a player
|
syntax. For example, in the above code snippet if a player
|
||||||
types something of the form `/sethp username 12` then the function passed
|
types something of the form `/sethp username 12` then the function passed
|
||||||
to cmd:sub will be called. If they type `/sethp 12 bleh` then a wrong
|
to cmd:sub will be called. If they type `/sethp 12 bleh`, then a wrong
|
||||||
input message will appear.
|
input message will appear.
|
||||||
|
|
||||||
`:name :hp:int` is a route. It describes the format of the param passed to /teleport.
|
`:name :hp:int` is a route. It describes the format of the param passed to /teleport.
|
||||||
@ -76,7 +76,7 @@ as terminals.
|
|||||||
Variables can change value depending on what the user types. For example, `:username`
|
Variables can change value depending on what the user types. For example, `:username`
|
||||||
and `:teamname`.
|
and `:teamname`.
|
||||||
|
|
||||||
Variables are defined as `:name:type`. The `name` is used in the help documention.
|
Variables are defined as `:name:type`. The `name` is used in the help documentation.
|
||||||
The `type` is used to match the input. If the type is not given, then the type is
|
The `type` is used to match the input. If the type is not given, then the type is
|
||||||
`word`.
|
`word`.
|
||||||
|
|
||||||
|
@ -164,7 +164,7 @@ want to do.
|
|||||||
|
|
||||||
### Fields
|
### Fields
|
||||||
|
|
||||||
The fields parameter to the function is a table, index by string, of the values
|
The `fields` parameter to the function is a table, index by string, of the values
|
||||||
submitted by the user. You can access values in the table via fields.name,
|
submitted by the user. You can access values in the table via fields.name,
|
||||||
where 'name' is the name of the element.
|
where 'name' is the name of the element.
|
||||||
|
|
||||||
|
@ -79,13 +79,13 @@ score panel like so:
|
|||||||
alt="screenshot of the HUD we're aiming for">
|
alt="screenshot of the HUD we're aiming for">
|
||||||
</figure>
|
</figure>
|
||||||
|
|
||||||
In the above screenshot all of the elements have the same percentage position -
|
In the above screenshot all the elements have the same percentage position -
|
||||||
(100%, 50%) - but different offsets. This allows the whole thing to be anchored
|
(100%, 50%) - but different offsets. This allows the whole thing to be anchored
|
||||||
to the right of the window, but to resize without breaking.
|
to the right of the window, but to resize without breaking.
|
||||||
|
|
||||||
## Text Elements
|
## Text Elements
|
||||||
|
|
||||||
You can create a hud element once you have a copy of the player object:
|
You can create a HUD element once you have a copy of the player object:
|
||||||
|
|
||||||
{% highlight lua %}
|
{% highlight lua %}
|
||||||
local player = minetest.get_player_by_name("username")
|
local player = minetest.get_player_by_name("username")
|
||||||
@ -109,13 +109,12 @@ table. The meaning of other properties varies based on this type.
|
|||||||
|
|
||||||
`scale` is the maximum bounds of text, text outside these bounds is cropped, eg: `{x=100, y=100}`.
|
`scale` is the maximum bounds of text, text outside these bounds is cropped, eg: `{x=100, y=100}`.
|
||||||
|
|
||||||
The text's color in [Hexadecimal form](http://www.colorpicker.com/), eg: `0xFF0000`,
|
`number` is the text's colour, and is in [Hexadecimal form](http://www.colorpicker.com/), eg: `0xFF0000`.
|
||||||
and stored in
|
|
||||||
|
|
||||||
|
|
||||||
### Our Example
|
### Our Example
|
||||||
|
|
||||||
Let's go ahead, and place all of the text in our score panel:
|
Let's go ahead, and place all the text in our score panel:
|
||||||
|
|
||||||
{% highlight lua %}
|
{% highlight lua %}
|
||||||
player:hud_add({
|
player:hud_add({
|
||||||
@ -222,7 +221,8 @@ player:hud_add({
|
|||||||
})
|
})
|
||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
We now have a HUD that looks like the one in the first post! There is one problem however, it won't update when the stats change
|
We now have a HUD that looks like the one in the first post!
|
||||||
|
There is one problem however, it won't update when the stats change.
|
||||||
|
|
||||||
## Changing an Element
|
## Changing an Element
|
||||||
|
|
||||||
|
@ -57,7 +57,7 @@ unintended, it has been preserved in overrides due to its use on many servers.
|
|||||||
Two overrides are needed to fully restore old movement behaviour:
|
Two overrides are needed to fully restore old movement behaviour:
|
||||||
|
|
||||||
* new_move: whether the player uses new movement (default: true)
|
* new_move: whether the player uses new movement (default: true)
|
||||||
* sneak_glitch: whether the player can use 'sneak elevators' (default: false)
|
* sneak_glitch: whether the player can use "sneak elevators" (default: false)
|
||||||
|
|
||||||
## Mod Incompatibility
|
## Mod Incompatibility
|
||||||
|
|
||||||
|
@ -136,15 +136,15 @@ minetest.set_player_privs(name, privs)
|
|||||||
## Adding Privileges to basic_privs
|
## Adding Privileges to basic_privs
|
||||||
|
|
||||||
Players with the `basic_privs` privilege are able to grant and revoke a limited
|
Players with the `basic_privs` privilege are able to grant and revoke a limited
|
||||||
set of privileges. It's common to give this privilege to moderators so they can
|
set of privileges. It's common to give this privilege to moderators, so that
|
||||||
grant and revoke `interact` and `shout`, but can't grant themselves or other
|
they can grant and revoke `interact` and `shout`, but can't grant themselves or other
|
||||||
players privileges such as `give` and `server`, which have greater potential for abuse.
|
players privileges such as `give` and `server`, which have greater potential for abuse.
|
||||||
|
|
||||||
To add a privilege to `basic_privs` and adjust which privileges your moderators can
|
To add a privilege to `basic_privs` and adjust which privileges your moderators can
|
||||||
grant and revoke from other players, you must change the `basic_privs` setting.
|
grant and revoke from other players, you must change the `basic_privs` setting.
|
||||||
To do this, you must edit the minetest.conf file.
|
To do this, you must edit the minetest.conf file.
|
||||||
|
|
||||||
By default `basic_privs` has the following value:
|
By default, `basic_privs` has the following value:
|
||||||
|
|
||||||
basic_privs = interact, shout
|
basic_privs = interact, shout
|
||||||
|
|
||||||
|
@ -13,7 +13,7 @@ create the player's inventory [formspec](formspecs.html). SFINV comes with
|
|||||||
an API that allows you to add and otherwise manage the pages shown.
|
an API that allows you to add and otherwise manage the pages shown.
|
||||||
|
|
||||||
Whilst SFINV by default shows pages as tabs, pages are called "pages" as
|
Whilst SFINV by default shows pages as tabs, pages are called "pages" as
|
||||||
it's entirely possible that a mod or subgame decides to show them in
|
it's entirely possible that a mod or game decides to show them in
|
||||||
some other format instead.
|
some other format instead.
|
||||||
|
|
||||||
* [Registering a Page](#registering-a-page)
|
* [Registering a Page](#registering-a-page)
|
||||||
@ -217,7 +217,7 @@ leaves (another tab is about to be selected) your tab.
|
|||||||
Please note that you can't cancel these, as it would be a bad user experience
|
Please note that you can't cancel these, as it would be a bad user experience
|
||||||
if you could.
|
if you could.
|
||||||
|
|
||||||
Also note that the inventory may not be visible at the time
|
Also, note that the inventory may not be visible at the time
|
||||||
these callbacks are called. For example, on_enter is called for the home page
|
these callbacks are called. For example, on_enter is called for the home page
|
||||||
when a player joins the game even before they open their inventory!
|
when a player joins the game even before they open their inventory!
|
||||||
|
|
||||||
|
@ -70,14 +70,14 @@ One way to do this is to think about:
|
|||||||
these actions cause things to happen in the engine.
|
these actions cause things to happen in the engine.
|
||||||
|
|
||||||
Let's take an example of a land protection mod. The data you have is the areas
|
Let's take an example of a land protection mod. The data you have is the areas
|
||||||
and any associated meta data. The actions you can take are `create`, `edit`, or
|
and any associated metadata. Actions you can take are `create`, `edit`, or
|
||||||
`delete`. The events that trigger these actions are chat commands and formspec
|
`delete`. The events that trigger these actions are chat commands and formspec
|
||||||
receive fields. These are 3 areas can usually be separated pretty well.
|
receive fields. These are 3 areas that can usually be separated pretty well.
|
||||||
|
|
||||||
In your tests, you will be able to make sure that an action when triggered does the right thing
|
In your tests, you will be able to make sure that an action when triggered does
|
||||||
to the data, but you won't need to test that an event calls an action (as this
|
the right thing to the data, but you won't need to test that an event calls an
|
||||||
would require using the Minetest API, and this area of code should be made as
|
action (as this would require using the Minetest API, and this area of code
|
||||||
small as possible anyway.)
|
should be made as small as possible anyway.)
|
||||||
|
|
||||||
You should write your data representation using Pure Lua. "Pure" in this context
|
You should write your data representation using Pure Lua. "Pure" in this context
|
||||||
means that the functions could run outside of Minetest - none of the engine's
|
means that the functions could run outside of Minetest - none of the engine's
|
||||||
@ -86,7 +86,7 @@ functions are called.
|
|||||||
{% highlight lua %}
|
{% highlight lua %}
|
||||||
-- Data
|
-- Data
|
||||||
function land.create(name, area_name)
|
function land.create(name, area_name)
|
||||||
land.lands[aname] = {
|
land.lands[area_name] = {
|
||||||
name = area_name,
|
name = area_name,
|
||||||
owner = name,
|
owner = name,
|
||||||
-- more stuff
|
-- more stuff
|
||||||
@ -152,14 +152,14 @@ most of the calculations are made.
|
|||||||
The controller should have no knowledge about the Minetest API - notice how
|
The controller should have no knowledge about the Minetest API - notice how
|
||||||
there are no Minetest calls or any view functions that resemble them.
|
there are no Minetest calls or any view functions that resemble them.
|
||||||
You should *NOT* have a function like `view.hud_add(player, def)`.
|
You should *NOT* have a function like `view.hud_add(player, def)`.
|
||||||
Instead the view defines some actions the controller can tell the view to do,
|
Instead, the view defines some actions the controller can tell the view to do,
|
||||||
like `view.add_hud(info)` where info is a value or table which doesn't relate
|
like `view.add_hud(info)` where info is a value or table which doesn't relate
|
||||||
to the Minetest API at all.
|
to the Minetest API at all.
|
||||||
|
|
||||||
<figure class="right_image">
|
<figure class="right_image">
|
||||||
<img
|
<img
|
||||||
width="100%"
|
width="100%"
|
||||||
src="{{ page.root }}//static/mvc_diagram.svg"
|
src="{{ page.root }}/static/mvc_diagram.svg"
|
||||||
alt="Diagram showing a centered text element">
|
alt="Diagram showing a centered text element">
|
||||||
</figure>
|
</figure>
|
||||||
|
|
||||||
|
@ -64,7 +64,7 @@ Malicious clients can submit formspecs whenever they like with whatever content
|
|||||||
they like.
|
they like.
|
||||||
|
|
||||||
The following code has a vulnerability where any player can give
|
The following code has a vulnerability where any player can give
|
||||||
themself moderator privileges:
|
themselves moderator privileges:
|
||||||
|
|
||||||
{% highlight lua %}
|
{% highlight lua %}
|
||||||
local function show_formspec(name)
|
local function show_formspec(name)
|
||||||
@ -130,7 +130,7 @@ inv:set_stack("main", 1, stack)
|
|||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
The behaviour of callbacks is slightly more complicated. Modifying an itemstack you
|
The behaviour of callbacks is slightly more complicated. Modifying an itemstack you
|
||||||
are given will change it for the caller too, and any subsequent callbacks. However
|
are given will change it for the caller too, and any subsequent callbacks. However,
|
||||||
it will only be saved in the engine if the callback caller sets it.
|
it will only be saved in the engine if the callback caller sets it.
|
||||||
|
|
||||||
Avoid this:
|
Avoid this:
|
||||||
@ -143,7 +143,7 @@ end)
|
|||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
If no callbacks cancel, then the stack will be set and the description will be updated.
|
If no callbacks cancel, then the stack will be set and the description will be updated.
|
||||||
If a callback cancels then the update may be lost. It's better to do this instead:
|
If a callback cancels, then the update may be lost. It's better to do this instead:
|
||||||
|
|
||||||
{% highlight lua %}
|
{% highlight lua %}
|
||||||
minetest.register_on_item_eat(function(hp_change, replace_with_item, itemstack, user, pointed_thing)
|
minetest.register_on_item_eat(function(hp_change, replace_with_item, itemstack, user, pointed_thing)
|
||||||
|
@ -88,7 +88,7 @@ a look at the list below.
|
|||||||
### Troubleshooting
|
### Troubleshooting
|
||||||
|
|
||||||
* **accessing undefined variable foobar** - If `foobar` is meant to be a global,
|
* **accessing undefined variable foobar** - If `foobar` is meant to be a global,
|
||||||
then add it to `read_globals`. Otherwise add any missing `local`s to the mod.
|
then add it to `read_globals`. Otherwise, add any missing `local`s to the mod.
|
||||||
* **setting non-standard global variable foobar** - If `foobar` is meant to be a global,
|
* **setting non-standard global variable foobar** - If `foobar` is meant to be a global,
|
||||||
then add it to `globals`. Remove from `read_globals` if present there.
|
then add it to `globals`. Remove from `read_globals` if present there.
|
||||||
Otherwise add any missing `local`s to the mod.
|
Otherwise add any missing `local`s to the mod.
|
||||||
@ -97,12 +97,14 @@ a look at the list below.
|
|||||||
|
|
||||||
## Using with editor
|
## Using with editor
|
||||||
|
|
||||||
It is highly recommended that you find an install a plugin for your editor of choice
|
It is highly recommended that you find and install a plugin for your editor of choice
|
||||||
to show you errors without running a command. Most editors will likely have a plugin
|
to show you errors without running a command. Most editors will likely have a plugin
|
||||||
available.
|
available.
|
||||||
|
|
||||||
* **Atom** - `linter-luacheck`
|
* **Atom** - `linter-luacheck`
|
||||||
* **Sublime** - `SublimeLinter-luacheck`
|
* **Sublime** - Install using package-control:
|
||||||
|
[SublimeLinter](https://github.com/SublimeLinter/SublimeLinter),
|
||||||
|
[SublimeLinter-luacheck](https://github.com/SublimeLinter/SublimeLinter-luacheck)
|
||||||
|
|
||||||
## Checking Commits with Travis
|
## Checking Commits with Travis
|
||||||
|
|
||||||
@ -115,7 +117,7 @@ without downloading the code.
|
|||||||
|
|
||||||
First you should visit [travis-ci.org](https://travis-ci.org/) and sign in with
|
First you should visit [travis-ci.org](https://travis-ci.org/) and sign in with
|
||||||
your Github account. Then find your project's repo in your Travis profile,
|
your Github account. Then find your project's repo in your Travis profile,
|
||||||
and enable travis by flipping the switch.
|
and enable Travis by flipping the switch.
|
||||||
|
|
||||||
Next, create a file called .travis.yml with the following content:
|
Next, create a file called .travis.yml with the following content:
|
||||||
|
|
||||||
@ -142,7 +144,7 @@ change the line after `script:` to:
|
|||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
Now commit and push to Github. Go to your project's page on Github, and click
|
Now commit and push to Github. Go to your project's page on Github, and click
|
||||||
commits. You should see an orange disc next to the commit you just made. After
|
commits. You should see an orange disc next to the commit you just made.
|
||||||
a while it should change either into a green tick or a red cross depending on the
|
After a while it should change either into a green tick or a red cross depending on the
|
||||||
outcome of LuaCheck. In either case, you can click the icon to see the build logs
|
outcome of LuaCheck. In either case, you can click the icon to see the build logs
|
||||||
and the output of LuaCheck.
|
and the output of LuaCheck.
|
||||||
|
@ -8,7 +8,7 @@ redirect_from: /en/chapters/readmore.html
|
|||||||
|
|
||||||
## List of Resources
|
## List of Resources
|
||||||
|
|
||||||
After you've read this book, take a look at the following
|
After you've read this book, take a look at the following.
|
||||||
|
|
||||||
### Minetest Modding
|
### Minetest Modding
|
||||||
|
|
||||||
|
@ -128,14 +128,16 @@ See appendix for an example and a generator.
|
|||||||
|
|
||||||
### description.txt
|
### description.txt
|
||||||
|
|
||||||
This should explain what your mod does.
|
This should explain what your mod does. Be concise without being vague.
|
||||||
Be concise without being vague. It should be short in length
|
It should be short because it will be displayed in the content installer.
|
||||||
because it will be displayed in the mod store.
|
|
||||||
|
|
||||||
For example:
|
Good example:
|
||||||
|
|
||||||
GOOD: Adds soups, cakes, bakes and juices. The food mod which supports the most ingredients.
|
Adds soup, cakes, bakes and juices. The food mod which supports the most ingredients.
|
||||||
BAD: The food mod for Minetest.
|
|
||||||
|
Don't do this:
|
||||||
|
|
||||||
|
(BAD) The food mod for Minetest.
|
||||||
|
|
||||||
### screenshot.png
|
### screenshot.png
|
||||||
|
|
||||||
@ -154,7 +156,7 @@ There are several methods you can use, but you should use the one that works
|
|||||||
best for you, as long as it meets these requirements:\\
|
best for you, as long as it meets these requirements:\\
|
||||||
(and any other requirements which may be added by forum moderators)
|
(and any other requirements which may be added by forum moderators)
|
||||||
|
|
||||||
* **Stable** - The hosting website should be unlikely to shutdown without warning.
|
* **Stable** - The hosting website should be unlikely to shut down without warning.
|
||||||
* **Direct link** - You should be able to click a link on the forum and download the file
|
* **Direct link** - You should be able to click a link on the forum and download the file
|
||||||
without having to view another page.
|
without having to view another page.
|
||||||
* **Virus Free** - Mods with malicious content are not wanted.
|
* **Virus Free** - Mods with malicious content are not wanted.
|
||||||
@ -189,7 +191,7 @@ On Windows, go to the mod's folder. Select all the files.
|
|||||||
Right click, Send To > Compressed (zipped) folder.
|
Right click, Send To > Compressed (zipped) folder.
|
||||||
Rename the resulting zip file to the name of your mod's folder.
|
Rename the resulting zip file to the name of your mod's folder.
|
||||||
|
|
||||||
On the Create a Topic page (see below), go to the "Upload Attachment" tab at the bottom.
|
On the "Create a Topic" page (see below), go to the "Upload Attachment" tab at the bottom.
|
||||||
Click browse and select the zipped file. It is recommended that you
|
Click browse and select the zipped file. It is recommended that you
|
||||||
enter the version of your mod in the comment field.
|
enter the version of your mod in the comment field.
|
||||||
|
|
||||||
|
@ -92,7 +92,7 @@ end)
|
|||||||
You can now run the tests by opening a terminal in the mod's directory and
|
You can now run the tests by opening a terminal in the mod's directory and
|
||||||
running `busted .`
|
running `busted .`
|
||||||
|
|
||||||
It's important that the api file doesn't create the table itself, as globals in
|
It's important that the API file doesn't create the table itself, as globals in
|
||||||
Busted work differently. Any variable which would be global in Minetest is instead
|
Busted work differently. Any variable which would be global in Minetest is instead
|
||||||
a file local in busted. This would have been a better way for Minetest to do things,
|
a file local in busted. This would have been a better way for Minetest to do things,
|
||||||
but it's too late for that now.
|
but it's too late for that now.
|
||||||
|
Loading…
Reference in New Issue
Block a user