Improve wording and grammar [2/3]
This commit is contained in:
parent
ab55b0d779
commit
3819933de0
@ -15,16 +15,16 @@ There are many techniques relevant to working on pixel art textures,
|
||||
and understanding these techniques will greatly improve
|
||||
the quality of the textures you create.
|
||||
|
||||
Detailed approaches to creating good pixel art are outside the scope
|
||||
of this book, and instead only the most relevant basic techniques
|
||||
will be covered.
|
||||
There are many [good online tutorials](http://www.photonstorm.com/art/tutorials-art/16x16-pixel-art-tutorial)
|
||||
available, which cover pixel art in much more detail.
|
||||
|
||||
* [Learning to Draw](#learning-to-draw)
|
||||
* [Techniques](#techniques)
|
||||
* [Editors](#editors)
|
||||
|
||||
## Learning to Draw
|
||||
|
||||
Teaching how to draw good pixel art is out of scope of this book.
|
||||
|
||||
* [16×16 Pixel Art Tutorial on photonstorm.com](http://www.photonstorm.com/art/tutorials-art/16x16-pixel-art-tutorial)
|
||||
|
||||
## Techniques
|
||||
|
||||
### Using the Pencil
|
||||
@ -32,7 +32,7 @@ Teaching how to draw good pixel art is out of scope of this book.
|
||||
The pencil tool is available in most editors. When set to its lowest size,
|
||||
it allows you to edit one pixel at a time without changing any other parts
|
||||
of the image. By manipulating the pixels one at a time, you create clear
|
||||
and sharp textures without unnecessary blurring. It also gives you a high
|
||||
and sharp textures without unintended blurring. It also gives you a high
|
||||
level of precision and control.
|
||||
|
||||
### Tiling
|
||||
@ -50,12 +50,10 @@ to look at.
|
||||
|
||||
### Transparency
|
||||
|
||||
Transparency is important when designing textures for special nodes,
|
||||
such as glass or water, which players should be able to see through,
|
||||
and for craft item textures.
|
||||
It's important to remember that not all editors support transparency,
|
||||
so make sure you choose an editor which is suitable for the textures
|
||||
you wish to create.
|
||||
Transparency is important when creating textures for nearly all craftitems
|
||||
and some nodes, such as glass.
|
||||
Not all editors support transparency, so make sure you choose an
|
||||
editor which is suitable for the textures you wish to create.
|
||||
|
||||
## Editors
|
||||
|
||||
|
@ -14,7 +14,7 @@ redirect_from:
|
||||
## Introduction
|
||||
|
||||
In this chapter you will learn how to use and manipulate inventories, whether
|
||||
that is a player inventory, a node inventory, or a detached inventory.
|
||||
that be a player inventory, a node inventory, or a detached inventory.
|
||||
|
||||
* [What are Item Stacks and Inventories?](#what-are-item-stacks-and-inventories)
|
||||
* [ItemStacks](#itemstacks)
|
||||
@ -47,7 +47,7 @@ ItemStacks have three components to them.
|
||||
The item name may be the item name of a registered item, an alias, or an unknown
|
||||
item name.
|
||||
Unknown items are common when users uninstall mods, or when mods remove items without
|
||||
any mitigation such as registering an alias.
|
||||
precautions, such as registering aliases.
|
||||
|
||||
```lua
|
||||
print(stack:get_name())
|
||||
@ -123,8 +123,8 @@ local inv = player:get_inventory()
|
||||
|
||||
A detached inventory is one which is independent of players or nodes.
|
||||
Detached inventories also don't save over a restart.
|
||||
Detached inventories need to be created before then can be retrieved -
|
||||
this will be covered latter.
|
||||
Detached inventories need to be created before they can be used -
|
||||
this will be covered later.
|
||||
|
||||
```lua
|
||||
local inv = minetest.get_inventory({
|
||||
@ -145,10 +145,10 @@ which all games have, such as the *main* inventory and *craft* slots.
|
||||
|
||||
### Size and Width
|
||||
|
||||
Lists have a size, which is the number of cells in the grid, and a width,
|
||||
which is used when the engine.
|
||||
The List width is not used when drawing the inventory in a window, as the
|
||||
code behind the window determines the width to use.
|
||||
Lists have a size, which is the total number of cells in the grid, and a width,
|
||||
which is only used within the engine.
|
||||
The list width is not used when drawing the inventory in a window,
|
||||
because the code behind the window determines the width to use.
|
||||
|
||||
```lua
|
||||
if inv:set_size("main", 32) then
|
||||
@ -180,7 +180,7 @@ end
|
||||
|
||||
### Adding to a List
|
||||
|
||||
To add items to a list named `"main"`, whilst respecting any maximum stack sizes:
|
||||
To add items to a list named `"main"` while respecting maximum stack sizes:
|
||||
|
||||
```lua
|
||||
local stack = ItemStack("default:stone 99")
|
||||
@ -239,9 +239,9 @@ inv:set_stack(listname, 0, stack)
|
||||
## Wear
|
||||
|
||||
Tools can have wear; wear shows a progress bar and makes the tool break when completely worn.
|
||||
Wear is a number out of 65535, the higher it is, the more worn the tool is.
|
||||
Wear is a number out of 65535; the higher it is, the more worn the tool is.
|
||||
|
||||
Wear can be manipulated using `add_wear()`, `get_wear()` and `set_wear(wear)`.
|
||||
Wear can be manipulated using `add_wear()`, `get_wear()`, and `set_wear(wear)`.
|
||||
|
||||
```lua
|
||||
local stack = ItemStack("default:pick_mese")
|
||||
|
@ -10,7 +10,7 @@ redirect_from: /en/chapters/abms.html
|
||||
## Introduction
|
||||
|
||||
An Active Block Modifier (ABM) is a method of periodically running a
|
||||
function on nodes matching a criteria.
|
||||
function on nodes matching specific criteria.
|
||||
As the name implies, this only works on loaded MapBlocks.
|
||||
|
||||
ABMs are best suited for nodes which are frequently found in the world,
|
||||
@ -20,8 +20,9 @@ to find matching nodes, but they have a low memory and storage overhead.
|
||||
|
||||
For nodes which are uncommon or already use metadata, such as furnaces
|
||||
and machines, node timers should be used instead.
|
||||
Node timers do not require scanning a MapBlock, but they do require slightly
|
||||
more memory and storage to keep track of running timers.
|
||||
Node timers don't involve searching all loaded nodes to find matches,
|
||||
but instead require slightly more memory and storage for the tracking
|
||||
of running timers.
|
||||
|
||||
|
||||
* [Registering an ABM](#registering-an-abm)
|
||||
@ -55,9 +56,8 @@ minetest.register_abm({
|
||||
})
|
||||
```
|
||||
|
||||
This ABM runs every ten seconds.
|
||||
There is a 1 in 50 chance of the ABM running on each node that has the
|
||||
correct name and the correct neighbours.
|
||||
This ABM runs every ten seconds, and for each matching node there is
|
||||
a 1 in 50 chance of it running.
|
||||
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.
|
||||
|
@ -30,12 +30,12 @@ unselectable placeholder node. Empty space is full of *air* nodes, an invisible
|
||||
you can walk through.
|
||||
|
||||
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, and have active entities. The Engine also
|
||||
performs operations on the map, such as performing liquid physics.
|
||||
|
||||
MapBlocks can either be loaded from the world database or generated. MapBlocks
|
||||
will be generated up to the map generation limit (`mapgen_limit`) which is set
|
||||
at its maximum value, 31000, by default. Existing MapBlocks can however be
|
||||
to its maximum value, 31000, by default. Existing MapBlocks can, however, be
|
||||
loaded from the world database outside of the generation limit.
|
||||
|
||||
## Reading
|
||||
@ -52,8 +52,8 @@ 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 ignored when the area is unloaded.
|
||||
* `param1` - See the node definition, will commonly be light.
|
||||
* `name` - The node name, which will be *ignore* when the area is unloaded.
|
||||
* `param1` - See the node definition. This will commonly be light.
|
||||
* `param2` - See the node definition.
|
||||
|
||||
It's worth noting that the function won't load the containing block if the block
|
||||
@ -71,7 +71,7 @@ Minetest offers a number of helper functions to speed up common map actions.
|
||||
The most commonly used of these are for finding nodes.
|
||||
|
||||
For example, say we wanted to make a certain type of plant that grows
|
||||
better near mese. You would need to search for any nearby mese nodes,
|
||||
better near mese; you would need to search for any nearby mese nodes,
|
||||
and adapt the growth rate accordingly.
|
||||
|
||||
```lua
|
||||
@ -204,7 +204,7 @@ local function emerge_callback(pos, action,
|
||||
end
|
||||
```
|
||||
|
||||
This is not the only way of loading blocks; Using a LVM will also cause the
|
||||
This is not the only way of loading blocks; using a LVM will also cause the
|
||||
encompassed blocks to be loaded synchronously.
|
||||
|
||||
## Deleting Blocks
|
||||
|
@ -22,7 +22,7 @@ own.
|
||||
|
||||
Players and Entities are both types of Objects. An Object is something that can move
|
||||
independently of the node grid and has properties such as velocity and scale.
|
||||
An Object is not an item, and they have their own separate registration system.
|
||||
Objects aren't items, and they have their own separate registration system.
|
||||
|
||||
There are a few differences between Players and Entities.
|
||||
The biggest one is that Players are player-controlled, whereas Entities are mod-controlled.
|
||||
@ -82,8 +82,8 @@ The updated properties will be sent to all players in range.
|
||||
This is very useful to get a large amount of variety very cheaply, such as having
|
||||
different skins per-player.
|
||||
|
||||
As shown in the next section, entities can have a default set of properties defined
|
||||
in their definition.
|
||||
As shown in the next section, entities can have initial properties
|
||||
provided in their definition.
|
||||
The default Player properties are defined in the engine, however, so you'll
|
||||
need to use `set_properties()` in `on_joinplayer` to set the properties for newly
|
||||
joined players.
|
||||
@ -115,7 +115,7 @@ function MyEntity:set_message(msg)
|
||||
end
|
||||
```
|
||||
|
||||
When an entity is emerged, a table is created for it by copying everything from
|
||||
When an entity has emerged, a table is created for it by copying everything from
|
||||
its type table.
|
||||
This table can be used to store variables for that particular entity.
|
||||
|
||||
@ -128,7 +128,7 @@ print("entity is at " .. minetest.pos_to_string(object:get_pos()))
|
||||
```
|
||||
|
||||
There are a number of available callbacks for use with entities.
|
||||
A complete list can be found in [lua_api.txt]({{ page.root }}/lua_api.html#registered-entities)
|
||||
A complete list can be found in [lua_api.txt]({{ page.root }}/lua_api.html#registered-entities).
|
||||
|
||||
```lua
|
||||
function MyEntity:on_step(dtime)
|
||||
@ -159,7 +159,7 @@ would be forgotten when the entity becomes inactive then active again.
|
||||
This is because the message isn't saved.
|
||||
Rather than saving everything in the entity table, Minetest gives you control over
|
||||
how to save things.
|
||||
Staticdata is a string which contains all of the custom information that
|
||||
Staticdata is a string which contains all the custom information that
|
||||
needs to stored.
|
||||
|
||||
```lua
|
||||
@ -177,7 +177,7 @@ function MyEntity:on_activate(staticdata, dtime_s)
|
||||
end
|
||||
```
|
||||
|
||||
Minetest may call `get_staticdata()` as many times as it once and at any time.
|
||||
Minetest may call `get_staticdata()` as many times as it wants and at any time.
|
||||
This is because Minetest doesn't wait for a MapBlock to become inactive to save
|
||||
it, as this would result in data loss. MapBlocks are saved roughly every 18
|
||||
seconds, so you should notice a similar interval for `get_staticdata()` being called.
|
||||
@ -225,7 +225,7 @@ An Object's `get_pos()` will always return the global position of the object, no
|
||||
matter whether it is attached or not.
|
||||
`set_attach` takes a relative position, but not as you'd expect.
|
||||
The attachment position is relative to the parent's origin as scaled up by 10 times.
|
||||
So `0,5,0` would be half a node above the parent's origin.
|
||||
So, `0,5,0` would be half a node above the parent's origin.
|
||||
|
||||
For 3D models with animations, the bone argument is used to attach the entity
|
||||
to a bone.
|
||||
|
Loading…
x
Reference in New Issue
Block a user