From d2c94dc8256b4485d4aae57cc9c4de530788c443 Mon Sep 17 00:00:00 2001 From: rubenwardy Date: Sun, 15 Jul 2018 23:04:55 +0100 Subject: [PATCH] Fix a load of typos and grammatical issues --- _en/basics/lua.md | 4 ++-- _en/inventories/itemstacks.md | 10 +++++----- _en/items/node_drawtypes.md | 2 +- _en/items/nodes_items_crafting.md | 5 ++--- _en/map/abms.md | 8 ++++---- _en/map/environment.md | 19 +++++++++---------- _en/map/lvm.md | 6 +++--- _en/map/node_metadata.md | 4 ++-- _en/players/chat.md | 6 +++--- _en/players/chat_complex.md | 6 +++--- _en/players/formspecs.md | 2 +- _en/players/hud.md | 12 ++++++------ _en/players/player_physics.md | 2 +- _en/players/privileges.md | 6 +++--- _en/players/sfinv.md | 4 ++-- _en/quality/clean_arch.md | 18 +++++++++--------- _en/quality/common_mistakes.md | 6 +++--- _en/quality/luacheck.md | 14 ++++++++------ _en/quality/readmore.md | 2 +- _en/quality/releasing.md | 18 ++++++++++-------- _en/quality/unit_testing.md | 2 +- 21 files changed, 79 insertions(+), 77 deletions(-) diff --git a/_en/basics/lua.md b/_en/basics/lua.md index 948cdf1..15ea0d3 100644 --- a/_en/basics/lua.md +++ b/_en/basics/lua.md @@ -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. diff --git a/_en/inventories/itemstacks.md b/_en/inventories/itemstacks.md index baede44..e12570a 100644 --- a/_en/inventories/itemstacks.md +++ b/_en/inventories/itemstacks.md @@ -15,13 +15,13 @@ In this chapter you will learn how to use ItemStacks. * Adding and Taking Items * Wear * Lua Tables -* Meta data +* Metadata * More Methods ## 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: @@ -120,9 +120,9 @@ local data = items:to_table() local items2 = ItemStack(data) {% 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 %} local meta = items:get_meta() diff --git a/_en/items/node_drawtypes.md b/_en/items/node_drawtypes.md index d094fc0..77a5810 100644 --- a/_en/items/node_drawtypes.md +++ b/_en/items/node_drawtypes.md @@ -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. diff --git a/_en/items/nodes_items_crafting.md b/_en/items/nodes_items_crafting.md index b14cb5f..9d5a796 100644 --- a/_en/items/nodes_items_crafting.md +++ b/_en/items/nodes_items_crafting.md @@ -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. diff --git a/_en/map/abms.md b/_en/map/abms.md index 6cd50d2..71e58b6 100644 --- a/_en/map/abms.md +++ b/_en/map/abms.md @@ -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. diff --git a/_en/map/environment.md b/_en/map/environment.md index 0718909..174b649 100644 --- a/_en/map/environment.md +++ b/_en/map/environment.md @@ -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 @@ -142,13 +142,13 @@ local node = minetest.get_node({ x = 1, y = 3, z = 4 }) print(node.name) --> default:mese {% 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 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 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 %} 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 -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 %} diff --git a/_en/map/lvm.md b/_en/map/lvm.md index a41dc81..f1cbf88 100644 --- a/_en/map/lvm.md +++ b/_en/map/lvm.md @@ -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`. diff --git a/_en/map/node_metadata.md b/_en/map/node_metadata.md index f697c19..a22e995 100644 --- a/_en/map/node_metadata.md +++ b/_en/map/node_metadata.md @@ -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() diff --git a/_en/players/chat.md b/_en/players/chat.md index 375ae11..b138c13 100644 --- a/_en/players/chat.md +++ b/_en/players/chat.md @@ -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 `. Lets go through left to right: +The above implements `/msg `. 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 diff --git a/_en/players/chat_complex.md b/_en/players/chat_complex.md index 35cba26..12df301 100644 --- a/_en/players/chat_complex.md +++ b/_en/players/chat_complex.md @@ -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`. diff --git a/_en/players/formspecs.md b/_en/players/formspecs.md index 3c376d9..ed05ada 100644 --- a/_en/players/formspecs.md +++ b/_en/players/formspecs.md @@ -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. diff --git a/_en/players/hud.md b/_en/players/hud.md index 7cc2acf..7ceb23c 100644 --- a/_en/players/hud.md +++ b/_en/players/hud.md @@ -79,13 +79,13 @@ score panel like so: alt="screenshot of the HUD we're aiming for"> -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 diff --git a/_en/players/player_physics.md b/_en/players/player_physics.md index 4d122ad..4f8478d 100644 --- a/_en/players/player_physics.md +++ b/_en/players/player_physics.md @@ -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 diff --git a/_en/players/privileges.md b/_en/players/privileges.md index 0197684..c87e3cf 100644 --- a/_en/players/privileges.md +++ b/_en/players/privileges.md @@ -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 diff --git a/_en/players/sfinv.md b/_en/players/sfinv.md index de18d5e..8bec0ab 100644 --- a/_en/players/sfinv.md +++ b/_en/players/sfinv.md @@ -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! diff --git a/_en/quality/clean_arch.md b/_en/quality/clean_arch.md index af7a052..27b3af7 100644 --- a/_en/quality/clean_arch.md +++ b/_en/quality/clean_arch.md @@ -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.
Diagram showing a centered text element
diff --git a/_en/quality/common_mistakes.md b/_en/quality/common_mistakes.md index a026583..575a482 100644 --- a/_en/quality/common_mistakes.md +++ b/_en/quality/common_mistakes.md @@ -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) diff --git a/_en/quality/luacheck.md b/_en/quality/luacheck.md index 1f9cc09..3e9104f 100644 --- a/_en/quality/luacheck.md +++ b/_en/quality/luacheck.md @@ -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. diff --git a/_en/quality/readmore.md b/_en/quality/readmore.md index 3acb9f3..4350a51 100644 --- a/_en/quality/readmore.md +++ b/_en/quality/readmore.md @@ -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 diff --git a/_en/quality/releasing.md b/_en/quality/releasing.md index 33f9ab1..73f55ad 100644 --- a/_en/quality/releasing.md +++ b/_en/quality/releasing.md @@ -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 @@ -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:\\ (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 without having to view another page. * **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. 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. diff --git a/_en/quality/unit_testing.md b/_en/quality/unit_testing.md index 416ff99..56da6d6 100644 --- a/_en/quality/unit_testing.md +++ b/_en/quality/unit_testing.md @@ -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.