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)
|
||||
{% 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
|
||||
"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**.
|
||||
@ -280,7 +280,7 @@ one()
|
||||
two()
|
||||
{% 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)
|
||||
|
||||
The same goes for functions. Functions are variables of a special type.
|
||||
|
@ -20,8 +20,8 @@ In this chapter you will learn how to use ItemStacks.
|
||||
|
||||
## Creating ItemStacks
|
||||
|
||||
An item stack is a... stack of items. It's basically just an item type with
|
||||
a count of items in the stack.
|
||||
An item stack is a... stack of items.
|
||||
It's basically just an item type with a count of items in the stack.
|
||||
|
||||
You can create a stack like so:
|
||||
|
||||
|
@ -341,7 +341,7 @@ The most important part is the nodebox table:
|
||||
{-0.5, 0, 0, 0.5, 0.5, 0.5}
|
||||
{% 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 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.
|
||||
|
@ -194,8 +194,7 @@ The is_ground_content attribute allows caves to be generated over the stone.
|
||||
|
||||
## Crafting
|
||||
|
||||
There are several different types of crafting,
|
||||
identified by the ``type`` property.
|
||||
There are several types of crafting, identified by the ``type`` property.
|
||||
|
||||
* shaped - Ingredients must be in the correct position.
|
||||
* 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
|
||||
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
|
||||
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,
|
||||
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
|
||||
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.
|
||||
|
||||
* [Example: Growing Alien Grass](#example-growing-alien-grass)
|
||||
@ -47,12 +47,12 @@ minetest.register_abm({
|
||||
{% endhighlight %}
|
||||
|
||||
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 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.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
* **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").
|
||||
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
|
||||
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
|
||||
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.
|
||||
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.
|
||||
* `param2` - See the node definition.
|
||||
|
||||
@ -91,7 +91,7 @@ if node_pos then
|
||||
end
|
||||
{% 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:
|
||||
|
||||
{% 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.
|
||||
|
||||
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
|
||||
similar way and are useful in other circumstances.
|
||||
`find_nodes_with_meta` and `find_nodes_in_area_under_air`, which work similarly
|
||||
and are useful in other circumstances.
|
||||
|
||||
## Writing
|
||||
|
||||
@ -156,8 +156,7 @@ minetest.swap_node({ x = 1, y = 3, z = 4 }, { name = "default:mese" })
|
||||
|
||||
### Removing Nodes
|
||||
|
||||
A node must always be present. When someone says to remove a node, what
|
||||
is usually meant is they want to set the node to `air`.
|
||||
A node must always be present. To remove a node, you set the position to `air`.
|
||||
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
{% highlight lua %}
|
||||
|
@ -42,7 +42,7 @@ local emin, emax = vm:read_from_map(pos1, pos2)
|
||||
{% endhighlight %}
|
||||
|
||||
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
|
||||
it contains for you - whether that involves loading from memory, from disk, or
|
||||
calling the map generator.
|
||||
@ -95,7 +95,7 @@ end
|
||||
{% endhighlight %}
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
`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
|
||||
date using `minetest.fix_light`.
|
||||
|
||||
|
@ -72,7 +72,7 @@ The functions available include:
|
||||
* get_float
|
||||
* 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 %}
|
||||
local value = minetest.is_yes(meta:get_string("key"))
|
||||
@ -103,7 +103,7 @@ This can be done using the following functions:
|
||||
|
||||
## 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 %}
|
||||
local tmp = meta:to_table()
|
||||
|
@ -48,7 +48,7 @@ only visible to the named player, in this case player1.
|
||||
### Older Mods
|
||||
|
||||
Occasionally you'll see mods where the chat_send_player function includes a
|
||||
boolean:
|
||||
Boolean:
|
||||
|
||||
{% highlight lua %}
|
||||
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 .. "!"
|
||||
{% 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.
|
||||
|
||||
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_-]+) (*+)$")
|
||||
{% 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.
|
||||
* `()` 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
|
||||
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
|
||||
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.
|
||||
|
||||
`: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`
|
||||
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
|
||||
`word`.
|
||||
|
||||
|
@ -164,7 +164,7 @@ want to do.
|
||||
|
||||
### 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,
|
||||
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">
|
||||
</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
|
||||
to the right of the window, but to resize without breaking.
|
||||
|
||||
## 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 %}
|
||||
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}`.
|
||||
|
||||
The text's color in [Hexadecimal form](http://www.colorpicker.com/), eg: `0xFF0000`,
|
||||
and stored in
|
||||
`number` is the text's colour, and is in [Hexadecimal form](http://www.colorpicker.com/), eg: `0xFF0000`.
|
||||
|
||||
|
||||
### 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 %}
|
||||
player:hud_add({
|
||||
@ -222,7 +221,8 @@ player:hud_add({
|
||||
})
|
||||
{% 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
|
||||
|
||||
|
@ -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:
|
||||
|
||||
* 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
|
||||
|
||||
|
@ -136,15 +136,15 @@ minetest.set_player_privs(name, privs)
|
||||
## Adding Privileges to basic_privs
|
||||
|
||||
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
|
||||
grant and revoke `interact` and `shout`, but can't grant themselves or other
|
||||
set of privileges. It's common to give this privilege to moderators, so that
|
||||
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.
|
||||
|
||||
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.
|
||||
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
|
||||
|
||||
|
@ -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.
|
||||
|
||||
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.
|
||||
|
||||
* [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
|
||||
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
|
||||
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.
|
||||
|
||||
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
|
||||
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
|
||||
to the data, but you won't need to test that an event calls an action (as this
|
||||
would require using the Minetest API, and this area of code should be made as
|
||||
small as possible anyway.)
|
||||
In your tests, you will be able to make sure that an action when triggered does
|
||||
the right thing to the data, but you won't need to test that an event calls an
|
||||
action (as this would require using the Minetest API, and this area of code
|
||||
should be made as small as possible anyway.)
|
||||
|
||||
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
|
||||
@ -86,7 +86,7 @@ functions are called.
|
||||
{% highlight lua %}
|
||||
-- Data
|
||||
function land.create(name, area_name)
|
||||
land.lands[aname] = {
|
||||
land.lands[area_name] = {
|
||||
name = area_name,
|
||||
owner = name,
|
||||
-- more stuff
|
||||
@ -152,14 +152,14 @@ most of the calculations are made.
|
||||
The controller should have no knowledge about the Minetest API - notice how
|
||||
there are no Minetest calls or any view functions that resemble them.
|
||||
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
|
||||
to the Minetest API at all.
|
||||
|
||||
<figure class="right_image">
|
||||
<img
|
||||
width="100%"
|
||||
src="{{ page.root }}//static/mvc_diagram.svg"
|
||||
src="{{ page.root }}/static/mvc_diagram.svg"
|
||||
alt="Diagram showing a centered text element">
|
||||
</figure>
|
||||
|
||||
|
@ -64,7 +64,7 @@ Malicious clients can submit formspecs whenever they like with whatever content
|
||||
they like.
|
||||
|
||||
The following code has a vulnerability where any player can give
|
||||
themself moderator privileges:
|
||||
themselves moderator privileges:
|
||||
|
||||
{% highlight lua %}
|
||||
local function show_formspec(name)
|
||||
@ -130,7 +130,7 @@ inv:set_stack("main", 1, stack)
|
||||
{% endhighlight %}
|
||||
|
||||
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.
|
||||
|
||||
Avoid this:
|
||||
@ -143,7 +143,7 @@ end)
|
||||
{% endhighlight %}
|
||||
|
||||
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 %}
|
||||
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
|
||||
|
||||
* **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,
|
||||
then add it to `globals`. Remove from `read_globals` if present there.
|
||||
Otherwise add any missing `local`s to the mod.
|
||||
@ -97,12 +97,14 @@ a look at the list below.
|
||||
|
||||
## 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
|
||||
available.
|
||||
|
||||
* **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
|
||||
|
||||
@ -115,7 +117,7 @@ without downloading the code.
|
||||
|
||||
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,
|
||||
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:
|
||||
|
||||
@ -142,7 +144,7 @@ change the line after `script:` to:
|
||||
{% endhighlight %}
|
||||
|
||||
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
|
||||
a while it should change either into a green tick or a red cross depending on the
|
||||
commits. You should see an orange disc next to the commit you just made.
|
||||
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
|
||||
and the output of LuaCheck.
|
||||
|
@ -8,7 +8,7 @@ redirect_from: /en/chapters/readmore.html
|
||||
|
||||
## 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
|
||||
|
||||
|
@ -128,14 +128,16 @@ See appendix for an example and a generator.
|
||||
|
||||
### description.txt
|
||||
|
||||
This should explain what your mod does.
|
||||
Be concise without being vague. It should be short in length
|
||||
because it will be displayed in the mod store.
|
||||
This should explain what your mod does. Be concise without being vague.
|
||||
It should be short because it will be displayed in the content installer.
|
||||
|
||||
For example:
|
||||
Good example:
|
||||
|
||||
GOOD: Adds soups, cakes, bakes and juices. The food mod which supports the most ingredients.
|
||||
BAD: The food mod for Minetest.
|
||||
Adds soup, cakes, bakes and juices. The food mod which supports the most ingredients.
|
||||
|
||||
Don't do this:
|
||||
|
||||
(BAD) The food mod for Minetest.
|
||||
|
||||
### screenshot.png
|
||||
|
||||
@ -189,7 +191,7 @@ On Windows, go to the mod's folder. Select all the files.
|
||||
Right click, Send To > Compressed (zipped) 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
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
Loading…
Reference in New Issue
Block a user