diff --git a/src/main/resources/assets/oc2r/doc/en_us/basics.md b/src/main/resources/assets/oc2r/doc/en_us/basics.md index 29fd6687..b5736084 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/basics.md +++ b/src/main/resources/assets/oc2r/doc/en_us/basics.md @@ -1,27 +1,33 @@ # Basics + This document contains some foundational information on how [computers](block/computer.md) work. This does not necessarily mean that this information is easy reading. Basic here means the general concepts in use. ## Architecture + Computers run on a single-core, general purpose RISC-V architecture. This means they have 64-bit registers and support floating point operations. This makes it possible to boot a modern Linux kernel on them. ### Native Devices + Native devices connected to computers are memory-mapped devices. This means they are mapped to some area in physical memory. Computers use regular Linux drivers to interact with them. What devices are available, and where those devices live, is communicated to the software running on the computer using a flattened device tree. This data structure may contain additional information on the system in general. In particular, it also stores the size of the installed [memory](item/memory.md). Since this data structure gets copied during boot, it cannot be updated later on. This is the reason computers must be rebooted when changes to native devices, such as the [network interface card](item/network_interface_card.md), are made. Devices for which this is the case will typically have a corresponding note in their tooltip. ### HLAPI Devices + The other type of device are high level API devices, sometimes also called RPC devices. These devices use a single controller which communicates with the computers via single serial device. This controller device is present in all computers, and takes care of collecting messages from multiple devices, and dispatching messages to devices. The protocol this controller uses is a simple JSON message based protocol. The `devices` Lua library provided with the default Linux library wraps around the serial device used to connect to this controller. As such, using the `devices` library whenever using a HLAPI device, such as the [redstone interface block](block/redstone_interface.md), is *strongly* recommended. Due to the nature of the employed protocol, data rate is rather limited. Most devices therefore usually only provide comparatively simple APIs which do not require sending large amounts of data either way. ## Configuration + Computers can be configured to some degree. The amount of memory, extra storage in the form of [hard drives](item/hard_drive.md) and most importantly, which cards to install, are largely up to the user. Note that the default Linux distribution does require at least 20M of memory, 24M are recommended. Most components contribute to the overall energy consumption of a computer. To conserve energy, choosing only the necessary components is essential. ## Linux + The default Linux distribution contains some basic command line tools, and the ability to write and run Lua programs. For an overview of how to interact with HLAPI devices using Lua, please see the [scripting](scripting.md) manual entry. -Native devices use regular Linux drivers. For example, hard drives show up as `/dev/vdaX` devices and can be formatted and mounted regularly. +Native devices use regular Linux drivers. For example, hard drives show up as */dev/vdaX* devices and can be formatted and mounted regularly. -Computers provide two hardware clock (RTC) devices. The first one counts time in a scale most users will think in. It is used by default, for example by command line tools like `date` and `time`. The second one measures time as it works in the world the computer runs in. To obtain the current world time, use `hwclock -f /dev/rtc1`. \ No newline at end of file +Computers provide two hardware clock (RTC) devices. The first one counts time in a scale most users will think in. It is used by default, for example by command line tools like *date* and *time*. The second one measures time as it works in the world the computer runs in. To obtain the current world time, use *hwclock -f /dev/rtc1*. diff --git a/src/main/resources/assets/oc2r/doc/en_us/block/bus_interface.md b/src/main/resources/assets/oc2r/doc/en_us/block/bus_interface.md index bdda5162..ee1901a8 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/block/bus_interface.md +++ b/src/main/resources/assets/oc2r/doc/en_us/block/bus_interface.md @@ -1,8 +1,9 @@ # Bus Interface + ![Plug and play](item:oc2r:bus_interface) Bus interfaces connect external devices to [computers](computer.md). This includes explicit device blocks, such as the [redstone interface](redstone_interface.md). Some generic functionality blocks of blocks is also available, such as information on energy storage. -It is possible to configure an explicit name for a bus interface using a [wrench](../item/wrench.md). This is useful when attaching multiple devices of the same type to a computer: when searching devices by type name (`devices:find(typeName)`), these custom names will also work. - +It is possible to configure an explicit name for a bus interface using a [wrench](../item/wrench.md). This is useful when attaching multiple devices of the same type to a computer: when searching devices by type name (*devices:find(typeName)*), these custom names will also work. + Note that [computers](computer.md) must also be explicitly connected to a [bus](bus_cable.md) with a bus connector. diff --git a/src/main/resources/assets/oc2r/doc/en_us/block/disk_drive.md b/src/main/resources/assets/oc2r/doc/en_us/block/disk_drive.md index 88a972fe..13480042 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/block/disk_drive.md +++ b/src/main/resources/assets/oc2r/doc/en_us/block/disk_drive.md @@ -6,14 +6,14 @@ at runtime, unlike [hard drives](../item/hard_drive.md). Note that it is highly advisable to explicitly unmount your floppy before removing it from the drive to avoid data loss. -On a Linux system, disk drives will typically appear as `/dev/vdX` devices, following any installed hard drives. They +On a Linux system, disk drives will typically appear as */dev/vdX* devices, following any installed hard drives. They are not automatically formatted or mounted, but will only appear as raw block devices. To use them, you'll need to configure them, first. For example, on the default Linux distribution, the following commands will be useful: -- `mke2fs /dev/vdX` to format a floppy disk. Run this when first installing the disk. *Will erase data on floppy!* -- `mount /dev/vdX ` to mount a floppy disk after formatting it. Make sure the directory you want to +- *mke2fs /dev/vdX* to format a floppy disk. Run this when first installing the disk. *Will erase data on floppy!* +- *mount /dev/vdX * to mount a floppy disk after formatting it. Make sure the directory you want to mount it to exists and is empty. -- `umount ` to unmount a floppy disk. Make sure to run this before removing the floppy from the disk +- *umount * to unmount a floppy disk. Make sure to run this before removing the floppy from the disk drive, to avoid data loss. Computers *have to be shut down* before installing or removing this component. Installing it while the computer is diff --git a/src/main/resources/assets/oc2r/doc/en_us/block/flash_memory_flasher.md b/src/main/resources/assets/oc2r/doc/en_us/block/flash_memory_flasher.md index 963b794c..86c22bce 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/block/flash_memory_flasher.md +++ b/src/main/resources/assets/oc2r/doc/en_us/block/flash_memory_flasher.md @@ -3,12 +3,12 @@ The memory flasher provides a way to flash custom compiled firmware onto a flash chip for your computer. -On a Linux system, the memory flasher will typically appear as `/dev/vdX` devices, following any installed hard drives. On a technical level flash memory chips work exactly like a floppy or +On a Linux system, the memory flasher will typically appear as */dev/vdX* devices, following any installed hard drives. On a technical level flash memory chips work exactly like a floppy or hard drive does from this mod, so you could use it for data storage or sharing though they are primarily intended for firmware storage. -To flash the device you should use the `flash.sh` script found in the `/mnt/builtin/bin` directory of the default linux distro. You can use it as follows: +To flash the device you should use the *flash.sh* script found in the */mnt/builtin/bin* directory of the default linux distro. You can use it as follows: -- `flash.sh [device path] [firmware file path] (use opensbi, yes or no, if ommitted opensbi will not be used)` +- *flash.sh [device path] [firmware file path] (use opensbi, yes or no, if ommitted opensbi will not be used)* OpenSBI is an open source loader/bootstrapper for RISC-V systems that makes developing kernels much simpler. Further information about building custom kernels is outside the scope of this documentation. diff --git a/src/main/resources/assets/oc2r/doc/en_us/block/keyboard.md b/src/main/resources/assets/oc2r/doc/en_us/block/keyboard.md index d344bb67..af446bb6 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/block/keyboard.md +++ b/src/main/resources/assets/oc2r/doc/en_us/block/keyboard.md @@ -1,9 +1,10 @@ # Keyboard + ![To click or not to click](block:oc2r:keyboard) The keyboard allows key presses to be picked up by [computers](computer.md). Its primary use-case is in combination with a [projector](projector.md), when using a Linux system. -When using the default Linux distribution, this device will provide events via the `evdev` system. To use its input this without additional configuration, use a [projector](projector.md). The keyboard input will be sent to the terminal session displayed there. +When using the default Linux distribution, this device will provide events via the *evdev* system. To use its input this without additional configuration, use a [projector](projector.md). The keyboard input will be sent to the terminal session displayed there. Note that the only face of the keyboard device large enough to fit a bus interface is at the bottom. Keyboards may be placed anywhere, as long as they're connected to the computer via a bus. diff --git a/src/main/resources/assets/oc2r/doc/en_us/block/monitor.md b/src/main/resources/assets/oc2r/doc/en_us/block/monitor.md index e2737c43..b8568fc5 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/block/monitor.md +++ b/src/main/resources/assets/oc2r/doc/en_us/block/monitor.md @@ -5,7 +5,7 @@ The monitor, like the projector, provides a framebuffer device to [computers](co Monitors need to be powered directly to function. The device bus cannot provide enough energy on its own. When insufficiently powered, this is indicated by a red error text on the screen. -On a Linux system, monitors will typically appear as `/dev/fbX` devices. To send data to the framebuffer, it is possible to write to these devices. For example, to clear a framebuffer one might pipe zeros to the device like so: `cat /dev/zero > /dev/fb0`. +On a Linux system, monitors will typically appear as */dev/fbX* devices. To send data to the framebuffer, it is possible to write to these devices. For example, to clear a framebuffer one might pipe zeros to the device like so: *cat /dev/zero > /dev/fb0*. The monitor provides a built-in keyboard for usage with the default Linux distro, this feature may be interrupted by having another keyboard device connected to the same computer. diff --git a/src/main/resources/assets/oc2r/doc/en_us/block/projector.md b/src/main/resources/assets/oc2r/doc/en_us/block/projector.md index c3d686d7..8f06bfc4 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/block/projector.md +++ b/src/main/resources/assets/oc2r/doc/en_us/block/projector.md @@ -5,7 +5,7 @@ The projector provides a framebuffer device to [computers](computer.md). They ha Projectors need to be powered directly to function. The device bus cannot provide enough energy on its own. When insufficiently powered, this is indicated by a red glow in the projector's lens. -On a Linux system, projectors will typically appear as `/dev/fbX` devices. To send data to the framebuffer, it is possible to write to these devices. For example, to clear a framebuffer one might pipe zeros to the device like so: `cat /dev/zero > /dev/fb0`. +On a Linux system, projectors will typically appear as */dev/fbX* devices. To send data to the framebuffer, it is possible to write to these devices. For example, to clear a framebuffer one might pipe zeros to the device like so: *cat /dev/zero > /dev/fb0*. When using the default Linux distribution, the [keyboard](keyboard.md) may be used, to send input to the virtual terminal, running on the first connected framebuffer. diff --git a/src/main/resources/assets/oc2r/doc/en_us/block/redstone_interface.md b/src/main/resources/assets/oc2r/doc/en_us/block/redstone_interface.md index 88449cc0..e2d964b4 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/block/redstone_interface.md +++ b/src/main/resources/assets/oc2r/doc/en_us/block/redstone_interface.md @@ -6,32 +6,32 @@ The redstone interface provides an omnidirectional bus to receive and emit redst Use this to interact with primitive devices, such as doors and lamps, or other machinery offering a redstone based protocol. This is a high level device. It must be controlled using the high level device API. The default Linux distribution offers Lua libraries for this API. For example: -`local d = require("devices")` -`local r = d:find("redstone")` -`r:setRedstoneOutput("up", 15)` +*local d = require("devices")* +*local r = d:find("redstone")* +*r:setRedstoneOutput("up", 15)* ## API -Device name: `redstone` +Device name: *redstone* ### Sides -The side parameter in the following methods represents a side local to the device block. Valid values are: `up`, `down`, `left`, `right`, `front`, `back`, `north`, `south`, `west` and `east`. +The side parameter in the following methods represents a side local to the device block. Valid values are: *up*, *down*, *left*, *right*, *front*, *back*, *north*, *south*, *west* and *east*. Each face of the block has an indicator for convenience. Side names represent the names with the block seen from the primary face (indicated by a single marking). When looking at the primary face: -- `front` and `south` is the face we are looking at. -- `back` and `north` is the face behind the block. -- `left` and `west` is the face to our left. -- `right` and `east` is the face to our right. -- `up` and `down` are the top and bottom faces. +- *front* and *south* is the face we are looking at. +- *back* and *north* is the face behind the block. +- *left* and *west* is the face to our left. +- *right* and *east* is the face to our right. +- *up* and *down* are the top and bottom faces. ### Methods -`getRedstoneInput(side):number` gets the received redstone signal for the specified side. -- `side` is a string representing the side to get the input on. See the "Sides" section. +*getRedstoneInput(side):number* gets the received redstone signal for the specified side. +- *side* is a string representing the side to get the input on. See the "Sides" section. - Returns the number representing the current input signal strength. -`setRedstoneOutput(side, value:number)` sets the emitted redstone signal for the specified side. -- `side` is a string representing the side to set the signal on. See the "Sides" section. -- `value` is a number representing the signal strength to set in the range of [0, 15]. +*setRedstoneOutput(side, value:number)* sets the emitted redstone signal for the specified side. +- *side* is a string representing the side to set the signal on. See the "Sides" section. +- *value* is a number representing the signal strength to set in the range of [0, 15]. -`getRedstoneOutput(side):number` gets the emitted redstone signal for the specified side. -- `side` is a string representing the side to get the output on. See the "Sides" section. +*getRedstoneOutput(side):number* gets the emitted redstone signal for the specified side. +- *side* is a string representing the side to get the output on. See the "Sides" section. - Returns the number representing the current output signal strength. diff --git a/src/main/resources/assets/oc2r/doc/en_us/getting_started.md b/src/main/resources/assets/oc2r/doc/en_us/getting_started.md index 37c45f74..fca74fbc 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/getting_started.md +++ b/src/main/resources/assets/oc2r/doc/en_us/getting_started.md @@ -1,8 +1,11 @@ # Getting Started + This article describes the steps required to get a [computer](block/computer.md) up and running, and gives an example of how it can be used to interact with devices. ## Building + First things first, you need an actual computer, plus a couple of components. If you haven't already, craft these first: + - 1x [computer](block/computer.md) - 1x **Linux** [hard drive](item/hard_drive.md) (regular 8M hard drive, then craft it with a [wrench](item/wrench.md)) - 3x 8M [Memory](item/memory.md) @@ -14,6 +17,7 @@ Once you got all this, place down the computer. Open its inventory screen using ![Computer inventory](../img/getting_started_inventory.png) ## Starting + To power up your freshly build computer, you'll usually need to supply it with some power. Have a look at the energy bar to the left of the terminal or inventory screen. Its tooltip informs you of the current amount of energy stored in the computer, and the amount of energy it requires per tick to keep running. ![Computer energy info](../img/getting_started_energy.png) @@ -22,8 +26,8 @@ When you've ensured the required amount of energy is available, switch to the te ![Login prompt](../img/getting_started_login.png) -Enter `root` as the user name to log in with and press enter. Well done, you now have a computer that's ready for use! +Enter *root* as the user name to log in with and press enter. Well done, you now have a computer that's ready for use! You can now add more devices, depending on what you want to use your computer for. For information on how to control devices, have a look at the [scripting](scripting.md) manual entry. -Good luck, and most importantly, have fun! \ No newline at end of file +Good luck, and most importantly, have fun! diff --git a/src/main/resources/assets/oc2r/doc/en_us/index.md b/src/main/resources/assets/oc2r/doc/en_us/index.md index 8983d411..4eecc9e6 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/index.md +++ b/src/main/resources/assets/oc2r/doc/en_us/index.md @@ -1,27 +1,33 @@ # The Computerists Handbook + Hello, greetings, welcome! If you've come here, you either stumbled in by accident, are interested in [building your first computer](getting_started.md), or maybe you are looking for information on a particular [block](block/index.md) or [item](item/index.md)? ## Overview + [Computers](block/computer.md) offer a variety of uses, from recreational to large-scale, highly customizable automation of other machines and devices. At the heart of each computer lies its operating system (OS). The default OS provided is a very basic Linux distribution. It offers just the most basic command line tools, as well as the means to write and run Lua programs. -Lua is very relevant when it comes to interacting with high level API devices (HLAPI), such as the [redstone interface block](block/redstone_interface.md). With the default OS come some utility libraries to enable interacting with such devices, in particular the `devices` library. To learn more about how to interact with HLAPI devices from Lua, see the [scripting](scripting.md) manual entry. +Lua is very relevant when it comes to interacting with high level API devices (HLAPI), such as the [redstone interface block](block/redstone_interface.md). With the default OS come some utility libraries to enable interacting with such devices, in particular the *devices* library. To learn more about how to interact with HLAPI devices from Lua, see the [scripting](scripting.md) manual entry. On the other end of the scale are native devices, such as [hard drives](item/hard_drive.md) and the [network interface card](item/network_interface_card.md). These devices are controlled by native Linux drivers and will require a restart of the system when added or removed. Most devices you will encounter will be HLAPI devices, however. ## Getting Started -If you just want to get running quickly, read the [getting started guide](getting_started.md). It contains a step-by-step description on how to build your first computer and how to start working with it. To learn more about some topic in particular, see the referenced topical pages in the "Reference" section. + +If you just want to get running quickly, read the [getting started guide](getting_started.md). It contains a step-by-step description on how to build your first computer and how to start working with it. To learn more about some topic in particular, see the referenced topical pages in the "Reference" section. ## Reference + This manual contains reference information on the blocks and items related to computers and the like. If you're looking for information on a particular block or item, have a look at the respective glossaries: + - [List of blocks](block/index.md) - [List of items](item/index.md) If you're interested in a particular topic, there are some overview entries for the more common ones: + - [Basics](basics.md) - [Scripting](scripting.md) - [Robotics](robotics.md) -- [Networking](networking.md) \ No newline at end of file +- [Networking](networking.md) diff --git a/src/main/resources/assets/oc2r/doc/en_us/item/block_operations_module.md b/src/main/resources/assets/oc2r/doc/en_us/item/block_operations_module.md index 89089b15..fbe9c3e2 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/item/block_operations_module.md +++ b/src/main/resources/assets/oc2r/doc/en_us/item/block_operations_module.md @@ -4,27 +4,27 @@ The block operations module provides to [robots](robot.md) the ability to break and place blocks in the world. ## API -Device name: `block_operations` +Device name: *block_operations* This is a high level API device. It can be controlled using Lua in the default Linux distribution. For example: -`local d = require("devices")` -`local m = d:find("block_operations")` -`m:excavate("front")` +*local d = require("devices")* +*local m = d:find("block_operations")* +*m:excavate("front")* ### Sides -The side parameter in the following methods represents a direction from the perspective of the robot. Valid values are: `front`, `up` and `down`. +The side parameter in the following methods represents a direction from the perspective of the robot. Valid values are: *front*, *up* and *down*. ### Methods -`excavate([side]):boolean` tries to break a block in the specified direction. Collected blocks will be inserted starting at the currently selected inventory slot. If the selected slot is full, the next slot will be used, and so on. If the inventory has no space for the dropped block, it will drop into the world. -- `side` is the relative direction in to break a block in. Optional, defaults to `front`. See the "Sides" section. +*excavate([side]):boolean* tries to break a block in the specified direction. Collected blocks will be inserted starting at the currently selected inventory slot. If the selected slot is full, the next slot will be used, and so on. If the inventory has no space for the dropped block, it will drop into the world. +- *side* is the relative direction in to break a block in. Optional, defaults to *front*. See the "Sides" section. - Returns whether the operation was successful. -`place([side]):boolean` tries to place a block in the specified direction. Blocks will be placed from the currently selected inventory slot. If the slot is empty, no block will be placed. -- `side` is the relative direction to place the block in. Optional, defaults to `front`. See the "Sides" section. +*place([side]):boolean* tries to place a block in the specified direction. Blocks will be placed from the currently selected inventory slot. If the slot is empty, no block will be placed. +- *side* is the relative direction to place the block in. Optional, defaults to *front*. See the "Sides" section. - Returns whether the operation was successful. -`durability():number` returns the remaining durability of the module's excavation tool. Once the durability has reached zero, no further excavation operations can be performed until it is repaired. +*durability():number* returns the remaining durability of the module's excavation tool. Once the durability has reached zero, no further excavation operations can be performed until it is repaired. - Returns the remaining durability of the module's excavation tool -`repair():boolean` attempts to repair the module's excavation tool using materials in the currently selected inventory slot. This method will consume one item at a time. Any regular tool may act as the source for repair materials, such as pickaxes and shovels. The quality of the tool directly effects the amount of durability restored. +*repair():boolean* attempts to repair the module's excavation tool using materials in the currently selected inventory slot. This method will consume one item at a time. Any regular tool may act as the source for repair materials, such as pickaxes and shovels. The quality of the tool directly effects the amount of durability restored. - Returns whether some material could be used to repair the module's excavation tool. diff --git a/src/main/resources/assets/oc2r/doc/en_us/item/file_import_export_card.md b/src/main/resources/assets/oc2r/doc/en_us/item/file_import_export_card.md index af000214..0dd4e04a 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/item/file_import_export_card.md +++ b/src/main/resources/assets/oc2r/doc/en_us/item/file_import_export_card.md @@ -5,10 +5,10 @@ The file import/export card allows breaking the fourth wall. It allows: - uploading files from your real computer into a virtual [computer](../block/computer.md). - downloading files from a virtual computer onto your real computer. -For added convenience, the default Linux distribution provides two utility scripts for these operations, `import.lua` and `export.lua`. +For added convenience, the default Linux distribution provides two utility scripts for these operations, *import.lua* and *export.lua*. -`import.lua` will, when run, prompt for a file to upload to the virtual computer. The file will be stored in the current working directory. If a file with the name of the imported file already exists, the option to provide an alternative name will be offered. +*import.lua* will, when run, prompt for a file to upload to the virtual computer. The file will be stored in the current working directory. If a file with the name of the imported file already exists, the option to provide an alternative name will be offered. -`export.lua` takes as its parameter the path to a file in a virtual computer. It then downloads this file to your real computer and offers a save dialog, offering the choice of where to save the downloaded file, or to cancel the operation. +*export.lua* takes as its parameter the path to a file in a virtual computer. It then downloads this file to your real computer and offers a save dialog, offering the choice of where to save the downloaded file, or to cancel the operation. -Both scripts will prompt all users currently interacting with the computer's terminal. For upload operations (`import.lua`), the first uploaded file will be used. The prompts on other clients will be canceled. For download operations all clients will be offered to save the exported file. +Both scripts will prompt all users currently interacting with the computer's terminal. For upload operations (*import.lua*), the first uploaded file will be used. The prompts on other clients will be canceled. For download operations all clients will be offered to save the exported file. diff --git a/src/main/resources/assets/oc2r/doc/en_us/item/inventory_operations_module.md b/src/main/resources/assets/oc2r/doc/en_us/item/inventory_operations_module.md index 95a6020c..63854950 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/item/inventory_operations_module.md +++ b/src/main/resources/assets/oc2r/doc/en_us/item/inventory_operations_module.md @@ -4,40 +4,40 @@ The inventory operations module provides to [robots](robot.md) the ability to insert and extract items from inventories in the world. This supports both block and entity inventories. ## API -Device name: `inventory_operations` +Device name: *inventory_operations* This is a high level API device. It can be controlled using Lua in the default Linux distribution. For example: -`local d = require("devices")` -`local m = d:find("inventory_operations")` -`m:drop(1, "front")` +*local d = require("devices")* +*local m = d:find("inventory_operations")* +*m:drop(1, "front")* ### Sides -The side parameter in the following methods represents a direction from the perspective of the robot. Valid values are: `front`, `up` and `down`. +The side parameter in the following methods represents a direction from the perspective of the robot. Valid values are: *front*, *up* and *down*. ### Methods -`move(fromSlot:number,intoSlot:number,count:number)` tries to move the specified number of items from one robot inventory slot to another. -- `fromSlot` is the slot to extract items from. -- `intoSlot` is the slot to insert items into. -- `count` is the number of items to move. +*move(fromSlot:number,intoSlot:number,count:number)* tries to move the specified number of items from one robot inventory slot to another. +- *fromSlot* is the slot to extract items from. +- *intoSlot* is the slot to insert items into. +- *count* is the number of items to move. -`drop(count:number[,side]):number` tries to drop items from the specified slot in the specified direction. It will drop items either into an inventory, or the world if no inventory is present. -- `count` is the number of items to drop. -- `side` is the relative direction to drop the items in. Optional, defaults to `front`. See the "Sides" section. +*drop(count:number[,side]):number* tries to drop items from the specified slot in the specified direction. It will drop items either into an inventory, or the world if no inventory is present. +- *count* is the number of items to drop. +- *side* is the relative direction to drop the items in. Optional, defaults to *front*. See the "Sides" section. - Returns the number of items dropped. -`dropInto(intoSlot:number,count:number[,side]):number` tries to drop items from the specified slot into the specified slot of an inventory in the specified direction. It will only drop items into an inventory. -- `intoSlot` is the slot to insert the items into. -- `count` is the number of items to drop. -- `side` is the relative direction to drop the items in. Optional, defaults to `front`. See the "Sides" section. +*dropInto(intoSlot:number,count:number[,side]):number* tries to drop items from the specified slot into the specified slot of an inventory in the specified direction. It will only drop items into an inventory. +- *intoSlot* is the slot to insert the items into. +- *count* is the number of items to drop. +- *side* is the relative direction to drop the items in. Optional, defaults to *front*. See the "Sides" section. - Returns the number of items dropped. -`take(count:number[,side]):number` tries to take the specified number of items from the specified direction. It will take items from either an inventory, or the world if no inventory is present. -- `count` is the number of items to take. -- `side` is the relative direction to take the items from. Optional, defaults to `front`. See the "Sides" section. +*take(count:number[,side]):number* tries to take the specified number of items from the specified direction. It will take items from either an inventory, or the world if no inventory is present. +- *count* is the number of items to take. +- *side* is the relative direction to take the items from. Optional, defaults to *front*. See the "Sides" section. - Returns the number of items taken. -`takeFrom(fromSlot:number,count:number[,side]):number` tries to take the specified number of items from the specified slot from an inventory in the specified direction. It will only take items from an inventory. -- `fromSlot` is the slot to take the items from. -- `count` is the number of items to take. -- `side` is the relative direction to take the items from. Optional, defaults to `front`. See the "Sides" section. +*takeFrom(fromSlot:number,count:number[,side]):number* tries to take the specified number of items from the specified slot from an inventory in the specified direction. It will only take items from an inventory. +- *fromSlot* is the slot to take the items from. +- *count* is the number of items to take. +- *side* is the relative direction to take the items from. Optional, defaults to *front*. See the "Sides" section. - Returns the number of items taken. diff --git a/src/main/resources/assets/oc2r/doc/en_us/item/network_interface_card.md b/src/main/resources/assets/oc2r/doc/en_us/item/network_interface_card.md index 5f512306..40d26951 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/item/network_interface_card.md +++ b/src/main/resources/assets/oc2r/doc/en_us/item/network_interface_card.md @@ -5,8 +5,8 @@ The network interface card (NIC) allows [computers](../block/computer.md) to sen These cards can be configured to only connect to selected sides (use while holding). This allows using multiple cards to build a custom router, for example. -When using the default Linux distribution, this device will provide a regular ethernet device. Network setup can either be performed manually, or using the convenience script `setup-network.lua`. This script provides the option to either use a fixed-address setup, or a DHCP setup. For a DHCP setup, exactly one computer in the network must act as a DHCP server. +When using the default Linux distribution, this device will provide a regular ethernet device. Network setup can either be performed manually, or using the convenience script *setup-network.lua*. This script provides the option to either use a fixed-address setup, or a DHCP setup. For a DHCP setup, exactly one computer in the network must act as a DHCP server. -After initial setup, use the command `ifconfig` to see the currently used IP address. +After initial setup, use the command *ifconfig* to see the currently used IP address. Computers *have to be shut down* before installing or removing this component. Installing it while the computer is running will have no effect, removing it may lead to system errors. diff --git a/src/main/resources/assets/oc2r/doc/en_us/item/network_tunnel_card.md b/src/main/resources/assets/oc2r/doc/en_us/item/network_tunnel_card.md index 9c6fb1c3..c1116283 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/item/network_tunnel_card.md +++ b/src/main/resources/assets/oc2r/doc/en_us/item/network_tunnel_card.md @@ -5,8 +5,8 @@ The network tunnel card allows [computers](../block/computer.md) to send message To link two tunnel devices, open their configuration interface (use while holding), and insert the other tunnel device to link to. This allows linking any two network tunnel devices. -When using the default Linux distribution, this device will provide a regular ethernet device. Network setup can either be performed manually, or using the convenience script `setup-network.lua`. This script provides the option to either use a fixed-address setup, or a DHCP setup. For a DHCP setup, exactly one computer in the network must act as a DHCP server. +When using the default Linux distribution, this device will provide a regular ethernet device. Network setup can either be performed manually, or using the convenience script *setup-network.lua*. This script provides the option to either use a fixed-address setup, or a DHCP setup. For a DHCP setup, exactly one computer in the network must act as a DHCP server. -After initial setup, use the command `ifconfig` to see the currently used IP address. +After initial setup, use the command *ifconfig* to see the currently used IP address. Computers *have to be shut down* before installing or removing this component. Installing it while the computer is running will have no effect, removing it may lead to system errors. diff --git a/src/main/resources/assets/oc2r/doc/en_us/item/network_tunnel_module.md b/src/main/resources/assets/oc2r/doc/en_us/item/network_tunnel_module.md index d1152a94..08bad389 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/item/network_tunnel_module.md +++ b/src/main/resources/assets/oc2r/doc/en_us/item/network_tunnel_module.md @@ -5,8 +5,8 @@ The network tunnel module allows [robots](robot.md) to send messages to and rece To link two tunnel devices, open their configuration interface (use while holding), and insert the other tunnel device to link to. This allows linking any two network tunnel devices. -When using the default Linux distribution, this device will provide a regular ethernet device. Network setup can either be performed manually, or using the convenience script `setup-network.lua`. This script provides the option to either use a fixed-address setup, or a DHCP setup. For a DHCP setup, exactly one computer in the network must act as a DHCP server. +When using the default Linux distribution, this device will provide a regular ethernet device. Network setup can either be performed manually, or using the convenience script *setup-network.lua*. This script provides the option to either use a fixed-address setup, or a DHCP setup. For a DHCP setup, exactly one computer in the network must act as a DHCP server. -After initial setup, use the command `ifconfig` to see the currently used IP address. +After initial setup, use the command *ifconfig* to see the currently used IP address. Robots *have to be shut down* before installing or removing this component. Installing it while the robot is running will have no effect, removing it may lead to system errors. diff --git a/src/main/resources/assets/oc2r/doc/en_us/item/robot.md b/src/main/resources/assets/oc2r/doc/en_us/item/robot.md index a29536ca..07e69ab9 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/item/robot.md +++ b/src/main/resources/assets/oc2r/doc/en_us/item/robot.md @@ -9,92 +9,92 @@ In their default configuration, robots cannot interact with their own inventory. To recharge a robot, it is recommended to make use the [charger](../block/charger.md). It is possible for robots to recharge themselves by simply moving on top of a charger. Alternatively, they may be placed into an inventory on top of the charger. -The default Linux distribution provides a utility Lua library, `robot`, that eases controlling robots. The underlying API offers asynchronous methods for movement. The library implements synchronous alternatives, making sequential programming more convenient. +The default Linux distribution provides a utility Lua library, *robot*, that eases controlling robots. The underlying API offers asynchronous methods for movement. The library implements synchronous alternatives, making sequential programming more convenient. ## API -Device name: `robot` +Device name: *robot* This is a high level API device. It can be controlled using Lua in the default Linux distribution. For example: -`local d = require("devices")` -`local r = d:find("robot")` -`r:move("forward")` +*local d = require("devices")* +*local r = d:find("robot")* +*r:move("forward")* ### Directions -The direction parameter in the following methods represents a direction relative to the robot. Valid values are: `forward`, `backward`, `upward`, `downward` for movement actions, `left` and `right` for rotation actions. These directions are always from the point of view of the robot at the time it executes an action. +The direction parameter in the following methods represents a direction relative to the robot. Valid values are: *forward*, *backward*, *upward*, *downward* for movement actions, *left* and *right* for rotation actions. These directions are always from the point of view of the robot at the time it executes an action. -Short form aliases of these values can be used for convenience: `back`, `up`, `down`. For extreme brevity, the initial letter of each direction can be used as well. +Short form aliases of these values can be used for convenience: *back*, *up*, *down*. For extreme brevity, the initial letter of each direction can be used as well. ### Methods These methods are available on the underlying robot device. Note that the library offers useful wrapper for all of these. It is recommended to use the library instead of interacting with the device directly. -`getEnergyStored():number` returns the current amount of energy stored in the robot's internal energy storage. +*getEnergyStored():number* returns the current amount of energy stored in the robot's internal energy storage. - Returns the stored amount of energy. -`getEnergyCapacity():number` returns the maximum amount of energy that can be stored in the robot's internal energy storage. +*getEnergyCapacity():number* returns the maximum amount of energy that can be stored in the robot's internal energy storage. - Returns the maximum amount of energy stored. -`getSelectedSlot():number` returns the currently selected robot inventory slot. This is used by many modules as an implicit input. +*getSelectedSlot():number* returns the currently selected robot inventory slot. This is used by many modules as an implicit input. - Returns the index of the selected inventory slot. -`setSelectedSlot(slot:number):number` sets the currently selected robot inventory slot. This is used by many modules as an implicit input. -- `slot` is the index of the inventory slot to select. -- Returns the index of the newly selected slot. This may differ from `slot` if the specified value was invalid. +*setSelectedSlot(slot:number):number* sets the currently selected robot inventory slot. This is used by many modules as an implicit input. +- *slot* is the index of the inventory slot to select. +- Returns the index of the newly selected slot. This may differ from *slot* if the specified value was invalid. -`getStackInSlot(slot:number):table` gets a description of the item in the specified slot. -- `slot` is the index of the slot to get the item description for. +*getStackInSlot(slot:number):table* gets a description of the item in the specified slot. +- *slot* is the index of the slot to get the item description for. -`move(direction):boolean` tries to enqueue a movement action in the specified direction. -- `direction` is the direction to move in. +*move(direction):boolean* tries to enqueue a movement action in the specified direction. +- *direction* is the direction to move in. - Returns whether the action was enqueued successfully. -`turn(direction):boolean` tries to enqueue a turn action towards the specified direction. -- `direction` is the direction to turn towards. +*turn(direction):boolean* tries to enqueue a turn action towards the specified direction. +- *direction* is the direction to turn towards. - Returns whether the action was enqueued successfully. -`getLastActionId():number` returns the opaque id of the last enqueued action. Call this after a successful `move()` or `turn()` call to obtain the id associated with the enqueued action. +*getLastActionId():number* returns the opaque id of the last enqueued action. Call this after a successful *move()* or *turn()* call to obtain the id associated with the enqueued action. - Returns the id of the last enqueued action. -`getQueuedActionCount():number` returns the number of actions currently waiting in the action queue to be processed. Use this to wait for actions to finish when enqueueing fails. +*getQueuedActionCount():number* returns the number of actions currently waiting in the action queue to be processed. Use this to wait for actions to finish when enqueueing fails. - Returns the number of currently pending actions. -`getActionResult(actionId:number):string` returns the result of the action with the specified id. Action ids can be obtained from `getLastActionId()`. Only a limited number of past action results are available. -- Returns the result for the specified action id, or nothing if unavailable. When available, possible values are: `INCOMPLETE`, `SUCCESS` and `FAILURE`. +*getActionResult(actionId:number):string* returns the result of the action with the specified id. Action ids can be obtained from *getLastActionId()*. Only a limited number of past action results are available. +- Returns the result for the specified action id, or nothing if unavailable. When available, possible values are: *INCOMPLETE*, *SUCCESS* and *FAILURE*. ### Library API -- Library name: `robot` +- Library name: *robot* This is a Lua library. It can be used in the default Linux distribution. For example: -`local r = require("robot")` -`r.move("forward")` -`r.turn("left")` +*local r = require("robot")* +*r.move("forward")* +*r.turn("left")* ### Methods -`energy():number` returns the current amount of energy stored in the robot's internal energy storage. +*energy():number* returns the current amount of energy stored in the robot's internal energy storage. - Returns the stored amount of energy. -`capacity():number` returns the maximum amount of energy that can be stored in the robot's internal energy storage. +*capacity():number* returns the maximum amount of energy that can be stored in the robot's internal energy storage. - Returns the maximum amount of energy stored. -`slot():number` returns the currently selected robot inventory slot. This is used by many modules as an implicit input. +*slot():number* returns the currently selected robot inventory slot. This is used by many modules as an implicit input. - Returns the index of the selected inventory slot. -`slot(slot:number):number` sets the currently selected robot inventory slot. This is used by many modules as an implicit input. -- `slot` is the index of the inventory slot to select. -- Returns the index of the newly selected slot. This may differ from `slot` if the specified value was invalid. +*slot(slot:number):number* sets the currently selected robot inventory slot. This is used by many modules as an implicit input. +- *slot* is the index of the inventory slot to select. +- Returns the index of the newly selected slot. This may differ from *slot* if the specified value was invalid. -`stack([slot:number]):table` gets a description of the item in the specified slot. -- `slot` is the index of the slot to get the item description for. Optional, defaults to `slot()`. +*stack([slot:number]):table* gets a description of the item in the specified slot. +- *slot* is the index of the slot to get the item description for. Optional, defaults to *slot()*. -`move(direction):boolean` tries to move into the specified direction. Blocks until the movement operation has completed. -- `direction` is the direction to move in. +*move(direction):boolean* tries to move into the specified direction. Blocks until the movement operation has completed. +- *direction* is the direction to move in. - Returns whether the operation was successful. -`moveAsync(direction)` tries to asynchronously move into the specified direction. Blocks until the action was successfully enqueued. -- `direction` is the direction to move in. +*moveAsync(direction)* tries to asynchronously move into the specified direction. Blocks until the action was successfully enqueued. +- *direction* is the direction to move in. -`turn(direction):boolean` tries to turn towards the specified direction. Blocks until the rotation operation has completed. -- `direction` is the direction to turn towards. +*turn(direction):boolean* tries to turn towards the specified direction. Blocks until the rotation operation has completed. +- *direction* is the direction to turn towards. - Returns whether the operation was successfully. -`turnAsync(direction)` tries to asynchronously turn into the specified direction. Blocks until the action was successfully enqueued. -- `direction` is the direction to turn towards. +*turnAsync(direction)* tries to asynchronously turn into the specified direction. Blocks until the action was successfully enqueued. +- *direction* is the direction to turn towards. diff --git a/src/main/resources/assets/oc2r/doc/en_us/item/sound_card.md b/src/main/resources/assets/oc2r/doc/en_us/item/sound_card.md index 80e511eb..08066f58 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/item/sound_card.md +++ b/src/main/resources/assets/oc2r/doc/en_us/item/sound_card.md @@ -4,20 +4,20 @@ The sound card enables playing back various sound effects from its vast library of life-like samples. Due to internal engineering constraints, playback of sequential effects requires a small pause. Attempts to play back additional effects in this time window will have no effect. This is a high level device. It must be controlled using the high level device API. The default Linux distribution offers Lua libraries for this API. For example: -`local d = require("devices")` -`local s = d:find("sound")` -`s:playSound("entity.creeper.primed")` +*local d = require("devices")* +*local s = d:find("sound")* +*s:playSound("entity.creeper.primed")* ## API -Device name: `sound` +Device name: *sound* ### Methods -`playSound(name:string[,volume:float,pitch:float])` plays back the sound effect with the specified name. -- `name` is the name of the effect to play. -- `volume` is the volume at which to play the effect in the range from `0` to `1`, with `1` being the normal volume. Optional, defaulting to `1`. -- `pitch` is the pitch at which to play the effect in the range from `0.5` to `2`, with `1` being the normal pitch. Optional, defaulting to `1`. +*playSound(name:string[,volume:float,pitch:float])* plays back the sound effect with the specified name. +- *name* is the name of the effect to play. +- *volume* is the volume at which to play the effect in the range from *0* to *1*, with *1* being the normal volume. Optional, defaulting to *1*. +- *pitch* is the pitch at which to play the effect in the range from *0.5* to *2*, with *1* being the normal pitch. Optional, defaulting to *1*. - Throws if the specified name is invalid. -`findSound(name:string):table` returns a list of available sound effects matching the given name. Note that the number of results is limited, so overly generic queries will result in truncated results. -- `name` the name query to search for. +*findSound(name:string):table* returns a list of available sound effects matching the given name. Note that the number of results is limited, so overly generic queries will result in truncated results. +- *name* the name query to search for. - Returns a list of sound effect names matching the query string. diff --git a/src/main/resources/assets/oc2r/doc/en_us/networking.md b/src/main/resources/assets/oc2r/doc/en_us/networking.md index fedd1832..cf1ea8bf 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/networking.md +++ b/src/main/resources/assets/oc2r/doc/en_us/networking.md @@ -1,4 +1,5 @@ # Networking + To set up a [computer](block/computer.md) network, use [network connectors](block/network_connector.md) and [network cables](item/network_cable.md) to connect the connectors. Finally, make sure a [network interface card](item/network_interface_card.md) is installed in each computer that should be part of the network. Connectors have to be attached to any face but the front face of a computer. This allows the network card installed in it to send and receive packets through the connector. @@ -6,13 +7,17 @@ Connectors have to be attached to any face but the front face of a computer. Thi Connectors connected with cables will forward packets to each other. For more complex network setups, a [network hub](block/network_hub.md) may be necessary. It allows connecting multiple connectors with each other. ## Hops + Network packets can only travel a certain maximum number of "hops". A hop can generally be understood as a single forwarding operation. For example, a connector forwarding a packet uses one hop. A network hub forwarding a packet to each connector the packet did not arrive from uses one hop. Once the number of remaining hops reaches zero, the packet is no longer forwarded. This avoids packets going in circles forever for networks with cycles. That said, this is a safeguard mechanism. No network should contain cycles, as this will also lead to the same packet arriving multiple times on receiving computers. ## Computer Setup -To set up a computer for networking, first ensure a network card is present. After this, using the default Linux distribution, run the command `setup-network.lua`. This will provide a wizard to configure how the computer should connect to the network. Alternatively, if you know what you're doing, set up network as you would on any regular Linux installation. + +To set up a computer for networking, first ensure a network card is present. After this, using the default Linux distribution, run the command *setup-network.lua*. This will provide a wizard to configure how the computer should connect to the network. Alternatively, if you know what you're doing, set up network as you would on any regular Linux installation. ## DHCP + DHCP is a protocol which allows a simplified network setup. Only one computer will need to have a statically configured network address, all other computers in the network may have their addresses assigned to them automatically. When going for this setup, ensure there is only a single computer that acts as a DHCP server. Also ensure that no computer uses a static IP address that falls into the range of dynamically distributed IP addresses. ## Tools -Once you have a network setup running, with multiple computers in one network, you have all the options in the world. For example, you can copy files between computers using `scp`, log in to a remote computer using `ssh` and write custom network programs in Lua using the `socket` library. For samples on how to use the `socket` library, please the [samples in the official repository](https://github.com/diegonehab/luasocket/tree/master/samples). \ No newline at end of file + +Once you have a network setup running, with multiple computers in one network, you have all the options in the world. For example, you can copy files between computers using *scp*, log in to a remote computer using *ssh* and write custom network programs in Lua using the *socket* library. For samples on how to use the *socket* library, please the [samples in the official repository](https://github.com/diegonehab/luasocket/tree/master/samples). diff --git a/src/main/resources/assets/oc2r/doc/en_us/scripting.md b/src/main/resources/assets/oc2r/doc/en_us/scripting.md index 45523054..9d7b2ae6 100644 --- a/src/main/resources/assets/oc2r/doc/en_us/scripting.md +++ b/src/main/resources/assets/oc2r/doc/en_us/scripting.md @@ -1,72 +1,80 @@ # Scripting + Controlling devices using Lua is a core concept when using [computers](block/computer.md). Many devices are so-called high level API (HLAPI) devices. This means they are not controlled using regular Linux drives, but via a simple RPC system, employing JSON messages over a serial device. ## The Devices Library -The default Linux distribution includes libraries to make HLAPI devices more easily accessible. The `devices` library provides utilities for discovering devices and calling methods on them, as well as obtaining documentation on devices, when available. -To use the `devices` library, import it using `require("devices")`. +The default Linux distribution includes libraries to make HLAPI devices more easily accessible. The *devices* library provides utilities for discovering devices and calling methods on them, as well as obtaining documentation on devices, when available. + +To use the *devices* library, import it using *require("devices")*. ### Methods -`list():table` returns a list of all currently available devices. Each entry in the returned table represents a single device, including its type names and unique identifier. + +*list():table* returns a list of all currently available devices. Each entry in the returned table represents a single device, including its type names and unique identifier. + - Returns the list of connected HLAPI devices. -`get(id:string):Device` returns a wrapper for a device with the specified identifier. This is similar to `find` but takes a specific identifier instead of a type name. -- `id` is the unique identifier of the device. +*get(id:string):Device* returns a wrapper for a device with the specified identifier. This is similar to *find* but takes a specific identifier instead of a type name. + +- *id* is the unique identifier of the device. - Returns a wrapper for the specified device. -`find(typeName):Device` returns a wrapper for a device of the specified type. If there are many devices of this type, it is undefined which one will be returned. Aliases set in [Bus Interfaces](block/bus_interface.md) may also be used. -- `typeName` is the device type for which to find a device. +*find(typeName):Device* returns a wrapper for a device of the specified type. If there are many devices of this type, it is undefined which one will be returned. Aliases set in [Bus Interfaces](block/bus_interface.md) may also be used. + +- *typeName* is the device type for which to find a device. - Returns a wrapper for a device of the specified device. -`methods(id:string):table` returns the list of methods offered by the device with the specified identifier. To obtain the list of methods in a more readable way, get the device wrapper and convert it to a string, instead. Also see the section on the device wrapper type. -- `id` is the unique identifier of the device. +*methods(id:string):table* returns the list of methods offered by the device with the specified identifier. To obtain the list of methods in a more readable way, get the device wrapper and convert it to a string, instead. Also see the section on the device wrapper type. + +- *id* is the unique identifier of the device. - Returns the list of methods offered by the device. - Throws an error if obtaining the method list failed. -`invoke(id:string, methodName:string, ...):any` calls the method with the specified name on the device with the specified identifier. Passes along any extra parameters. Using this method directly is not recommended. Prefer obtaining a device wrapper and invoking the method through it. Also see the section on the device wrapper type. -- `id` is the unique identifier of the device. -- `methodName` is the name of the method to invoke. -- `...` are parameters to pass to the method. +*invoke(id:string, methodName:string, ...):any* calls the method with the specified name on the device with the specified identifier. Passes along any extra parameters. Using this method directly is not recommended. Prefer obtaining a device wrapper and invoking the method through it. Also see the section on the device wrapper type. + +- *id* is the unique identifier of the device. +- *methodName* is the name of the method to invoke. +- *...* are parameters to pass to the method. - Returns the result of the method. - Throws an error if invocation failed, or the method threw an exception. ## The Device Wrapper -Devices returned from the `device` library are objects of type `Device`. This is a wrapper storing the device identifier. + +Devices returned from the *device* library are objects of type *Device*. This is a wrapper storing the device identifier. Its main purpose is to enable seamless invocation of methods exposed by this device, as well as a convenient way to access documentation, if available. -To invoke a method on such a wrapper, use colon notation, and the method's name. For example: -`wrapper:someMethod(1, 2, 3)` +To invoke a method on such a wrapper, use colon notation, and the method's name. For example: +*wrapper:someMethod(1, 2, 3)* -To obtain the documentation of the device, `tostring` it. In the Lua interpreter, use `=wrapper`. +To obtain the documentation of the device, *tostring* it. In the Lua interpreter, use *=wrapper*. ## Example + For this example we will control a [redstone interface block](block/redstone_interface.md). First, place the block and connect it to the computer using [bus cables](block/bus_cable.md) and [bus interfaces](block/bus_interface.md). ![Redstone interface setup](../img/scripting_redstone_interface.png) We place a redstone lamp on top of the redstone interface to have a visual indicator that our commands work. -To verify the connection between device and computer, run the command `lsdev.lua` from the command line. This lists the identifiers and type names of all connected HLAPI devices. One of these should have the type `redstone` among its type names. +To verify the connection between device and computer, run the command *lsdev.lua* from the command line. This lists the identifiers and type names of all connected HLAPI devices. One of these should have the type *redstone* among its type names. -Start Lua in interactive mode by running just `lua` from the command line. +Start Lua in interactive mode by running just *lua* from the command line. ![Lua in interactive mode](../img/scripting_lua_interactive.png) -Include the devices library and store it in a variable named `d`: -`d = require("devices")` +Include the devices library and store it in a variable named *d*: *d = require("devices")* -Then get the `Device` wrapper for the redstone interface block and store it in a variable named `r`: -`r = d:find("redstone")` +Then get the *Device* wrapper for the redstone interface block and store it in a variable named *r*: *r = d:find("redstone")* -The `redstone` in this call is the device type name, the same we checked for just earlier using `lsdev.lua`. +The *redstone* in this call is the device type name, the same we checked for just earlier using *lsdev.lua*. -We now have a wrapper for the redstone interface block on which we may call methods. To get a list of the available methods, run `=r`. +We now have a wrapper for the redstone interface block on which we may call methods. To get a list of the available methods, run *=r*. -For our example, we're interested in the `setRedstoneOutput` method. It allows setting the signal emitted from the redstone interface. +For our example, we're interested in the *setRedstoneOutput* method. It allows setting the signal emitted from the redstone interface. -To light up our lamp, we want to emit a redstone signal from the top face of the redstone interface block: -`r:setRedstoneOutput("up", 15)` +To light up our lamp, we want to emit a redstone signal from the top face of the redstone interface block: +*r:setRedstoneOutput("up", 15)* The lamp should now light up!