mirror of
https://github.com/MightyPirates/OpenComputers.git
synced 2025-09-12 16:57:32 -04:00
Merge branch 'master-MC1.7.10' of github.com:MightyPirates/OpenComputers into updated_recipes
Conflicts: src/main/scala/li/cil/oc/common/recipe/Recipes.scala
This commit is contained in:
Johannes Lohrer
commit
72a4a0e476
BIN
assets/items.psd
BIN
assets/items.psd
Binary file not shown.
@ -1,7 +1,7 @@
|
||||
minecraft.version=1.7.10
|
||||
forge.version=10.13.2.1291
|
||||
|
||||
oc.version=1.5.7
|
||||
oc.version=1.5.8
|
||||
oc.subversion=dev
|
||||
|
||||
ae2.version=rv2-beta-26
|
||||
|
||||
@ -16,7 +16,7 @@ import li.cil.oc.api.detail.NetworkAPI;
|
||||
*/
|
||||
public class API {
|
||||
public static final String ID_OWNER = "OpenComputers|Core";
|
||||
public static final String VERSION = "5.1.0";
|
||||
public static final String VERSION = "5.1.1";
|
||||
|
||||
public static DriverAPI driver = null;
|
||||
public static FileSystemAPI fileSystem = null;
|
||||
|
||||
30
src/main/java/li/cil/oc/api/internal/Wrench.java
Normal file
30
src/main/java/li/cil/oc/api/internal/Wrench.java
Normal file
@ -0,0 +1,30 @@
|
||||
package li.cil.oc.api.internal;
|
||||
|
||||
import net.minecraft.entity.player.EntityPlayer;
|
||||
import net.minecraft.world.World;
|
||||
|
||||
/**
|
||||
* Implemented on items that are wrench-like tools.
|
||||
*/
|
||||
public interface Wrench {
|
||||
/**
|
||||
* Called when the wrench is used.
|
||||
* <p/>
|
||||
* This is called in two scenarios, once when testing whether the wrench
|
||||
* can be used on a certain block, in which case the <tt>simulate</tt>
|
||||
* argument will be <tt>true</tt>, and once when actually used on a block,
|
||||
* in which case the <tt>simulate</tt> argument will be <tt>false</tt>,
|
||||
* allowing the tool to damage itself, for example.
|
||||
* <p/>
|
||||
* This is usually called from blocks' activation logic.
|
||||
*
|
||||
* @param player the player using the tool
|
||||
* @param world the world containing the block the wrench is used on.
|
||||
* @param x the X coordinate of the block.
|
||||
* @param y the Y coordinate of the block.
|
||||
* @param z the Z coordinate of the block.
|
||||
* @param simulate whether to simulate the usage.
|
||||
* @return whether the wrench can be used on the block.
|
||||
*/
|
||||
boolean useWrenchOnBlock(EntityPlayer player, World world, int x, int y, int z, boolean simulate);
|
||||
}
|
||||
@ -15,7 +15,7 @@ public interface ImageRenderer {
|
||||
* The width of the area this renderer uses.
|
||||
* <p/>
|
||||
* This is used to offset the OpenGL state properly before calling
|
||||
* {@link #render()}, to correctly align the image horizontally.
|
||||
* {@link #render(int, int)}, to correctly align the image horizontally.
|
||||
*
|
||||
* @return the width of the rendered image.
|
||||
*/
|
||||
@ -25,7 +25,7 @@ public interface ImageRenderer {
|
||||
* The height of the area this renderer uses.
|
||||
* <p/>
|
||||
* This is used to offset the OpenGL state properly before calling
|
||||
* {@link #render()}, as well as to know where to resume rendering
|
||||
* {@link #render(int, int)}, as well as to know where to resume rendering
|
||||
* other content below the image.
|
||||
*
|
||||
* @return the height of the rendered image.
|
||||
|
||||
@ -40,7 +40,7 @@ public class ResourceContentProvider implements ContentProvider {
|
||||
|
||||
@Override
|
||||
public Iterable<String> getContent(String path) {
|
||||
final ResourceLocation location = new ResourceLocation(resourceDomain, basePath + path);
|
||||
final ResourceLocation location = new ResourceLocation(resourceDomain, basePath + (path.startsWith("/") ? path.substring(1) : path));
|
||||
InputStream is = null;
|
||||
try {
|
||||
is = Minecraft.getMinecraft().getResourceManager().getResource(location).getInputStream();
|
||||
|
||||
@ -946,6 +946,16 @@ opencomputers {
|
||||
# cartridge. Tweak this if you think printing is too cheap or expensive.
|
||||
# Note: the amount a single dye adds is this divided by 10.
|
||||
inkValue: 50000
|
||||
|
||||
# Whether to enable print opacity, i.e. make prints have shadows. If
|
||||
# enabled, prints will have an opacity that is estimated from their
|
||||
# sampled fill rate. This is disabled by default, because MC's lighting
|
||||
# computation is apparently not very happy with multiple blocks with
|
||||
# dynamic opacity sitting next to each other, and since all prints share
|
||||
# the same block type, this can lead to weird shadows on prints. If you
|
||||
# don't care about that and prefer them to be not totally shadowless,
|
||||
# enable this.
|
||||
printsHaveOpacity: false
|
||||
}
|
||||
|
||||
# Other settings that you might find useful to tweak.
|
||||
@ -1069,6 +1079,11 @@ opencomputers {
|
||||
# avoid issues with computers timing out, but can also lead to higher
|
||||
# server load. AGAIN, USE WITH CARE!
|
||||
threadPriority: -1
|
||||
|
||||
# Whether to give a new player a free copy of the manual. This will only
|
||||
# happen one time per game, not per world, not per death. Once. If this
|
||||
# is still too much for your taste, disable it here ;-)
|
||||
giveManualToNewPlayers: true
|
||||
}
|
||||
|
||||
# Settings for mod integration (the mod previously known as OpenComponents).
|
||||
|
||||
@ -1,5 +1,10 @@
|
||||
# Handbuch
|
||||
|
||||
Test für Lokalisierung.
|
||||
Leider ist das Handbuch bisher nur [auf Englisch](/en_US/index.md) vorhanden.
|
||||
|
||||
Ergo, [Link zur Beispielseite](general/example.md) die nur auf Englisch existiert.
|
||||
Wenn du des Englischen mächtig bist und dazu beitragen willst, das Handbuch zu übersetzen, super! Wenn du noch dazu sauberes Deutsch schreiben kannst, nicht alle drei Wörter einen Rechtschreibfehler einbaust, und es dich nervt wenn Leute Standart statt Standard schreiben, lies weiter. Sonst... schau mer mal ;-) Etwas Grundkenntnis von Git ist nötig, um deine Übersetzung dann als Pull-Request in OpenComputers einzubringen.
|
||||
|
||||
Um beim Übersetzen zu helfen bedarf es keiner Programmierkenntnisse. Die gesamte Dokumentation ist in Form von Markdown-Dokumenten vorhanden, und findet sich [hier](http://git.io/ve1Fj). Im `en_US` Ordner findet sich die Englische Dokumentation, mit der gleichen Datei- und Ordnerstruktur müsste die Übersetzung ins Deutsche in den `de_DE` Ordner.
|
||||
Dass die Ordner und Dateien gleich heißen ist wichtig, damit die richtige Seite automatisch angezeigt werden kann, wenn man das Handbuch z.B. auf einen Block anwendet. Zudem wird für fehlende Seiten automatisch auf die Englischen zurückgegriffen, sofern vorhanden. Das heißt auch, dass es schon hilft wenn einzelne Seiten übersetzt werden. Diese würden dann in Deutsch angezeigt, während alle anderen Seiten nach wie vor auf Englisch angezeigt würden.
|
||||
|
||||
Wenn sich freiwillige finden würden, wäre das super. Andernfalls müsst ihr euch bis auf Weiteres mit der [Englischen Variante](/en_US/index.md) begnügen.
|
||||
|
||||
@ -2,10 +2,10 @@
|
||||
|
||||
|
||||
|
||||
The Access Point is the wireless version of the [switch](switch.md). It can be used to separate subnetworks so that machines in them will not see components in other networks, while still allowing to send network messages to the machines in other networks.
|
||||
The access point is the wireless version of the [switch](switch.md). It can be used to separate subnetworks so that machines in them will not see [components](../general/computer.md) in other networks, while still allowing to send network messages to the machines in other networks.
|
||||
|
||||
In addition to that, this block will resend any wired messages it receives as wireless ones, wireless messages it receives as wired messages, and repeat wireless messages as wireless ones.
|
||||
In addition to that, this block can act as a repeater: it can re-send wired messages as wired messages to other devices; or wireless messages as wired or wireless messages.
|
||||
|
||||
Switches and access point do *not* keep track of which packets they relayed recently, so avoid cycles in your network, or you may receive the same packet multiple times.
|
||||
[Switches](switch.md) and access point do *not* keep track of which packets they relayed recently, so avoid cycles in your network or you may receive the same packet multiple times. Due to the limited buffer size of switches, packet loss can occur when trying to send network messages too frequently. You can upgrade your switches and access points to increase the speed at which they relay messages, as well as their internal message queue size.
|
||||
|
||||
Packets are only re-sent a certain number of times, so chaining an arbitrary number of switches or access points is not possible.
|
||||
Packets are only re-sent a certain number of times, so chaining an arbitrary number of [switches](switch.md) or access points is not possible. By default, a packet will be re-sent up to five times.
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The Adapter allows computers to interact with a number of blocks that are not part of OpenComputers, such as blocks from Minecraft itself (like the Furnace) and from a number of other mods. Supported blocks adjacent to the adapter will show up as components in [computers](../general/computer.md) connected to the adapter.
|
||||
The adapter allows [computers](../general/computer.md) to interact with blocks from vanilla Minecraft or other mods. Supported blocks adjacent to the adapter will show up as components in [computers](../general/computer.md) connected to the adapter.
|
||||
|
||||
In addition to this, the adapter provides a slot for a few select upgrades. For example, the [inventory controller upgrade](../item/inventoryControllerUpgrade.md) allows computers to query more information from an inventory adjacent to the adapter, similar to when the upgrade is installed in a device (such as a [robot](robot.md) or [drone](../item/drone.md)), and a [tank controller upgrade](../item/tankControllerUpgrade.md) provides similar functionality for fluid tanks next to the adapter.
|
||||
|
||||
@ -2,10 +2,12 @@
|
||||
|
||||
|
||||
|
||||
The Assembler is an advanced workstation that can be used to build more complex electronic devices, such as [robots](robot.md), [drones](../item/drone.md) and [tablets](../item/tablet.md). They usually require a relatively large amount of energy to assemble these devices, so it is recommended to power them sufficiently.
|
||||
The assembler is an advanced workstation that can be used to build more complex electronic devices, such as [robots](robot.md), [drones](../item/drone.md) and [tablets](../item/tablet.md). They require a large amount of energy to assemble devices, so it is recommended to power them sufficiently with a [capacitor bank](capacitor.md).
|
||||
|
||||
To build a device using an assembler, first insert the base part for that device. For [robots](robot.md) that is a [computer case](case1.md) of any tier, for tablets that is a [tablet case](../item/tabletCase1.md), for example. Continue to insert any parts you would like the device to contain. Take particular care to provide an operating system, or a possibility to install one later on (for robots you can install a [disk drive](diskDrive.md) to insert and remove [floppies](../item/floppy.md) later on, for example).
|
||||
To build a device using an assembler, insert the base part for that device. For [robots](robot.md), that is a [computer case](case1.md) of any tier; and for [tablets](../item/tablet.md), a [tablet case](../item/tabletCase1.md). As with all OpenComputers inventories, the parts that can be inserted into specific slots; hovering over a slot highlights the parts in your inventory that can go into the slot. If you have NEI open, filtered to show OpenComputers items, compatible items will be highlighted in NEI as well. Continue to insert any parts you would like the device to contain. Take particular care to provide an operating system, or a way to install one later on (for robots you can install a [disk drive](diskDrive.md) to insert and remove [floppies](../item/floppy.md) later on, for example). For most devices, their [EEPROM](../item/eeprom.md) can be changed later on, by crafting the device together with a different [EEPROM](../item/eeprom.md) to insert in them. Existing [EEPROM](../item/eeprom.md) on the device will be returned to your inventory.
|
||||
|
||||
Also note that for [robots](robot.md) to have a [screen](screen1.md) you need to install a tier one screen in them, and to allow typing on the screen you also need to install a [keyboard](keyboard.md). For [tablets](../item/tablet.md) the screen is pre-installed in the tablet case, but you still need to install a keyboard if you wish to type on your [tablet](../item/tablet.md).
|
||||
Also note that for [robots](robot.md) to have a [screen](screen1.md), you will need to install a [screen (tier 1)](screen1.md) in them, and to allow typing on the [screen](screen1.md), you will need to install a [keyboard](keyboard.md). For [tablets](../item/tablet.md), the [screen](screen1.md) is pre-installed in the [tablet case](../item/tabletCase1.md), but you will need to install a [keyboard](keyboard.md) if you wish to type on the [tablet](../item/tablet.md).
|
||||
|
||||
Once everything is in place, press the start button and wait for the device to be assembled and charged. It is important to remember that you *cannot* change the device after it has been assembled. If you forgot something or made a mistake, you will have to disassemble the device completely using the [disassembler](disassembler.md), which has a slight chance of breaking parts in the process.
|
||||
Once everything is in place, press the start button and wait for the device to be assembled and charged. It is important to remember that you *cannot* change the device after it has been assembled. If you forgot something or made a mistake, you will have to disassemble the device using the [disassembler](disassembler.md), which has a slight chance of breaking parts in the process.
|
||||
|
||||
A final note on complexity: the tier of an item determines how much complexity it requires, with tier 1 items requiring 1 complexity, tier 2 requiring 2 and tier 3 requiring 3. Container upgrades are the exception, where the complexity is twice the tier of the container (eg: a tier 2 [upgrade containers](../item/upgradeContainer1.md) requires 4 complexity, and likewise for [card containers](../item/cardContainer1.md)).
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
|
||||
|
||||
|
||||
The Cable simply serves as a way of connecting computers and machines that are far apart. If you have a compact build where all components touch each other (directly or indirectly, most blocks also behave the same way as cables) you will usually not need cables.
|
||||
The cable serves as a way of connecting [computers](../general/computer.md) and machines that are far apart. If you have a compact build where all components touch each other (directly or indirectly, most blocks also behave the same way as cables) you will usually not need cables.
|
||||
|
||||
Cables can be colored using any kind of dye. Colored cables will only connect to cables of the same color and to light gray colored cables - the default color. This can be useful for running cables for multiple subnetworks in parallel, without using covers.
|
||||
|
||||
If necessary, Cables can be covered using Forge MultiPart covers, or Immibis Microblocks covers.
|
||||
If necessary, cables can be covered using Forge MultiPart covers, or Immibis Microblocks covers. Keep in mind that [3D prints](print.md) are Forge MultiPart compatible, so it is possible to print custom covers, if desired.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
|
||||
|
||||
The capacitor stores energy to be used by the network, acting as an energy buffer when needed. Unlike conversion from other mod's energy to OpenComputers' internal energy type (using a [power converter](powerConverter.md), transferring energy inside a single subnetwork is instantaneous, so it can be advantageous to store some energy internally for tasks that consume a lot of energy, such as assembling devices in the [assembler](assembler.md) or charging [robots](robot.md).
|
||||
The capacitor stores energy to be used by the network, acting as an energy buffer when needed. Unlike conversion from other mod's energy to OpenComputers' internal energy type (using a [power converter](powerConverter.md) for example), transferring energy inside a single subnetwork is instantaneous. Having an internal energy bugger will be useful for tasks that require a lot of energy, such as [assembling](assembler.md) and/or [charging](charger.md) devices such as [robots](robot.md) or [drones](../item/drone.md).
|
||||
|
||||
The storage efficiency of capacitors increases with the number of capacitors in direct contact or in the vicinity. For example, two capacitors directly next to each other will have a higher storage capacity than the sum of two separated capacitors. This adjacency bonus applies for capacitors up to two blocks away, and is reduced as the distance between capacitors increases.
|
||||
|
||||
|
||||
@ -4,6 +4,8 @@
|
||||
|
||||
Computer cases come in three different tiers, which limits the components that can be inserted into them. An additional tier also exists for use in creative mode only. Computer cases can also be placed inside an [assembler](assembler.md) to build [robots](robot.md).
|
||||
|
||||
The maximum tier of the component that can be inserted into any slot of a computer case can be seen as a small roman numeral in the corner of a tier-limited slot. A tier 2 slot can take a tier 1 component, for instance.
|
||||
|
||||
The tier 1 case can house up to and including the following components:
|
||||
- 2x tier 1 expansion cards (such as [graphics cards](../item/graphicsCard1.md), [network cards](../item/lanCard.md), etc)
|
||||
- 1x tier 1 [CPU](../item/cpu1.md)
|
||||
@ -32,4 +34,4 @@ The tier 4 (Creative) case can house the following components:
|
||||
- 1x tier 3 [CPU](../item/cpu3.md)
|
||||
- 2x tier 3 [RAM](../item/ram5.md)
|
||||
- 2x tier 3 [HDD](../item/hdd3.md)
|
||||
- 1x [floppy disk](../item/floppy.md)
|
||||
- 1x [floppy disk](../item/floppy.md)
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Chamelium Block
|
||||
# Block of Chamelium
|
||||
|
||||
|
||||
|
||||
A bunch of [Chamelium](../item/chamelium.md) slapped together, this can be nice to decorate parts of your base, if you want a clean, monochrome block. Can be dyed to take any one of the 16 common Minecraft colors.
|
||||
A few pieces of [chamelium](../item/chamelium.md) can be combined to provide a monochrome block for decorative purposes. Chamelium blocks can also be dyed with any of the 16 Minecraft colors.
|
||||
|
||||
Another use is to pick its texture and use that in your [3D prints](print.md), if you want something clean white to apply a tint to.
|
||||
Using the Chamelium block as a texture for [3D prints](print.md) provides a clean white surface for applying tints.
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
|
||||
|
||||
|
||||
The Charger is used to charge devices such as [robots](robot.md), [drones](../item/drone.md) and [tablets](../item/tablet.md). A charger has to be activated by applying a redstone signal to it. The relative charge speed is based on the applied redstone signal's strength, with a strength of 15 meaning a charge speed of 100%.
|
||||
The charger is used to charge devices such as [robots](robot.md), [drones](../item/drone.md) and [tablets](../item/tablet.md). A charger has to be activated by applying a redstone signal to it. The charge speed is based on the applied redstone signal's strength, with a strength of 15 meaning a charge speed of 100%.
|
||||
|
||||
Note that this logic can be inversed by hitting the charger with a BuildCraft compatible wrench. In inversed mode the charger defaults to 100% charge speed, and a higher redstone signal will result in a slower charge speed.
|
||||
Note that this logic can be inversed by hitting the charger with a [wrench](../item/wrench.md). In inversed mode, the charger defaults to 100% charge speed, decreasing in charge speed as the strength of the redstone signal increases.
|
||||
|
||||
When a [tablet](../item/tablet.md) is placed in the charger, its first [hard drive](../item/hdd1.md) is also exposed to [computers](../general/computer.md) connected to the charger, similar to how [floppies](../item/floppy.md) in [disk drives](diskDrive.md) are. This allows transferring of data between the [computer](../general/computer.md) and [tablet](../item/tablet.md).
|
||||
When a [tablet](../item/tablet.md) is placed in the charger, the first [hard drive](../item/hdd1.md) is also exposed to [computers](../general/computer.md) connected to the charger, similar to how [floppies](../item/floppy.md) in [disk drives](diskDrive.md) are. This allows transferring of data between the [computer](../general/computer.md) and [tablet](../item/tablet.md).
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The Disassembler can be used to deconstruct most items in OpenComputers into their original parts. This is mostly useful to reclaim materials from old parts that are no longer useful, or to deconstruct devices that are either no longer needed or were incorrectly built (e.g. [robots](robot.md) without an operating system).
|
||||
The disassembler can be used to deconstruct most items in OpenComputers into their original parts. This is mostly useful to reclaim materials from old parts that are no longer useful, or to deconstruct devices that are either no longer needed or were incorrectly built (e.g. [robots](robot.md) without an [operating system](../general/openOS.md)).
|
||||
|
||||
Disassembling items takes a relatively long time, and some energy. There is also a slight chance of loosing a component, which is applied on a component by component basis - be careful about throwing a device into the disassembler.
|
||||
Disassembling items takes a long time, and some energy. There is also a slight chance of losing a component (which is applied on a component by component basis).
|
||||
@ -2,6 +2,8 @@
|
||||
|
||||
|
||||
|
||||
The Disk Drive can be used to read [floppy disks](../item/floppy.md) using a computer connected to the disk drive. This is useful to get started, since the lower tier [computer cases](case1.md) do not have a built-in floppy slot, and you'll need an operating system to get started. An OpenOS disk can be crafted using an empty [floppy disk](../item/floppy.md) and a Book.
|
||||
The disk drive can be used to read [floppy disks](../item/floppy.md) using a [computer](../general/computer.md) connected to the disk drive. This is useful to get started, since the lower tier [computer cases](case1.md) do not have a built-in floppy slot, and you'll need an operating system to boot up the [computer](../general/computer.md). An [OpenOS](../general/openOS.lua) disk can be crafted using an empty [floppy disk](../item/floppy.md) and a [manual](../item/manual.lua).
|
||||
|
||||
It can also be installed in [robots](robot.md) to allow inserting an removing [floppy disks](../item/floppy.md) into and from the robot at any time. This can be very useful since the only other way to transfer data to and from a robot is using networking - for example using [network cards](../item/lanCard.md).
|
||||
It can also be installed in [robots](robot.md) to allow inserting [floppy disks](../item/floppy.md) into the [robot](robot.md). This can be very useful since the only other way to transfer data to and from a robot is using networking - for example using [network cards](../item/lanCard.md).
|
||||
|
||||
[Disks](../item/floppy.md) can be inserted and removed without opening the disk drive's GUI by sneak-activating the disk drive (shift-right click) with the [floppy disk](../item/floppy.md) in hand.
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The Geolyzer can be used by computers to scan the terrain surrounding the geolyzer for the blocks' approximate hardness. This can be useful to generate maps of the area to display on [hologram projectors](hologram1.md) as well as to detect potentially valuable blocks (ores are usually harder than dirt and stone). Geolyzer scan results have a certain amount of noise added; in theory, multiple scans can be performed to determine a more accurate reading of a block's hardness level.
|
||||
The geolyzer can be used by [computers](../general/computer.md) to scan the terrain surrounding the geolyzer for the blocks' approximate hardness. This can be useful to generate maps of the area to display on [hologram projectors](hologram1.md) as well as to detect potentially valuable blocks (ores are usually harder than dirt and stone). Geolyzer scan results have a certain amount of noise added; in theory, multiple scans can be performed to determine a more accurate reading of a block's hardness level.
|
||||
|
||||
The geolyzer can also be installed in [robots](robot.md) as an upgrade to allow them to scan their surroundings. Performing a scan will consume some energy, though, so using it excessively may quickly drain a [robot](robot.md)'s batteries.
|
||||
The geolyzer can also be installed in [robots](robot.md) and [tablets](../item/tablet.md) as an upgrade to allow them to scan their surroundings. Performing a scan will consume some energy, though, so using it excessively will drain the device's batteries.
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The Hologram Projector is a volumetric display, i.e. it provides a three dimensional array of voxels that can be individually enabled or disabled by a connected computer. The second tier projector, while having the same resolution as the tier one projector, supports displaying the individual voxels in three different user-definable colors.
|
||||
The hologram projector is a volumetric display, i.e. it provides a three dimensional array of voxels that can be individually enabled or disabled by a connected [computer](../general/computer.md). The second tier projector, while having the same resolution as the tier 1 projector, supports displaying the individual voxels in three different user-definable colors.
|
||||
|
||||
Holograms can be rotated along their vertical axis by hitting them with a BuildCraft compatible wrench on their top or bottom. This can save some effort, so that the output doesn't have to be transformed on the software side. Holograms can also be scaled up or down as desired.
|
||||
Holograms can be rotated along their vertical axis by hitting them with a [wrench](../item/wrench.md) on their top or bottom. This can save some effort, so that the output doesn't have to be transformed on the software side. Holograms can also be scaled up or down as desired.
|
||||
|
||||
@ -28,7 +28,7 @@ Keep in mind that some of these may not be available, depending on the recipe se
|
||||
* [Motion Sensor](motionSensor.md)
|
||||
* [Redstone I/O](redstone.md)
|
||||
|
||||
### Assembly / Printing
|
||||
## Assembly / Printing
|
||||
* [3D Print](print.md)
|
||||
* [3D Printer](printer.md)
|
||||
* [Assembler](assembler.md)
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
A Keyboard is needed to type text on [screens](screen1.md), be they in the world or built into devices such as [robots](robot.md) or [tablets](../item/tablet.md).
|
||||
A keyboard is needed to type text on [screens](screen1.md), be they in the world or built into devices such as [robots](robot.md) or [tablets](../item/tablet.md).
|
||||
|
||||
For a keyboard to work with a [screen](screen1.md) in the world, it has to be placed next to the [screen](screen1.md), facing that [screen](screen1.md), or placed directly on the [screen](screen1.md) (on top or on one of its sides). You can tell that a keyboard is "connected" to a [screen](screen1.md) if by using the keyboard the [screen's](screen1.md) GUI opens up.
|
||||
For a keyboard to work with a [screen](screen1.md) in the world, it has to be placed next to the [screen](screen1.md), facing that [screen](screen1.md), or placed directly on the [screen](screen1.md) (on top or on one of its sides). You can tell that a keyboard is "connected" to a [screen](screen1.md) if the [screen's](screen.md) GUI opens up when using the keyboard.
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
Microcontrollers are built using a [microcontroller case](../item/microcontrollerCase1.md) in the [assembler](assembler.md). They have less functionality compared to computers.
|
||||
Microcontrollers are built using a [microcontroller case](../item/microcontrollerCase1.md) in the [assembler](assembler.md). They have less functionality compared to [computers](../general/computer.md), but are cheaper to build.
|
||||
|
||||
Microcontrollers can take various components, such as [CPUs](../item/cpu1.md), [memory (RAM)](../item/ram1.md), and Expansion cards. Microcontrollers are unable to contain a [hard disk drive](../item/hdd1.md), but do contain a slot for an [EEPROM](../item/eeprom.md), which can be programmed for very specific tasks.
|
||||
Microcontrollers can take various components, such as [CPUs](../item/cpu1.md), [memory (RAM)](../item/ram1.md), and Expansion cards. Microcontrollers are unable to contain a [hard disk drive](../item/hdd1.md), but do contain a slot for an [EEPROM](../item/eeprom.md), which can be programmed for very specific tasks.
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The Motion Sensor allows [computers](../general/computer.md) to detect movement of living entities. If an entity moves faster than a set threshold, a signal will be injected into [computers](../general/computer.md) connected to the motion sensor. The threshold can be configured via the component the motion sensor exposes to connected computers.
|
||||
The motion sensor allows [computers](../general/computer.md) to detect movement of living entities. If an entity moves faster than a set threshold, a signal will be injected into [computers](../general/computer.md) connected to the motion sensor. The threshold can be configured using the component API that the motion sensor exposes to connected computers.
|
||||
|
||||
Movement is only detected if it happens within a radius of eight blocks around the motion sensor, and if there is a direct line of sight from the block to the entity that moved.
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
The Power Converter serves as the fastest way to convert energy from other mods' power systems to OpenComputers' internal energy. If you only run a simple computer, you probably won't need a converter. If you have a large capacitor bank that you only drain every now and then, you probably won't need one, either. However, if you wish to directly power an [assembler](assembler.md) or [charger](charger.md), it is usually a good idea to use a converter, instead of directly connecting them to external power.
|
||||
The power converter serves as the fastest way to convert energy from other mods' power systems to OpenComputers' internal energy. If you only run a simple computer, you probably won't need a converter. If you have a large capacitor bank that you only drain every now and then, you probably won't need one, either. However, if you wish to directly power an [assembler](assembler.md) or [charger](charger.md), it is usually a good idea to use a converter instead of directly connecting them to external power.
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
The Power Distributor distributes a shared power storage (such as a [capacitor](capacitor.md)), allowing several subnetworks to share their energy, without components being exposed to computers in other networks. It operates by regularly "balancing" the energy in all subnetworks it is connected to, so that the *relative* amount of energy is the same in them.
|
||||
The power distributor distributes a shared power storage (such as a [capacitor](capacitor.md)), allowing several subnetworks to share their energy without components being exposed to computers in other networks. It operates by regularly "balancing" the energy in all subnetworks it is connected to, so that the *relative* amount of energy is the same in them.
|
||||
|
||||
@ -2,6 +2,10 @@
|
||||
|
||||
|
||||
|
||||
3D prints are created using a [3D printer](printer.md). They are primarily intended for decorative purposes, but can also be created in such a way that they react to or emit redstone signals, allowing for a little bit of functional behavior on the side.
|
||||
3D prints are created using a [3D printer](printer.md). They are primarily intended for decorative purposes, but can also be created in such a way that they react to or emit redstone signals, allowing for a little bit extra functionality.
|
||||
|
||||
3D prints can be recycled by putting them as input into a 3D printer. This will re-use some of the [chamelium](../item/chamelium.md) that was used to print them. Color that was used to print the model will not be recycled.
|
||||
3D prints can be recycled by putting them as input into a [3D printer](printer.md). This will re-use some of the [chamelium](../item/chamelium.md) that was used to print them. Color that was used to print the model will not be recycled.
|
||||
|
||||
Holding the key for OpenComputers' extended tooltips (default is [Shift]), a print's active state will be shown, if any.
|
||||
|
||||
Printed blocks are also Forge MultiPart compatible. If present, multiple prints can be placed into a single block-space, unless they do not collide, and the total number of shapes in the block-space does not exceed the limit for a single model. Due to the nature of Forge MultiPart, prints can therefore also be placed into the same block-space as any other Forge MultiPart compatible block, such as torches, levers, cables or red alloy wires from Project Red, for example.
|
||||
|
||||
@ -4,12 +4,12 @@
|
||||
|
||||
3D printers allow you to print any block of any shape, with any type of texture. To get started with 3D printers, you will need to place down a 3D printer block next to a computer. This will give access to the `printer3d` component API, allowing you to set up and print [models](print.md) using the provided functions.
|
||||
|
||||
A more convenient way to setup 3D printers is to use Open Programs Package Manager (OPPM). Once installed, make sure you have an [internet card](../item/internetCard.md) in your computer and run the following command:
|
||||
A more convenient way to setup 3D printers is to use Open Programs Package Manager (OPPM). Once installed (`oppm install oppm`), make sure you have an [internet card](../item/internetCard.md) in your [computer](../general/computer.md) and run the following command:
|
||||
`oppm install print3d-examples`
|
||||
|
||||
The examples can then be found in `/usr/share/models/` as .3dm files. Take a look through the example files for available options, in particular the `example.3dm` file. Alternatively, you can download the `print3d` and `print3d-examples` programs from OpenPrograms using `wget` and an internet card.
|
||||
The examples can then be found in `/usr/share/models/` as .3dm files. Take a look through the example files for available options, in particular the `example.3dm` file. Alternatively, you can download the `print3d` and `print3d-examples` programs from OpenPrograms using `wget` and an [internet card](../item/internetCard.md).
|
||||
|
||||
In order to be able to print the models, a 3D printer needs to be configured via a computer. If set to print non-stop, the computer will be no longer required thereafter. You will also need to provide an [ink cartridge](../item/inkCartridge.md) and some [chamelium](../item/chamelium.md) as input materials. The amount of chamelium used depends on the volume of the 3D print, while the amount of ink used depends on the surface area of the printed item.
|
||||
In order to be able to print the models, a 3D printer needs to be configured via a [computer](../general/computer.md). If set to print non-stop, the computer will no longer be required thereafter. You will also need to provide an [ink cartridge](../item/inkCartridge.md) and some [chamelium](../item/chamelium.md) as input materials. The amount of chamelium used depends on the volume of the 3D print, while the amount of ink used depends on the surface area of the printed item.
|
||||
|
||||
To print an item, use the following command:
|
||||
`print3d /path/to/file.3dm`
|
||||
|
||||
@ -2,8 +2,10 @@
|
||||
|
||||
|
||||
|
||||
The Raid block houses three [hard drives](../item/hdd1.md) which will be combined into a single file system. This combined file system has the size of the sum of the capacities of the individual [hard drives](../item/hdd1.md) and is available to all [computers](../general/computer.md) connected to the raid.
|
||||
The raid block houses three [hard drives](../item/hdd1.md) which will be combined into a single file system. This combined file system has the size of the sum of the capacities of the individual [hard drives](../item/hdd1.md) and is available to all [computers](../general/computer.md) connected to the raid.
|
||||
|
||||
The raid only works (and shows up as a file system) when three [hard drives](../item/hdd1.md) are present. The [hard drives](../item/hdd1.md) may differ in size.
|
||||
|
||||
Beware that adding a [hard drive](../item/hdd1.md) to the raid block will wipe it of its contents. Removing a single [hard drives](../item/hdd1.md) from a complete raid will also wipe the raid. Adding the disk back in will *not* restore it, the raid's new file system will not contain any files.
|
||||
Beware that adding a [hard drive](../item/hdd1.md) to the raid block will wipe it of its contents. Removing a single [hard drives](../item/hdd1.md) from a complete raid will wipe the entire raid. Adding the disk back in will *not* restore the old files; the raid will be re-initialized as an empty file system.
|
||||
|
||||
Breaking a raid block will retain its contents, so it can be safely relocated without losing any data.
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
|
||||
|
||||
|
||||
The Redstone I/O block can be used to remotely read and emit redstone signals. It behaves like a hybrid of a tier 1 and 2 [redstone card](../item/redstoneCard1.md): it can read and emit simple analog as well as bundled signals, but cannot read or emit wireless redstone signals.
|
||||
The redstone I/O block can be used to remotely read and emit redstone signals. It behaves like a hybrid of a tier 1 and 2 [redstone card](../item/redstoneCard1.md): it can read and emit simple analog as well as bundled signals, but cannot read or emit wireless redstone signals.
|
||||
|
||||
When providing a side to the methods of the component exposed by this block, the directions are the global principal directions, i.e. it is recommended to use sides.north, sides.east and so on.
|
||||
When providing a side to the methods of the component exposed by this block, the directions are the global principal directions, i.e. it is recommended to use `sides.north`, `sides.east` and so on.
|
||||
|
||||
Like the redstone card, this block injects a signal into connected computers when the state of a redstone signal changes - both for analog as well as for bundled signals.
|
||||
Like the [redstone cards](../item/redstoneCard1.md), this block injects a signal into connected [computers](../general/computer.md) when the state of a redstone signal changes - both for analog as well as for bundled signals. This block can also be configured to wake up connected [computers](../general/computer.md) when a certain input strength is exceeded, allowing automated booting of [computers](../general/computer.md).
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
|
||||
|
||||
|
||||
Unlike computers, robots can move around and interact with the world much like a player can. They can *not* interact with external components, however! If you need to communicate with a computer or other robots, use a [wireless network card](../item/wlanCard.md), or create some low-level protocol using redstone signals via a [redstone card](../item/redstoneCard1.md), for example.
|
||||
Unlike [computers](../general/computer.md), robots can move around and interact with the world much like a player can. They can *not* interact with external components, however! If you need to communicate with a [computer](../general/computer.md) or other robots, use a [wireless network card](../item/wlanCard.md), or create some low-level protocol using redstone signals via a [redstone card](../item/redstoneCard1.md), for example.
|
||||
|
||||
Robots are built by placing a [computer case](case1.md) of any tier in an [assembler](assembler.md). Higher tier computer cases can build more complex robots, due to being able to hold a higher tier [CPU](../item/cpu1.md). Complexity of the robot (as shown in the [assembler](assembler.md)) is determined by the tier of the components and upgrades placed in the robot slots; higher tier components will increase the complexity more than a lower tier component. If the complexity of the robot is too high, the [assembler](assembler.md) will not build the robot.
|
||||
Robots are built by placing a [computer case](case1.md) of any tier in an [assembler](assembler.md). Higher tier [computer cases](case1.md) can build more complex robots, due to being able to hold a higher tier [CPU](../item/cpu1.md). Complexity of the robot (as shown in the [assembler](assembler.md)) is determined by the tier of the components and upgrades placed in the robot slots; higher tier components will increase the complexity more than a lower tier component. If the complexity of the robot is too high, the [assembler](assembler.md) will not build the robot.
|
||||
|
||||
Various upgrades can be placed into robots to increase the functionality. These include [inventory](../item/inventoryUpgrade.md) and [inventory controller](../item/inventoryControllerUpgrade.md) upgrades, [tank upgrades](../item/tankUpgrade.md), [navigation upgrade](../item/navigationUpgrade.md), among others. [Upgrade](../item/upgradeContainer1.md) and [card](../item/cardContainer1.md) containers can be placed in the robot for on-the-fly insertion and removal of upgrades and components. A [disk drive](diskDrive.md) can also be placed inside a robot to allow [floppy disks](../item/floppy.md) to be inserted, which will let you install openOS to the robot (an alternative is to install openOS to a blank [hard drive](../item/hdd1.md) using a computer, and using the pre-installed [hard drive](../item/hdd1.md) as a component in the robot assembly).
|
||||
Various upgrades can be placed into robots to increase the functionality. These include [inventory](../item/inventoryUpgrade.md) and [inventory controller](../item/inventoryControllerUpgrade.md) upgrades, [tank upgrades](../item/tankUpgrade.md), [navigation upgrade](../item/navigationUpgrade.md), among others. [Upgrade](../item/upgradeContainer1.md) and [card](../item/cardContainer1.md) containers can be placed in the robot for on-the-fly insertion and removal of upgrades and components. A [disk drive](diskDrive.md) can also be placed inside a robot to allow [floppy disks](../item/floppy.md) to be inserted, which will let you install [openOS](../general/openOS.md) to the robot (an alternative is to install [openOS](../general/openOS.md) to a blank [hard drive](../item/hdd1.md) using a [computer](../general/computer.md), and using the pre-installed [hard drive](../item/hdd1.md) as a component in the robot assembly).
|
||||
|
||||
@ -2,15 +2,17 @@
|
||||
|
||||
|
||||
|
||||
A Screen is used in combination with a [graphics card](../item/graphicsCard1.md), to allow computers to display text. Different screen tiers have different capabilities, such as supporting different resolutions and color depths. Screens range from low-resolution, monochrome displays to high-resolution displays with up to 256 colors.
|
||||
A screen is used in combination with a [graphics card](../item/graphicsCard1.md), to allow [computers](../general/computer.md) to display text. Different screen tiers have different capabilities, such as supporting different resolutions and color depths. Screens range from low-resolution, monochrome displays to high-resolution displays with up to 256 colors.
|
||||
|
||||
The available resolution and color depth depends on the lowest tier component. When using a [graphics card (tier 1)](../item/graphicsCard1.md) with a [screen (tier 3)](screen3.md), only the tier 1 resolution and color depth is usable.
|
||||
The available resolution and color depth depends on the lowest tier component. When using a [graphics card (tier 1)](../item/graphicsCard1.md) with a [screen (tier 3)](screen3.md), only the tier 1 resolution and color depth is usable. However, when using a tier 3 [graphics card](../item/graphicsCard1.md) with a tier 1 screen, while resolution and color depth will still be limit to tier 1, the different operations on the [graphics card](../item/graphicsCard1.md) will be faster than when using a tier 1 [graphics card](../item/graphicsCard1.md).
|
||||
|
||||
Screens can be placed next to each other to form multi-block screens. This has no impact on the available resolution. To control how adjacent screens connect, screens can also be dyed using any dye. Screens with different colors will not connect. Screens with different tiers will never connect, even if they have the same color.
|
||||
Screens can be placed next to each other to form multi-block screens, as long as they are facing the same way. When placed facing up or down they must also be rotated the same way. Their orientation is indicated by an arrow overlay shown while holding a screen in hand.
|
||||
|
||||
Tier 2 and tier 3 screens also support mouse input. Clicks can either be performed in a screen's GUI (which can only be opened if a keyboard is connected to the screen), or by sneak-activating a screen empty-handed. Note that whether the GUI opens when sneak- or normally activating a screen can be controlled via the component it exposes to connected computers.
|
||||
The size of a screen has no impact on the available resolution, only its tier has. To control how adjacent screens connect, screens can also be dyed using any dye. Simply right-click the screen with a dye in hand. The dye will not be consumed, but screens will not retain this color when broken. Screens with different colors will not connect. Screens with different tiers will never connect, even if they have the same color.
|
||||
|
||||
Tier 2 and tier 3 screens also support mouse input. Clicks can either be performed in a screen's GUI (which can only be opened if a [keyboard](keyboard.md) is connected to the screen), or by using a screen while sneaking (empty-handed when in doubt). The sneaking part is optional if the screen has no [keyboard](keyboard.md). Note that whether the GUI opens when sneak- or normally activating a screen can be controlled using the component API that it exposes to connected [computers](../general/computer.md). Tier 3 screens allow more accurate hit position detection, if enabled in their component. This allows detecting whether the upper or lower half of a single character space was clicked, for example, which can be useful when using special Unicode characters to simulate higher resolutions.
|
||||
|
||||
The resolutions and color depths for the screens are as follows:
|
||||
- Tier 1: 50x16, 1-bit color.
|
||||
- Tier 2: 80x25, 4-bit color.
|
||||
- Tier 3: 160x50, 8-bit color.
|
||||
- Tier 3: 160x50, 8-bit color.
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
|
||||
|
||||
|
||||
A Server Rack houses up to four [servers](../item/server1.md). A server is a higher tier computer, which can only run when inside a server rack. [Servers](../item/server1.md) can be remote controlled using a [remote terminal](../item/terminal.md). The number of terminals that can be connected to a single server at a time depends on the tier of the server. The distance up to which the remote terminals work can be configured in the rack's GUI. Higher values have a higher constant energy draw.
|
||||
A server rack houses up to four [servers](../item/server1.md). A [server](../item/server1.md) is a higher tier [computer](../general/computer.md), which can only run when inside a server rack. [Servers](../item/server1.md) can be remote controlled using a [remote terminal](../item/terminal.md). The number of [remote terminals](../item/terminal.md) that can be connected to a single [server](../item/server1.md) at a time depends on the tier of the [server](../item/server1.md). The distance up to which the [remote terminal](../item/terminal.md) work can be configured in the rack's GUI. Higher values have require more energy.
|
||||
|
||||
Each [server](../item/server1.md) in a server rack can only communicate with one "face" of the server rack at a time - or none at all. Which side each [server](../item/server1.md) is connected to can be configured in the server rack's GUI. Beware that the sides are from the point of view of the server rack, i.e. if you are looking at the front of the server rack, right will be to your left and vice versa.
|
||||
Each [server](../item/server1.md) in a server rack can only communicate with one "face" of the server rack at a time - or none at all. Which side each [server](../item/server1.md) is connected to can be configured in the server rack's GUI. Beware that the sides are from the point of view of the server rack, i.e. if you are looking at the front of the server rack, `sides.right` will be to your left and vice versa.
|
||||
|
||||
Server racks act as [switch](switch.md) and [power distributor](powerDistributor.md) in one. The switch mode of the server rack can be configured in its GUI, with the two options being internal and external. In external mode the server rack will behave like a normal switch. In internal mode, messages are only passed to the [servers](../item/server.md) in the rack, they will not be automatically relayed to the other faces of the rack. [Servers](../item/server1.md) will still be able to send messages to each other. This allows using server racks as advanced switches that can perform filter and mapping operations, for example.
|
||||
Server racks act as [switch](switch.md) and [power distributor](powerDistributor.md) in one. The switch mode of the server rack can be configured in its GUI, with the two options being internal and external. In external mode the server rack will behave like a normal [switch](switch.md). In internal mode, messages are only passed to the [servers](../item/server.md) in the rack, and will not be automatically relayed to the other faces of the rack. [Servers](../item/server1.md) will still be able to send messages to each other. This allows using server racks as advanced [switches](switch.md) that can perform filter and mapping operations, for example.
|
||||
|
||||
@ -2,10 +2,10 @@
|
||||
|
||||
|
||||
|
||||
The switch can be used to allow different subnetworks to send network messages to each other, without exposing components to computers in other networks. Keeping components local is usually a good idea, to avoid computers using the wrong screen or to avoid component overflows to happen (in which computers will crash / not start anymore).
|
||||
The switch can be used to allow different subnetworks to send network messages to each other, without exposing components to [computers](../general/computer.md) in other networks. Keeping components local is usually a good idea, to avoid [computers](../general/computer.md) using the wrong [screen](screen1.md) or to avoid component overflows to happen (causing [computers](../general/computer.md) to crash and refuse to boot up).
|
||||
|
||||
There is also a wireless variation of this block, called the [access point](accessPoint.md), which will also relay messages wirelessly.
|
||||
There is also a wireless variation of this block, called the [access point](accessPoint.md), which will also relay messages wirelessly. Wireless messages can be received and relayed by other [access points](accessPoint.md), or by [computers](../general/computer.md) with a [wireless network card](../item/wlanCard.md).
|
||||
|
||||
Switches and [access points](accessPoint.md) do *not* keep track of which packets they relayed recently, so avoid cycles in your network or you may receive the same packet multiple times.
|
||||
Switches and [access points](accessPoint.md) do *not* keep track of which packets they relayed recently, so avoid cycles in your network or you may receive the same packet multiple times. Due to the limited buffer size of switches, sending messages too frequently will result in packet loss. You can upgrade your switches and [access points](accessPoint.md) to increase the speed with which they relay messages, as well as their internal message queue size.
|
||||
|
||||
Packets are only re-sent a certain number of times, so chaining an arbitrary number of switches or access points is not possible.
|
||||
Packets are only re-sent a certain number of times, so chaining an arbitrary number of switches or access points is not possible. By default, a packet will be re-sent up to five times.
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
# Computers
|
||||
|
||||
Computers are built using a variety of different [blocks](../block/index.md) and components. The bare minimum needed to build a computer is a [case](../block/case1.md), [screen](../block/screen1.md), and [keyboard](../block/keyboard.md). The case and screen are available in different tiers providing different functionality and allowing for more complex computer systems. In order for the screen to be accessible, the keyboard must be placed adjacent to the screen (either on the sides or directly in front of the screen).
|
||||
Computers are built using a variety of different [blocks](../block/index.md) and components. The bare minimum needed to build a computer is a [case](../block/case1.md), [screen](../block/screen1.md), and [keyboard](../block/keyboard.md). The [case](../block/case1.md) and [screen](../block/screen1.md) are available in different tiers providing different functionality and allowing for more complex computer systems. In order for the [screen](../block/screen1.md) to be accessible, the [keyboard](../block/keyboard.md) must be placed adjacent to the [screen](../block/screen1.md) (either on the sides or directly in front of the [screen](../block/screen1.md)).
|
||||
|
||||
Once the basic structure is built, components can be placed inside the [case](../block/case1.md). These components include [CPUs](../item/cpu1.md), [memory (RAM)](../item/ram1.md), [hard disk drives (HDD)](../item/hdd1.md), [graphics cards](../item/graphicsCard1.md) (to be able to use the [screen](../block/screen1.md)), [network cards](../item/lanCard.md) (for communication between computer networks), etc. There are many components available allowing for highly flexible systems designed for specific purposes.
|
||||
Once the basic structure is built, components can be placed inside the [case](../block/case1.md). These components include [CPUs](../item/cpu1.md), [memory (RAM)](../item/ram1.md), [hard drives (HDD)](../item/hdd1.md), [graphics cards](../item/graphicsCard1.md) (to be able to use the [screen](../block/screen1.md)), [network cards](../item/lanCard.md) (for communication between computer networks), etc. There are many components available allowing for highly flexible systems designed for specific purposes.
|
||||
|
||||
Lower tier computers also require a [disk drive](../block/diskDrive.md), which takes a [floppy](../item/floppy.md) disk. An OpenOS [floppy](../item/floppy.md) disk is needed for booting up the computer for the first time, and is used to install the operating system to the [HDD](../item/hdd1.md). Once installed to the [HDD](../item/hdd1.md), the [floppy](../item/floppy.md) disk is no longer necessary. Additional software is also available as [floppy](../item/floppy.md) disks (such as Open Programs Package Manager, or OPPM) and are obtained from dungeon loot.
|
||||
Lower tier computers also require a [disk drive](../block/diskDrive.md), which takes a [floppy](../item/floppy.md) disk. An [OpenOS](openOS.md) [floppy](../item/floppy.md) disk is needed for booting up the computer for the first time, and is used to install the operating system to the [HDD](../item/hdd1.md). Once installed to the [HDD](../item/hdd1.md), the [floppy](../item/floppy.md) disk is no longer necessary. Additional software is also available as [floppy](../item/floppy.md) disks (such as Open Programs Package Manager, or OPPM) and are obtained from dungeon loot.
|
||||
|
||||
The final step necessary is to provide the computer with a power source. OpenComputers is compatible with most major power-providing mods, and many blocks can be powered directly. You can see which blocks can be connected to external power by checking if their tooltip contains an entry about the block's power conversion speed.
|
||||
For a larger network with multiple computers, a [power converter](../block/powerConverter.md) (converts different mod's power to OC's internal Energy type), [power distributor](../block/powerDistributor.md) (distributes power to different computers), and [capacitor](../block/capacitor.md) (power storage for the network) can be used to connect different computers on the network using Cables.
|
||||
For a larger network with multiple computers, a [power converter](../block/powerConverter.md) (converts different mod's power to OC's internal Energy type), [power distributor](../block/powerDistributor.md) (distributes power to different computers on the network), and [capacitor](../block/capacitor.md) (power storage for the network) can be used to connect different computers on the network using [cables](../block/cable.md).
|
||||
|
||||
@ -1,12 +1,16 @@
|
||||
# Lua
|
||||
|
||||
The Lua [reference manual](http://www.lua.org/manual/5.2/manual.html) is a good place to get started with the basics of Lua and becoming familiar with the basic syntax and standard libraries. OpenComputers has very similar standard libraries, and omits certain libraries almost entirely (such as about 99% of the debug library).
|
||||
The Lua [reference manual](http://www.lua.org/manual/5.2/manual.html) and the [Programming in Lua](http://www.lua.org/pil/) books (first edition is available for free online) are a good place to get started with the basics of Lua and becoming familiar with the basic syntax and standard libraries. [OpenOS](openOS.md) strives to emulate the standard libraries very closely, with a few deviations, such as the mostly missing debug library (for sandboxing reasons). These differences are [documented on the wiki](http://ocdoc.cil.li/api:non-standard-lua-libs).
|
||||
|
||||
Non-standard libraries will need to be *required* in order to use them in a script. For example:
|
||||
Non-standard libraries will need to be `require`d in order to use them in a script. For example:
|
||||
|
||||
`local component = require("component")`
|
||||
`local rs = component.redstone`
|
||||
`local component = require("component")`
|
||||
`local rs = component.redstone`
|
||||
|
||||
This will allow you to call all of the functions provided by the [redstone](../item/redstoneCard1.md) component.
|
||||
This will allow you to call all of the functions provided by the [redstone](../item/redstoneCard1.md) component. For example:
|
||||
|
||||
OpenComputers provides many custom libraries which can be used for many applications, from controlling and manipulating components attached to the [computer](computer.md), to reference APIs for colors and keyboard keycodes. Custom libraries can be used within a Lua script by using the `require()` function, as above. Some custom libraries require specific components to work, such as the Internet library requiring an [internet card](../item/internetCard.md).
|
||||
`rs.setOutput(require("sides").front, 15)`
|
||||
|
||||
**Important**: when working in the Lua interpreter, *do not* use `local`, as that will make the variables local to a single line of input. Meaning if you were to enter the lines above one after another in the interpreter, the third one would error, telling you that `rs` is a `nil` value. Why only on the third line, you ask? Because, for ease of testing, the interpreter tries to load unknown variables as libraries. So even though the assignment to `component` from the first line would nothing, the use of `component` on the second line would cause that library to be loaded and used. Libraries are not automatically used when using Lua scripts to keep memory usage low, because that's a limited resource.
|
||||
|
||||
OpenOS provides many custom libraries which can be used for many applications, from controlling and manipulating components attached to the [computer](computer.md), to reference APIs for colors used in bundled redstone control and [keyboard](../block/keyboard.md) keycodes. Custom libraries can be used within a Lua script by using the `require()` function, as above. Some custom libraries require specific components to work, such as the `internet` library requiring an [internet card](../item/internetCard.md). In that particular case it is even being provided by it, i.e. the library will show up once you install an internet card - technically speaking, it is contained on a small, read-only file system on the internet card.
|
||||
|
||||
@ -1,7 +1,12 @@
|
||||
# OpenOS
|
||||
|
||||
OpenOS is a basic operating system available in OpenComputers. It is required to boot up a [computer](computer.md) for the first time, and can be crafted by placing an empty [floppy disk](../item/floppy.md) and an OpenComputers manual inside a Crafting table.
|
||||
OpenOS is a basic operating system available in OpenComputers. It is required to boot up a [computer](computer.md) for the first time, and can be crafted by placing an empty [floppy disk](../item/floppy.md) and an OpenComputers [manual](../item/manual.md) inside a crafting table.
|
||||
|
||||
Once crafted, the [floppy disk](../item/floppy.md) can be placed inside a [disk drive](../block/diskDrive.md) connected to a [computer](computer.md) system, which will allow the [computer](computer.md) to boot up OpenOS. Once booted, it is advisable to install OpenOS to an empty [hard drive](../item/hdd1.md), foregoing the need for a [floppy disk](../item/floppy.md) and to gain access to a read-write file system ([floppy disk](../item/floppy.md) are read-only). A tier 3 [computer case](../block/case3.md) does not require a [disk drive](../block/diskDrive.md), as it has a slot built in for the [floppy disk](../item/floppy.md). OpenOS can be installed by simply running `install`, and following the on-screen prompts to complete the installation. The [floppy disk](../item/floppy.md) may be removed once the system has been rebooted. OpenOS can be installed on all devices except [drones](../item/drone.md) and [microcontrollers](../block/microcontroller.md) (both of which require manually programming an [EEPROM](../item/eeprom.md) to provide functionality).
|
||||
Once crafted, the [floppy disk](../item/floppy.md) can be placed inside a [disk drive](../block/diskDrive.md) connected to a [correctly configured](quickstart.md) [computer](computer.md) system, which will allow the [computer](computer.md) to boot up OpenOS.
|
||||
Once booted, it is advisable to install OpenOS to an empty [hard drive](../item/hdd1.md), foregoing the need for a [floppy disk](../item/floppy.md) and to gain access to a read-write file system (the OpenOS [floppy disk](../item/floppy.md) and other "loot" disks are read-only). A tier 3 [computer case](../block/case3.md) does not require a [disk drive](../block/diskDrive.md), as it has a slot built in for the [floppy disk](../item/floppy.md).
|
||||
|
||||
OpenOS has many built in functions, the most useful of them is the `lua` command, which opens up a Lua interpreter. This is a good testing space for trying out various commands, and experimenting with component API, before writing the commands into a .lua script. For more information on programming, refer to the [Lua Programming](lua.md) page. To run Lua scripts, simply type in the name of the file and hit enter (for example, script.lua can be run by typing the `script` command in the terminal).
|
||||
OpenOS can be installed by simply running `install`, and following the on-screen prompts to complete the installation. The [floppy disk](../item/floppy.md) may be removed once the system has been rebooted. OpenOS can be installed on all devices except [drones](../item/drone.md) and [microcontrollers](../block/microcontroller.md) (both of which require manually programming an [EEPROM](../item/eeprom.md) to provide functionality, because they have no built in file system).
|
||||
|
||||
OpenOS has many built in functions, the most useful of them is the `lua` command, which opens up a Lua interpreter. This is a good testing space for trying out various commands, and experimenting with component API, before writing the commands into a .lua script. Take note of the information displayed when starting the interpreter, it will tell you how to show results of the commands you enter, and how to exit it.
|
||||
|
||||
For more information on programming, refer to the [Lua Programming](lua.md) page. To run Lua scripts, simply type in the name of the file and hit enter (for example, `script.lua` can be run by typing the `script` command in the terminal).
|
||||
|
||||
@ -0,0 +1,50 @@
|
||||
# Getting Started
|
||||
|
||||
Also know as "how to build your first computer". To get your first [computer](computer.md) to run, you will need to first set it up correctly. There are many different types of computers in OpenComputers, but let's start with the basic one: the standard computer.
|
||||
|
||||
**Disclaimer**: this will be step-by-step, and also provide some information on how to look for issues yourself later on, so this is quite long. If you have never built a computer in real life, and/or are completely new to the mod, it is highly recommended you read through it all.
|
||||
|
||||
First off, you will need a [computer case](../block/case1.md). This is the block which will contain of the components, defining the behavior of the computer you are building.
|
||||
|
||||
|
||||
|
||||
For example, you will need to choose what tier of [graphics card](../item/graphicsCard1.md) you wish to use, if you need a [network card](../item/lanCard.md), a [redstone card](../item/redstoneCard1.md) or, if you're just playing around in creative mode, maybe even a [debug card](../item/debugCard.md).
|
||||
|
||||
When you open the [computer case](../block/case1.md)'s GUI you will see a few slots to the right. The number of slots, and what tier of component can be placed into them (indicated by the small roman numeral in the slot) depends on the tier of the case itself.
|
||||
|
||||
In their empty state, [computer cases](../block/case1.md) are pretty useless. You can try to power up your [computer](computer.md) now, but it'll immediately print an error message to your chat log, and make its dissatisfaction heard by beeping at you. Good thing the error message is telling you what you can do to fix this situation: it requires energy. Connect your [computer](computer.md) to some power, either directly or via a [power converter](../block/powerConverter.md).
|
||||
|
||||
When you try to start it now, it will tell you that you need a [CPU](../item/cpu1.md). These come in different tiers - a trend you will notice is present throughout OpenComputers. For [CPUs](../item/cpu1.md), higher tiers mean more components at a time, as well as faster execution. So pick a tier, and put it in your [computer case](../block/case1.md).
|
||||
|
||||
Next up you will be asked to insert some [memory (RAM)](../item/ram1.md). Notice that the beep code is different now: long-short. Higher tiers of [memory (RAM)](../item/ram1.md) mean more memory available to the programs running on your [computer](computer.md). To run [OpenOS](openOS.md), which is the goal of this introduction, you will want to use at least two tier 1 [memory (RAM)](../item/ram1.md) sticks.
|
||||
|
||||
We're making good progress here. By now your [computer case](../block/case1.md) will look somewhat like this:
|
||||
|
||||
And behold, turning it on now does not print any more error messages! But alas, it still doesn't do much. At least it beeps twice now. That means the actual execution of the [computer](computer.md) failed. In other words: it technically runs! This is where a very useful tool comes into play: the [analyzer](../item/analyzer.md). This tool allows inspecting many of OpenComputers' blocks, as well as some blocks from other mods. To use it on the [computer](computer.md), use the [analyzer](../item/analyzer.md) on the case while sneaking.
|
||||
|
||||
You should now see the error that caused the [computer](computer.md) to crash:
|
||||
`no bios found; install configured EEPROM`
|
||||
|
||||
The emphasis here is on *configured*. Crafting an [EEPROM](../item/eeprom.md) is pretty simple. To configure it, you will usually use a [computer](computer.md) - but that's a little difficult right now, so we're going to use a recipe to craft a configured "Lua BIOS" [EEPROM](../item/eeprom.md). The standard recipe is an [EEPROM](../item/eeprom.md) plus a [manual](../item/manual.md). Put the configured [EEPROM](../item/eeprom.md) into your [computer](computer.md), aaaand.
|
||||
|
||||
Nope. Still nothing. But we know what to do: player uses [analyzer](../item/analyzer.md), it's super effective! Now we have a different error message:
|
||||
`no bootable medium found; file not found`
|
||||
|
||||
Well then. That means the BIOS is working. It's just not finding a file system to boot from, such as a [floppy](../item/floppy.md) or [hard drive](../item/hdd1.md). The Lua BIOS in particular expects such a file system to furthermore contain a file named `init.lua` at root level. As with the [EEPROM](../item/eeprom.md), you usually write to file systems using a [computer](computer.md). You probably guessed it: we now need to craft our operating system disk. Take a blank [floppy disk](../item/floppy.md) and a [manual](../item/manual.md), craft them together, and you'll get an [OpenOS](openOS.md) disk.
|
||||
|
||||
Now, if you used a tier 2 [computer case](../block/case2.md) as in the screenshots above, you'll have nowhere to place that floppy. If you have a tier 3 or creative [computer case](../block/case3.md), you can place the floppy right into the [case](../block/case1.md). Otherwise you'll need to place a [disk drive](../block/diskDrive.md) next to your case (or connect it via [cables](../block/cable.md)). Once your disk is in place, you know what to do. Press the power button.
|
||||
|
||||
It lives! Or should, anyway. If it doesn't something went wrong, and you'll want to investigate using the [analyzer](../item/analyzer.md). But assuming it's running now, you're pretty much done. The hardest part is over. All that's left is to make it take input and show some output.
|
||||
|
||||
To allow the [computer](computer.md) to show some output, you'll want to grab a [screen](../block/screen1.md) and a [graphics card](../item/graphicsCard1.md).
|
||||
|
||||
|
||||
Place the [screen](../block/screen1.md) adjacent to your [computer case](../block/case1.md), or, again, connect it using some [cable](../block/cable.md). Then place a [graphics card](../item/graphicsCard1.md) of your choice into the [computer case](../block/case1.md). You should now see a blinking cursor on the [screen](../block/screen1.md). Finally, place a [keyboard](../block/keyboard.md) either on the [screen](../block/screen1.md) itself, or in a way so that it faces the [screen](../block/screen1.md), to enable [keyboard](../block/keyboard.md) input.
|
||||
|
||||
And with that, you're done. The [computer](computer.md) is up and running and ready for action. Try using it now! Type `lua` in the shell and press enter, and you'll be greeted with a bit of information on how to use the Lua interpreter. Here you can test basic Lua commands. For more information this topic see [the Lua page](lua.md).
|
||||
|
||||
|
||||
|
||||
Have fun building more complex [computers](computer.md), messing with [servers](../item/server1.md) and assembling [robots](../block/robot.md), [drones](../item/drone.md), [microcontrollers](../block/microcontroller.md) and [tablets](../item/tablet.md) in the [assembler](../block/assembler.md).
|
||||
|
||||
Happy coding!
|
||||
@ -2,33 +2,38 @@
|
||||
|
||||
OpenComputers is a mod that adds persistent, modular, and highly configurable [computers](general/computer.md), [servers](item/server1.md), [robots](block/robot.md), and [drones](item/drone.md) to the game. All devices can be programmed using Lua 5.2, allowing for systems with varying complexity depending on the usage.
|
||||
|
||||
To learn about how to use the manual, check out [the page about the manual](item/manual.md) (that green text is a link, you can click it). You can find a table of contents at the bottom of this page.
|
||||
To learn about how to use the manual, check out [the page about the manual](item/manual.md) (that green text is a link, you can click it).
|
||||
|
||||
Persistence ensures that a running [computer](general/computer.md) retains its state when the chunk it is in is unloaded. This means that if the player moves away from the [computer](general/computer.md), or logs off, the [computer](general/computer.md) will remember its last known state and continue from that point on when the player goes near the [computer](general/computer.md). Persistence works for all devices except for [tablets](item/tablet.md).
|
||||
## Table of Contents
|
||||
|
||||
### Devices
|
||||
- [Computers](general/computer.md)
|
||||
- [Servers](item/server1.md)
|
||||
- [Microcontrollers](block/microcontroller.md)
|
||||
- [Robots](block/robot.md)
|
||||
- [Drones](item/drone.md)
|
||||
|
||||
### Software and Programming
|
||||
- [OpenOS](general/openOS.md)
|
||||
- [Lua](general/lua.md)
|
||||
|
||||
### Blocks and Items
|
||||
- [Items](item/index.md)
|
||||
- [Blocks](block/index.md)
|
||||
|
||||
### Guides
|
||||
- [Getting Started](general/quickstart.md)
|
||||
|
||||
## Overview
|
||||
|
||||
As mentioned above, computers in OpenComputers feature persistence, which means that a running [computer](general/computer.md) retains its state when the chunk it is in is unloaded. This means that if the player moves away from the [computer](general/computer.md), or logs off, the [computer](general/computer.md) will remember its last known state and continue from that point on when the player goes near the [computer](general/computer.md). Persistence works for all devices except for [tablets](item/tablet.md).
|
||||
|
||||
All devices are modular and can be assembled with a wide range of components, just like [computers](general/computer.md) in real life. Players who enjoy tinkering will be able to optimize devices to their heart's content. If desired, devices can be [dismantled](block/disassembler.md) and rebuilt if the initial configuration wasn't satisfactory. For [computers](general/computer.md) and [servers](item/server1.md), components can be swapped out on-the-fly simply by opening the corresponding GUI.
|
||||
|
||||
OpenComputers devices are compatible with many different mods for manipulation of blocks and entities (through the [adapter](block/adapter.md), or specific upgrades in a [robot](block/robot.md) or [drone](item/drone.md)). Power can be supplied using a large range of other mods, including, but not limited to, Redstone Flux, IndustrialCraft2 EU, Mekanism Joules, Applied Energistics 2 energy as well as Factorization Charge.
|
||||
|
||||
Most devices are able to run a basic operating system called [OpenOS](general/openOS.md) (with the exception of drones and microcontrollers). OpenComputers allows for creation of custom OSes and Architectures, should the player desire it.
|
||||
Most devices are able to run a basic operating system called [OpenOS](general/openOS.md) (with the exception of [drones](item/drone.md) and [microcontrollers](block/microcontroller.md). OpenComputers allows for creation of custom OSes and Architectures, should the player desire it.
|
||||
|
||||
Devices have access to various resources such as [disk space](item/hdd1.md) and [memory (RAM)](item/ram1.md). [Microcontrollers](block/microcontroller.md) are cheap [computers](general/computer.md) with less functionality and components, and do not have an operating system, requiring creative use of programming. [Robots](block/robot.md) are mobile [computers](general/computer.md) and are able to interact with blocks and entities (but are unable to interact with external OpenComputers components). [Drones](item/drone.md) are fast, entity-based [robots](block/robot.md) with limited functionality, able to move differently and are able to interact differently with the world. [Servers](item/server1.md) are higher tier [computers](general/computer.md) and are able to hold more components, increasing the amount of resources available to control larger networks and run larger programs.
|
||||
|
||||
This manual contains detailed information regarding all blocks and items, how to set up different types of systems and devices, as well as an introduction to Lua programming.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
### Devices
|
||||
- [Computers](general/computer.md)
|
||||
- [Servers](item/server1.md)
|
||||
- [Microcontrollers](block/microcontroller.md)
|
||||
- [Robots](block/robot.md)
|
||||
- [Drones](item/drone.md)
|
||||
|
||||
### Software and Programming
|
||||
- [OpenOS](general/openOS.md)
|
||||
- [Lua](general/lua.md)
|
||||
|
||||
### Blocks and Items
|
||||
- [Items](item/index.md)
|
||||
- [Blocks](block/index.md)
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
This card allows [computers](../general/computer.md), [servers](server1.md) and robots to interact with StargateTech2's abstract bus. When the card is installed, these blocks will connect to the abstract bus and a component becomes available to the machine that can be used to send messages across the abstract bus. Incoming abstract bus messages are converted to signals that are injected into the machine.
|
||||
This card allows [computers](../general/computer.md), [servers](server1.md) and [robots](../block/robot.md) to interact with StargateTech2's abstract bus. When the card is installed, these blocks will connect to the abstract bus and a component becomes available to the machine that can be used to send messages across the abstract bus. Incoming abstract bus messages are converted to signals that are injected into the machine.
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
You'll probably only see this item when playing with the hardmode recipe set, in which case you'll need it to etch [circuit boards](circuitBoard.md) to craft [printed circuit boards](printedCircuitBoard.md).
|
||||
Encountered only when using hard-mode recipes, it is used to etch [circuit boards](circuitBoard.md) before crafting [printed circuit boards](printedCircuitBoard.md).
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
Used for crafting most things pushing numbers, such as [CPUs](cpu1.md) and [graphics cards](graphicsCard1.md).
|
||||
Used for crafting components that perform calculations, such as [CPUs](cpu1.md) and [graphics cards](graphicsCard1.md).
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The analyzer is a handy tool for getting some information about OpenComputers-related blocks in the world. Simply (sneak-)activate a block to get some information printed to the chat. This ranges from basic things like the address of components, to power levels in the subnetwork the block is in, and information on the error lead to a computer to crash, for example.
|
||||
The analyzer is a handy tool for reading information about OpenComputers-related blocks in the world. Simply (sneak-)activate a block to get some information printed to the chat box. This ranges from basic things like the address of components, to power levels in the subnetwork the block is in, and information on the error lead to a [computer](../general/computer.md) to crash, for example.
|
||||
|
||||
Another useful functionality is that when using the using the analyzer on a block while holding down **Ctrl** the address of the block component will be copied to the clipboard. This information can then be pasted into a [computer](../general/computer.md) terminal if necessary.
|
||||
Another useful functionality is that when Ctrl-rightclicking a block or component, the address of that component is copied to the clipboard. This information can then be pasted into a [computer](../general/computer.md) terminal if needed.
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
This upgrade allows robots to place blocks in thin air, without a reference block, similar to a certain block by a certain mod this upgrade may or may not have been inspired by.
|
||||
This upgrade allows [robots](../block/robot.md) to place blocks in thin air, without a reference block.
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
At the risk of repeating myself: it's a button sink. Because the button economy has seen some serious inflation in recent years.
|
||||
At the risk of repeating myself: it's a button sink. Because the button economy has seen some serious inflation in recent years. It is used as a component for building [keyboards](../block/keyboard.md).
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
This upgrade increases the internal energy buffer of devices, such as [robots](../block/robot.md) and [tablets](tablet.md), allowing them to operate longer without having to return to a charger.
|
||||
This upgrade increases the internal energy buffer of devices, such as [robots](../block/robot.md) and [tablets](tablet.md), allowing them to operate longer without having to return to a [charger](../block/charger.md). Higher tier battery upgrades can store more energy.
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
Because you *always* have too many buttons lying around somewhere. Don't lie. We all shift-click that button recipe time and again.
|
||||
Because you *always* have too many buttons lying around somewhere. Don't lie. We all shift-click that button recipe time and again. Button groups are used to build [keyboards](../block/keyboard.md).
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
Common crafting material for most, if not all card components in OpenComputers.
|
||||
Common crafting material for card components in OpenComputers (such as [graphics cards](graphicsCard1.md), [network cards](lanCard.md), etc).
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
The card container is a container type upgrade for [robots](../block/robot.md) that provides a slot in the finished robots into which cards can be placed. The tier of card that the slot can hold is equal to the tier of the container. Unlike normal upgrades, the complexity of containers is twice their tier. See [here](../block/robot.md) for details on robot complexity.
|
||||
The card container is a container upgrade for [robots](../block/robot.md) allowing cards to be inserted/removed to/from [robots](../block/robot.md) on-the-fly. The maximum tier of card that the slot can hold is equal to the tier of the container. Unlike normal upgrades, the complexity of containers is twice their tier. See [here](../block/robot.md) for details on robot complexity.
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
|
||||
|
||||
|
||||
Chamelium is a shape-shifting material that is used when creating [3D prints](../block/print.md) in a [3D printer](../block/printer.md). On its own it is featureless and therefore very useful for creating simple, plain and monochrome areas.
|
||||
Chamelium is a shape-shifting material that is used when creating [3D prints](../block/print.md) in a [3D printer](../block/printer.md). On its own, it is featureless and therefore very useful for creating simple, plain and monochrome areas.
|
||||
|
||||
You can also slap some of it together to create a [block of Chamelium](../block/chameliumBlock.md).
|
||||
You can also combine them to create a [block of Chamelium](../block/chameliumBlock.md).
|
||||
|
||||
As the tooltip says, eating it can have severe side-effects, so consume with care. Or better yet, don't.
|
||||
As the tooltip says, eating it can cause adverse side-effects, so consume with care. Or better yet, don't.
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
Microchips are the bread and butter of electronic component crafting. They come in different tiers, for the different tier of devices they're used to craft with.
|
||||
Microchips are the bread and butter of electronic component crafting. They come in different tiers, for crafting different tiers of components.
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The chunk loader upgrade can be installed in devices to allow them to keep the chunk they are in - as well as the surrounding chunks - loaded. This consumes quite a bit of energy, however. The chunk loader can be turned on and off using the component exposed to the device.
|
||||
The chunk loader upgrade can be installed in devices (such as [robots](../block/robot.md) and [microcontrollers](../block/microcontroller.md)) to allow them to keep the chunk they are in - as well as the surrounding chunks - loaded. This consumes energy, however. The chunk loader can be turned on and off using the component API exposed to the device.
|
||||
|
||||
The upgrade is automatically enabled when the device powers up, and automatically disabled when the device powers down.
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
Intermediary crafting item made from [raw circuit boards](rawCircuitBoard.md) and used to make [printed circuit boards](printedCircuitBoard.md).
|
||||
Intermediate crafting item made from [raw circuit boards](rawCircuitBoard.md) and used to make [printed circuit boards](printedCircuitBoard.md).
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
|
||||
|
||||
A component bus is a [server](server1.md)-specific upgrade that allows the server to communicate with more components at the same time, without shutting down. Like with [CPUs](cpu1.md), higher tier buses provide higher component limits. Higher tier [servers](server1.md) are also capable of taking more component buses, allowing for communication with many more components.
|
||||
A component bus is a [server](server1.md)-specific upgrade that allows the [server](server1.md) to communicate with more components at the same time, without shutting down. Like with [CPUs](cpu1.md), higher tier buses provide higher component limits. Higher tier [servers](server1.md) are also capable of taking more component buses, allowing for communication with many more components.
|
||||
|
||||
The number of components each component bus allows access to is as follows:
|
||||
- Tier 1: 8 components.
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
Higher tier crafting material used in more advanced circuitry, such as [CPUs](cpu1.md).
|
||||
Higher tier crafting item used in more advanced circuitry, such as [CPUs](cpu1.md).
|
||||
|
||||
@ -2,13 +2,13 @@
|
||||
|
||||
|
||||
|
||||
The central processing unit is a core part for each [computer](../general/computer.md) or [server](server1.md). It defines the architecture of the computer, and the number of components that can be connected to the computer before it stops working. Higher tier CPUs also provide a higher per-tick direct call limit to the computer - in simpler terms: better CPUs run faster.
|
||||
The central processing unit is a core part for each [computer](../general/computer.md) or [server](server1.md). It defines the architecture of the [computer](../general/computer.md), and the number of components that can be connected to the [computer](../general/computer.md) before it stops working. Higher tier CPUs also provide a higher per-tick direct call limit to the [computer](../general/computer.md) - in simpler terms: better CPUs run faster.
|
||||
|
||||
The number of components that the CPU allows access to is as follows:
|
||||
- Tier 1: 8 components.
|
||||
- Tier 2: 12 components.
|
||||
- Tier 3: 16 components.
|
||||
|
||||
In servers, the number of supported components can be further increased by installing [component buses](componentBus1.md).
|
||||
In [servers](server1.md), the number of supported components can be further increased by installing [component buses](componentBus1.md).
|
||||
|
||||
If more than the supported number of components are connected to a computer, it will no longer be able to start, and if it was running, it will crash.
|
||||
If more than the supported number of components are connected to a [computer](../general/computer.md), it will no longer be able to start, and if it was running, it will crash.
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
The crafting upgrade allows [robots](../block/robot.md) to craft shaped and shapeless recipes using items in their [inventory](../item/inventoryUpgrade.md). When crafting, the top-left three by three grid in the [robot](../block/robot.md)'s [inventory](../item/inventoryUpgrade.md) is used as the crafting grid. Items have to be located as they would be in a normal crafting table. Results will be placed back into the [robot](../block/robot.md)'s [inventory](../item/inventoryUpgrade.md). As with picking up items, the result will be placed into the selected slot; failing to do so will place the item in the next available empty slot. If no inventory space remains, the result will be dropped into the world.
|
||||
The crafting upgrade allows [robots](../block/robot.md) to craft shaped and shapeless recipes using items in their [inventory](../item/inventoryUpgrade.md). When crafting, the top-left 3x3 grid in the [robot](../block/robot.md)'s [inventory](../item/inventoryUpgrade.md) is used as the crafting grid. Items have to be arranged according to the recipe. Results will be placed back into the [robot](../block/robot.md)'s [inventory](../item/inventoryUpgrade.md). As with picking up items, the result will be placed into the selected slot; failing to do so will place the item in the next available empty slot. If no inventory space remains, the result will be dropped into the world.
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
You'll usually only encounter this when playing with the hard mode recipe set. In that case, this is used for crafting [raw circuit boards](rawCircuitBoard.md). Very inefficiently.
|
||||
An item encountered when using hard-mode recipes, it is used for crafting [raw circuit boards](rawCircuitBoard.md). Very inefficiently.
|
||||
|
||||
@ -4,6 +4,6 @@
|
||||
|
||||
The database upgrade can be configured to store a list of item stack representations, which can then be used by other components. This is particularly useful for items that are differentiated purely based on their NBT data, which is not part of the item stack descriptor returned by callbacks.
|
||||
|
||||
To configure a database, open it by right-clicking it while holding it in your hand, then placing the stacks you wish to configure it with into the top inventory. This will store a "ghost stack", i.e. no "real" items are stored in the database.
|
||||
To configure a database, open it by right-clicking with the database in hand. Place the stacks you wish to configure it with into the top inventory. This will store a "ghost stack", i.e. no "real" items are stored in the database.
|
||||
|
||||
Alternatively the database can be configured automatically using [inventory controllers](inventoryControllerUpgrade.md) and [geolyzers](../block/geolyzer.md).
|
||||
Alternatively the database can be configured automatically using the component API provided by [inventory controllers](inventoryControllerUpgrade.md) and [geolyzers](../block/geolyzer.md).
|
||||
|
||||
@ -4,4 +4,4 @@
|
||||
|
||||
The debug card is a creative-only item that was originally only intended to make debugging things easier, by automating some processes. It has since gotten a bunch more functionality, making it quite useful for custom map-making.
|
||||
|
||||
Note that you can use sneak-activate while holding the card to bind it to you / unbind it, meaning `runCommand` will be performed using your permission levels instead of the default OpenComputers ones.
|
||||
Note that you can use sneak-activate while holding the card to bind it to you or unbind it, meaning `runCommand` will be performed using your permission levels instead of the default OpenComputers ones.
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
Drones are built using a [drone case](droneCase1.md) in the [assembler](../block/assembler.md). They are entity-based [robots](../block/robot.md), a little cheaper with limited functionality. They are also capable of moving differently and much quicker than robots, and are usually controlled using a client program on a computer. The drone will need a configured [EEPROM](eeprom.md) to listen for commands to be executed or act on its own.
|
||||
Drones are built using a [drone case](droneCase1.md) in the [assembler](../block/assembler.md). They are entity-based [robots](../block/robot.md), a little cheaper with limited functionality. They are also capable of moving differently and much quicker than [robots](../block/robot.md), and are usually controlled using a client program on a [computer](../general/computer.md). The drone will need a configured [EEPROM](eeprom.md) to listen for commands to be executed or act on its own.
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
|
||||
|
||||
|
||||
The drone case is used to build [drones](drone.md) in the [assembler](../block/assembler.md). Drones are light-weight, fast and very mobile machines with limited functionality (fewer upgrade and component slots available). Unlike [robots](../block/robot.md) they cannot use tools, and can interact with the world only in a relatively limited manner.
|
||||
The drone case is used to build [drones](drone.md) in the [assembler](../block/assembler.md). [Drones](drone.md) are light-weight, fast and very mobile machines with limited functionality (fewer upgrade and component slots available). Unlike [robots](../block/robot.md) they cannot use tools, and can interact with the world only in a relatively limited manner.
|
||||
|
||||
They make up for their limitations with speed and lower running energy costs. They are well suited for transport of small amounts of items, and ideal for reconnaissance. Pairing a drone with a robot can be quite powerful, with the robot doing the "hard work", and the drone providing information about the environment and transporting items to and from a central hub, for example.
|
||||
They make up for their limitations with speed and lower running energy costs. They are well suited for transport of small amounts of items, and ideal for reconnaissance. Pairing a [drone](drone.md) with a [robot](../block/robot.md) can be quite powerful, with the [robot](../block/robot.md) doing the "hard work", and the [drone](drone.md) providing information about the environment and transporting items to and from a central hub, for example.
|
||||
|
||||
Like [microcontrollers](../block/microcontroller.md), Drones can only be programmed using their [EEPROM](eeprom.md). Accordingly, the [EEPROM](eeprom.md) can be changed by crafting the drone with another [EEPROM](eeprom.md).
|
||||
Like [microcontrollers](../block/microcontroller.md), [drones](drone.md) can only be programmed using their [EEPROM](eeprom.md). Accordingly, the [EEPROM](eeprom.md) can be changed by crafting the [drone](drone.md) with another [EEPROM](eeprom.md); the existing [EEPROM](eeprom.md) is return to the player's inventory.
|
||||
|
||||
The tier 1 drone case is capable of taking the following components:
|
||||
- 1x tier 1 [CPU](cpu1.md)
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
The floppy disk is the cheapest and smallest type of storage medium in OpenComputers. It is a handy early game way of storing data and transferring it between [computers](../general/computer.md) and [robots](../block/robot.md). You may also find floppy disks with useful programs on them in dungeon chests (OpenPrograms Package Manager is a good example, allowing easy install of programs from a central GitHub repository).
|
||||
The floppy disk is the cheapest and smallest type of storage medium in OpenComputers. It is a handy early-game way of storing data and transferring it between [computers](../general/computer.md) and [robots](../block/robot.md). You may also find floppy disks with useful programs on them in dungeon chests (OpenPrograms Package Manager is a good example, allowing easy install of programs from a central GitHub repository).
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The generator upgrade allows devices to refuel on the go. Currently it only supports solid fuels, such as coal. It has an internal inventory that can store one item stack of fuel. Surplus fuel can be removed from the generator using the according API method. When removing a generator upgrade from a robot, its contents will be dropped into the world.
|
||||
The generator upgrade allows devices to re-fuel on the go. Currently it only supports solid fuels, such as coal. It has an internal inventory that can store one item stack of fuel. Surplus fuel can be removed from the generator using the appropriate component API method. When removing a generator upgrade from a [robot](../block/robot.md), its contents will be dropped into the world.
|
||||
|
||||
The efficiency of generators is lower than that of usual generators of other mods, meaning it is usually more fuel efficient to power devices using a [charger](../block/charger.md).
|
||||
The efficiency of generators is lower than that of usual generators from other mods, meaning it is usually more fuel efficient to power devices using a [charger](../block/charger.md).
|
||||
|
||||
@ -4,4 +4,4 @@
|
||||
|
||||
The graphics card is an essential part for most [computers](../general/computer.md) and allows the [computer](../general/computer.md) to display text on a connected [screen](../block/screen1.md). Graphics cards come in several tiers, and like [screens](../block/screen1.md), support different resolutions and color depths.
|
||||
|
||||
Another noteworthy difference for the different graphics card tiers is the number of operations a graphics card can perform per tick. The values listed in the graphics cards' tooltip is representative for a [computer](../general/computer.md) with a tier two [CPU](cpu1.md). Tier one CPUs perform slightly slower, tier three CPUs slightly faster. The numbers listed are for the different operations provided by a GPU: `copy`, `fill`, `set`, `setBackground` and `setForeground`, respectively.
|
||||
Another noteworthy difference for the different graphics card tiers is the number of operations a graphics card can perform per tick. The values listed in the graphics cards' tooltips are representative for a [computer](../general/computer.md) with a tier two [CPU](cpu1.md). Tier one CPUs perform slightly slower, tier three CPUs slightly faster. The numbers listed are for the different operations provided by a GPU: `copy`, `fill`, `set`, `setBackground` and `setForeground`, respectively.
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
The hard disk drives are the higher tier storage medium in OpenComputers. There are no speed differences in the storage media provided by OpenComputers, they only differ in the amount of disk space they provide. There are also some devices that can only use disk drives, no [floppies](floppy.md) (although servers could use an external [disk drive](../block/diskDrive.md), for example). Hard drives can be placed inside a [raid](../block/raid.md), allowing multiple drives to share the same file system.
|
||||
The hard disk drives are a higher tier storage medium in OpenComputers. All storage media perform at the same speed; higher tier storage provides more space. There are also some devices that can only use disk drives (although servers could use an external [disk drive](../block/diskDrive.md), for example). Hard drives can be placed inside a [raid](../block/raid.md), allowing multiple drives to share the same file system. Note that placing a hard drive in a [raid](../block/raid.md) wipes the drive of its contents.
|
||||
|
||||
@ -9,6 +9,7 @@ Keep in mind that some of these may not be available, depending on the recipe se
|
||||
* [Manual](manual.md)
|
||||
* [Remote Terminal](terminal.md)
|
||||
* [Texture Picker](texturePicker.md)
|
||||
* [Scrench](wrench.md)
|
||||
|
||||
## Devices
|
||||
* [Drone](drone.md)
|
||||
@ -18,7 +19,7 @@ Keep in mind that some of these may not be available, depending on the recipe se
|
||||
## Components
|
||||
|
||||
### Cards
|
||||
* [AbstractBusCard](abstractBusCard.md)
|
||||
* [AbstractBus Card](abstractBusCard.md)
|
||||
* [Debug Card](debugCard.md) (aka AMI)
|
||||
* [Graphics Card](graphicsCard1.md)
|
||||
* [Internet Card](internetCard.md)
|
||||
@ -60,8 +61,8 @@ Keep in mind that some of these may not be available, depending on the recipe se
|
||||
## Crafting
|
||||
* [Acid](acid.md)
|
||||
* [ALU](alu.md)
|
||||
* [ArrowKeys](arrowKeys.md)
|
||||
* [ButtonGroup](buttonGroup.md)
|
||||
* [Arrow Keys](arrowKeys.md)
|
||||
* [Button Group](buttonGroup.md)
|
||||
* [Card](card.md)
|
||||
* [Circuit Board](circuitBoard.md)
|
||||
* [Control Unit](controlUnit.md)
|
||||
@ -74,9 +75,9 @@ Keep in mind that some of these may not be available, depending on the recipe se
|
||||
* [Raw Circuit Board](rawCircuitBoard.md)
|
||||
* [Transistor](transistor.md)
|
||||
|
||||
# Assembling / Printing
|
||||
## Assembling / Printing
|
||||
* [Chamelium](chamelium.md)
|
||||
* [Drone Case](droneCase1.md)
|
||||
* [Ink Cartridge](inkCartridge.md)
|
||||
* [Drone Case](droneCase1.md)
|
||||
* [Microcontroller Case](microcontrollerCase1.md)
|
||||
* [Tablet Case](tabletCase1.md)
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
Ink cartridges come in handy when refilling the color buffer of [3D printers](../block/printer.md). While it is also possible to refill them using dyes directly, this is messy and very inefficient, so it is strongly recommended to invest into a real OC Ink Cartridge (TM), today!
|
||||
Ink cartridges come in handy when refilling the color buffer of [3D printers](../block/printer.md). While it is also possible to refill them using dyes directly, this is messy and very inefficient. It is strongly recommended to invest into a real OC Ink Cartridge (TM), today! (Disclaimer: they may or may cost more than the printer itself).
|
||||
|
||||
@ -4,4 +4,4 @@
|
||||
|
||||
The internet card grants [computers](../general/computer.md) access to the internet. It provides ways to perform simple HTTP requests, as well as to open plain TCP client sockets that can be read and written to.
|
||||
|
||||
Installing an internet card in a [computers](../general/computer.md) will also attach a custom file system that contains a few internet related applications, such as one for downloading and uploading snippets from and to pastebin as well as a wannabe `wget` clone that allows downloading data from arbitrary HTTP URLs.
|
||||
Installing an internet card in a [computers](../general/computer.md) will also attach a custom file system that contains a few internet related applications, such as one for downloading and uploading snippets from/to pastebin as well as a `wget` clone that allows downloading data from arbitrary HTTP URLs.
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The inventory controller upgrade provides extended inventory interaction to [robots](../block/robot.md) and [drones](drone.md). It allows the device to explicitly target slots in external inventories when dropping or sucking items. It also allows devices to read detailed information about item stacks. Lastly it provides robots with a means to change their equipped tool without external help.
|
||||
The inventory controller upgrade provides extended inventory interaction to [robots](../block/robot.md) and [drones](drone.md). It allows the device to explicitly target slots in external inventories when dropping or sucking items. It also allows devices to read detailed information about item stacks. Lastly it provides [robots](../block/robot.md) with a means to change their equipped tool without external help.
|
||||
|
||||
This upgrade can also be placed in [adapters](../block/adapter.md), where it provides similar inspection methods for inventories adjacent to the adapter as it does to the robot. It does not allow the adapter to move items into or out of inventories, however. This feature is only available in [robots](../block/robot.md) and [drones](drone.md).
|
||||
This upgrade can also be placed in [adapters](../block/adapter.md), where it provides similar inspection methods for inventories adjacent to the [adapter](../block/adapter.md) as it does to the [robot](../block/robot.md). It does not allow the [adapter](../block/adapter.md) to move items into or out of inventories, however. This feature is only available to [robots](../block/robot.md) and [drones](drone.md).
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The inventory upgrade provides inventory slots to [robots](../block/robot.md) and [drones](drone.md). For each inventory upgrade a robot will gain an addition 16 inventory slots, up to a maximum of 64 slots in total; a drone will gain 4 slots per upgrade, up to a maximum of 8 slots in total.
|
||||
The inventory upgrade provides inventory slots to [robots](../block/robot.md) and [drones](drone.md). For each inventory upgrade a [robot](../block/robot.md) will gain an addition 16 inventory slots, up to a maximum of 64 slots in total; a [drone](drone.md) will gain 4 slots per upgrade, up to a total of 8 slots.
|
||||
|
||||
If no inventory upgrade is installed in a device it will not be able to store or pick up items.
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
The network card allows computers to send and receive network messages. Such messages (or packets) can be either sent as a broadcast, in which case they will be sent to all nodes in the same subnetwork, or sent to specific target, in which case they will only be received by the node with the specified target address. [Switches](../block/switch.md) and [access points](../block/accessPoint.md) can be used to bridge multiple subnetworks by relaying messages between the subnetworks they are connected to. It is also possible to send a targeted message if the receiver is in another subnetwork, if the networks are connected via one or more [switches](../block/switch.md).
|
||||
The network card allows [computers](../general/computer.md) to send and receive network messages. Messages (or packets) can be broadcasted to all receiving nodes in a subnetwork, or sent to a specific node with a specified address. [Switches](../block/switch.md) and [access points](../block/accessPoint.md) can be used to bridge multiple subnetworks by relaying messages between the subnetworks they are connected to. It is also possible to send a targeted message if the receiver is in another subnetwork, if the networks are connected via one or more [switches](../block/switch.md).
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
The linked card is a specialized but advanced version of a [network card](lanCard.md). It can only operate in pairs, providing a point-to-point communication between the paired cards. In return, the distance the cards can communicate over is unlimited. They can even communicate across dimensions.
|
||||
The linked card is a specialized but advanced version of a [network card](lanCard.md). It can only operate in pairs, providing a point-to-point communication between the paired cards. Linked cards can communicate over large (unlimited) distances and across dimensions.
|
||||
@ -8,6 +8,8 @@ The thing you're reading right now! The manual contains a wealth of information
|
||||
|
||||
Navigating the manual is similar to browsing a wiki: click on links (1) to follow them to the page they reference. Right-click or press the jump key to go back one page. Press escape or the inventory key to close the manual. To the left you will find a few tabs (2) that provide a way to quickly jump to select pages, such as the block and item index. To the right you will find the scroll bar (3). You can either drag it manually, or use the mouse wheel to scroll in a page.
|
||||
|
||||
When opening the manual again at a later point, you will return to the page you were on when you closed it. You can start over on the main index page by using it while sneaking. It is also possible to directly jump to a page concerning a block in the world by using the block while sneaking with the manual in hand.
|
||||
The manual will remember the page where you last left off, when re-opening it. You can start over on the main index page by using it while sneaking. It is also possible to directly jump to a page concerning a block in the world by shift-right clicking the block with the manual in hand.
|
||||
|
||||
If your questions are not answered by the manual, other places with information are the [wiki](http://ocdoc.cil.li), OpenComputers' [IRC channel](http://webchat.esper.net/?channels=#oc) and the [forums](http://oc.cil.li/).
|
||||
If your questions are not answered by the manual, other places with information are [the wiki](http://ocdoc.cil.li), OpenComputers' [IRC channel](http://webchat.esper.net/?channels=#oc) and [the forums](http://oc.cil.li/).
|
||||
|
||||
If you spot any mistakes in the manual, factual, grammatical or otherwise; or bugs in the mod, for that matter, please let us know [via the issue tracker](https://github.com/MightyPirates/OpenComputers/issues). If you'd like to contribute to the manual by adding content, get in touch via IRC or by creating a ticket on the issue tracker.
|
||||
|
||||
@ -2,9 +2,9 @@
|
||||
|
||||
|
||||
|
||||
The microcontroller Case is the base part when building [microcontrollers](../block/microcontroller.md) in the [assembler](../block/assembler.md). Microcontrollers are very primitive computers. They may only contain a very limited number of components, and are intended to be used in very specific use-cases, such as transforming or reacting to redstone signals, or processing network messages.
|
||||
The Microcontroller case is the base part when building [microcontrollers](../block/microcontroller.md) in the [assembler](../block/assembler.md). [Microcontrollers](../block/microcontroller.md) are very primitive [computers](../general/computer.md). They may only contain a very limited number of components, and are intended to be used in very specific use-cases, such as transforming or reacting to redstone signals, or processing network messages.
|
||||
|
||||
They do not have an actual file system. All programming must be done using the [EEPROM](eeprom.md) chip built into them. This chip can be swapped for another one by crafting a microcontroller with the chip to insert. The old [EEPROM](eeprom.md) will be returned to your inventory.
|
||||
They do not have an actual file system. All programming must be done using the [EEPROM](eeprom.md) chip built into them. This chip can be swapped for another one by crafting a [microcontrollers](../block/microcontroller.md) with the chip to insert. The old [EEPROM](eeprom.md) will be returned to your inventory.
|
||||
|
||||
While they also require power to run, they consume very little energy.
|
||||
|
||||
|
||||
@ -4,4 +4,4 @@
|
||||
|
||||
The navigation upgrade provides location and orientation information to devices it is installed in. The coordinates the upgrade provides are relative to the center of the map that was used to craft the upgrade, and the functional range is based on the size of that map.
|
||||
|
||||
Navigation upgrades can be re-crafted with a map to replace the map in the upgrade with another one. The old map will be returned.
|
||||
The map inside a Navigation upgrade can be changed by re-crafting the upgrade with a new map. The old map will be returned to the player.
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
The numeric keypad is part of every [keyboard](../block/keyboard.md). I allows you to enter numbers. I'm seriously running out of ideas of what to write here...
|
||||
The Numeric keypad is part of every [keyboard](../block/keyboard.md). It allows you to enter numbers.
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The piston upgrade allows some devices to act very much like a vanilla piston. When installed, a component with a single method, `push()`, becomes available. When called the device will then try to push the block in its forward facing direction. For example, for [robots](../block/robot.md) this is their facing, for [tablets](tablet.md) it's the player's facing, for [microcontrollers](../block/microcontroller.md) it is their facing.
|
||||
The piston upgrade allows some devices to act very much like a vanilla piston. When installed, a component with a single method, `push()`, becomes available. When called the device will then try to push the block in its forward facing direction. For [robots](../block/robot.md) and [microcontrollers](../block/microcontroller.md), this is the front face; for [tablets](tablet.md), it will use the player's facing direction.
|
||||
|
||||
The logic for pushing follows the same rules as vanilla pistons.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
|
||||
|
||||
Memory is, like the [CPU](cpu1.md), an essential part in all [computers](../general/computer.md). Depending on the CPU's architecture, the memory has a very essential effect on what a computer can and cannot do. For the standard Lua architecture, for example, it controls the actual amount of memory Lua scripts can use. This means that to run larger and more memory-intensive programs, you will need more RAM.
|
||||
Memory is, like the [CPU](cpu1.md), an essential part in all [computers](../general/computer.md). Depending on the [CPU](cpu1.md)'s architecture, the memory has a very essential effect on what a [computer](../general/computer.md) can and cannot do. For the standard Lua architecture, for example, it controls the actual amount of memory Lua scripts can use. This means that to run larger and more memory-intensive programs, you will need more memory.
|
||||
|
||||
RAM is available in multiple tiers with the following capacities, by default:
|
||||
- Tier 1: 192KB
|
||||
@ -12,6 +12,6 @@ RAM is available in multiple tiers with the following capacities, by default:
|
||||
- Tier 3: 768KB
|
||||
- Tier 3.5: 1024KB
|
||||
|
||||
Note that these values only apply to the Lua architecture. Other architectures may provide different amounts of memory for the different tiers.
|
||||
Note that these values only apply to the Lua architecture. Other architectures may provide different amounts of memory for the different tiers. Also note that tier 1 and 1.5 memory are both considered tier 1 memory, and similarly for tier 2 and 3 memory.
|
||||
|
||||
The values can be changed in the configuration, if so desired.
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
Intermediary crafting material, used for crafting [circuit boards](circuitBoard.md) (or [printed circuit boards](printedCircuitBoard.md), depending on the recipe set you use).
|
||||
Intermediary crafting material, used for crafting [circuit boards](circuitBoard.md) (or [printed circuit boards](printedCircuitBoard.md), depending on the recipe set being used).
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
|
||||
|
||||
|
||||
The redstone card allows computers to read and emit analog redstone signal in adjacent blocks. When an incoming signal strength changes, a signal is injected into the computer.
|
||||
The redstone card allows [computers](../general/computer.md) to read and emit analog redstone signal in adjacent blocks. When an incoming signal strength changes, a signal is injected into the [computer](../general/computer.md).
|
||||
|
||||
If there are any supported mods present that provide bundled redstone facilities, such as RedLogic, Project Red or MineFactory Reloaded, or mods that provide wireless redstone facilities such as WR-CBE and Slimevoid's Wireless mod, a second tier card is available that allows interacting with these systems.
|
||||
If there are any supported mods present that provide bundled redstone facilities, such as RedLogic, Project Red or MineFactory Reloaded; or mods that provide wireless redstone facilities such as WR-CBE and Slimevoid's Wireless mod, a second tier card is available that allows interacting with these systems.
|
||||
|
||||
The side provided to the several methods are relative to the orientation of the [computer case](../block/case1.md) / [robot](../block/robot.md) / [server rack](../block/serverRack.md). That means when looking at the front of the computer, `sides.right` is at your left and vice versa.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
|
||||
|
||||
Servers are a form of higher tier [computer](../general/computer.md). They can be configured by holding them in the hand and using them - like opening a backpack or ender pouch, for example. After inserting a [CPU](cpu1.md), [memory](ram1.md) and Expansion cards, the server has to be placed inside a [server rack](../block/serverRack.md). For more information see the server rack entry.
|
||||
Servers are a form of higher tier [computer](../general/computer.md). They can be configured by holding them in the hand and using them - like opening a backpack or Ender pouch, for example. After inserting a [CPU](cpu1.md), [memory](ram1.md) and Expansion cards, the server has to be placed inside a [server rack](../block/serverRack.md). For more information see the [server rack](../block/serverRack.md) entry.
|
||||
|
||||
The tier 1 server is capable of taking the following components:
|
||||
- 1x tier 2 [CPU](cpu2.md)
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
This upgrade allows devices to interact with signs in the world. It allows reading the message currently being displayed on a sign, as well as setting that message to something else (unless some permission system blocks it).
|
||||
This upgrade allows devices to interact with signs in the world. It allows reading the current message on the sign as well as changing the message on the sign (if permitted.
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The solar generator upgrade can be installed in devices such as [robots](../block/robot.md), [drones](drone.md) and [tablets](tablet.md) to passively generate energy. It will only work while the device is standing in the sun, i.e. it is day and there is no block between the device and the sky above it.
|
||||
The solar generator upgrade can be installed in devices such as [robots](../block/robot.md), [drones](drone.md) and [tablets](tablet.md) to passively generate energy. It will only work while the device is exposed to direct sunlight; a device in an enclosed area or an area affected by weather will not generate energy.
|
||||
|
||||
The amount of energy generated is relatively small, but it should be enough to prolong the time needed between recharges, if not avoid them altogether.
|
||||
The amount of energy generated is relatively small, but it should be enough to prolong the time needed between [recharges](../block/charger.md), if not avoid them altogether.
|
||||
|
||||
@ -4,6 +4,10 @@
|
||||
|
||||
Tablets are built by placing a [tablet case](tabletCase1.md) into an [assembler](../block/assembler.md), configuring as desired and assembling it. Tablets act as portable computers that cannot directly interact with the world - for example, basic [redstone cards](redstoneCard1.md) do not work in them. A number of upgrades do, such as the [sign i/o](signUpgrade.md) upgrade or the [piston](pistonUpgrade.md) upgrade.
|
||||
|
||||
To force rebooting a tablet, sneak-activate it while holding it in your hand. Unlike computers, tablets do not persist across the player holding it leaving and re-entering the game. They also do not persist across the player holding the tablet changing dimensions (e.g. going to the Nether or back).
|
||||
The tier 2 tablet also allows installing a single container upgrade. The slot provided by the container can be accessed by opening the tablet's alternative GUI, by shift-right clicking with the tablet in hand. This will also forcibly shut down the tablet.
|
||||
|
||||
Tablets can be put into a [charger](../block/charger.md) to refill their energy, and to access the first [hard drive](hdd1.md) built into the tablet from a [computer](../general/computer.md) connected to the charger - in this setup, the charger will act similar to a [disk drive](../block/diskDrive.md), with the tablet being the [floppy disk](floppy.md). This can be very useful in case you forgot to install an OS on the hard drive built into the tablet, or after bricking a tablet's OS.
|
||||
Unlike computers, tablets do not persist across the player holding it leaving and re-entering the game. They also do not persist across dimensions (such as a player going to the Nether and back).
|
||||
|
||||
Tablets can be put into a [charger](../block/charger.md) to refill their energy, and to access the first [hard drive](hdd1.md) in the tablet from a [computer](../general/computer.md) connected to the charger - in this setup, the charger will behave similar to a [disk drive](../block/diskDrive.md), with the tablet being the [floppy disk](floppy.md). This can be very useful in case you forgot to install an OS on the hard drive built into the tablet, or after bricking a tablet's OS.
|
||||
|
||||
Another advanced feature of the tablet is its ability to generate signals with information about certain blocks in the world, by using it on a block in the world for about one second (e.g. keep the right mouse button pressed). A short beep tone will notify you that the signal was generated. This only works if upgrades are installed in the tablet that populate the signal with information. For example, the [geolyzer](../block/geolyzer.md) will add information about the block itself, such as its hardness, the [navigation upgrade](navigationUpgrade.md) will add the coordinates of the block relative to the player holding the tablet. The block to be analyzed will be highlighted with a green overlay while holding the tablet.
|
||||
@ -2,11 +2,11 @@
|
||||
|
||||
|
||||
|
||||
The tablet case is the base part when building [tablets](tablet.md) in the [assembler](../block/assembler.md). Tablets are very compact and portable computers. They can host a small number of select upgrades, but obviously cannot interact with the world like [computer cases](../block/case1.md) can (using simple [network cards](lanCard.md) or [redstone cards](redstoneCard1.md) for example).
|
||||
The tablet case is the base part when building [tablets](tablet.md) in the [assembler](../block/assembler.md). [Tablets](tablet.md) are very compact and portable [computers](../general/computer.md). They can host a small number of select upgrades, but cannot interact with the world like [computer cases](../block/case1.md) can (using simple [network cards](lanCard.md) or [redstone cards](redstoneCard1.md) for example).
|
||||
|
||||
Upgrades and cards that cannot be used in tablets can generally not be placed into the assembler, so if you can install an upgrade, you can usually assume that you will also be able to use it.
|
||||
Upgrades and cards that cannot be used in [tablets](tablet.md) cannot be placed in the [assembler](../block/assembler.md). If an upgrade can be placed in the [assembler](../block/assembler.md), it will be available for use through the component API.
|
||||
|
||||
They must also remain in a player's inventory to continue running. When dropped or placed into some other inventory, they will turn off after a short amount of time.
|
||||
They must also remain in a player's inventory to continue running. When dropped or placed into another inventory, they will turn off after a short amount of time.
|
||||
|
||||
The tier 1 tablet case can hold the following components:
|
||||
- 1x [CPU (tier 2)](cpu2.md)
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
|
||||
|
||||
The remote terminal can be used to remote control [servers](server1.md). To use it, sneak-activate a server that is installed in a [server rack](../block/serverRack.md) (click on the [server rack](../block/serverRack.md) block in the world, targeting the [server](server1.md) to bind the terminal to).
|
||||
The remote terminal can be used to remotely control [servers](server1.md). To use it, sneak-activate a server that is installed in a [server rack](../block/serverRack.md) (click on the [server rack](../block/serverRack.md) block in the world, targeting the [server](server1.md) to bind the terminal to).
|
||||
|
||||
When a terminal is bound to a [server](server1.md), a virtual [screen](../block/screen1.md) and [keyboard](../block/keyboard.md) get connected to the server. This can lead to unexpected behavior if another real screen and/or keyboard is connected to the server, so this should be avoided. When using the terminal in hand after binding it, a GUI will open in the same manner as a [keyboard](../block/keyboard.md) attached to a [screen](../block/screen1.md).
|
||||
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The texture picker is very useful when you're making models for your [3D printer](../block/printer.md). It allows getting the texture name of textures used by blocks in the world, simply by (sneak-)activate them with the tool. Disclaimer: for blocks that use special rendering, such as chests, this may not work.
|
||||
The texture picker is very useful when making models for your [3D printer](../block/printer.md). It allows getting the texture name of textures used by blocks in the world, simply by (sneak-)activating them with the tool. Disclaimer: for blocks that use special rendering, such as chests, this may not work.
|
||||
|
||||
While this is handy for quickly looking up texture names, it is good to know that you are not limited to the textures that can be picked with the analyzer. As long as you know the name of a texture (and it is a *block* texture), you can use it in your [3D prints](../block/print.md).
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
The upgrade container is a container type upgrade for [robots](../block/robot.md), that provides a slot in the finished [robots](../block/robot.md) into which normal upgrades can be placed. The tier of upgrade that slot can hold is equal to the tier of the container. Unlike normal upgrades, the complexity of containers is twice their tier. Refer to [robot](../block/robot.md) documentation on complexity.
|
||||
The upgrade container is a container type upgrade for [robots](../block/robot.md), that provides a slot in the finished [robots](../block/robot.md) into which normal upgrades can be placed. The maximum tier of upgrade that slot can hold is equal to the tier of the container. Unlike normal upgrades, the complexity of containers is twice their tier. Refer to [robot](../block/robot.md) and [assembler](../block/assembler.md) documentation on complexity.
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The wireless network card is an upgraded [network card](lanCard.md) that, in addition to wired network messages, can also send and receive wireless network messages. The signal strength directly controls the distance up to which a sent message can be received, where the strength is equal to that distance in blocks.
|
||||
The wireless network card is an upgraded [network card](lanCard.md) that, in addition to wired network messages, can also send and receive wireless network messages. The signal strength directly controls the distance up to which a sent message can be received, where the strength is equal to the distance in blocks.
|
||||
|
||||
The higher the signal strength, the more energy it will take to send a single message. The terrain between the sender and receiver also determines whether a message will be successfully transmitted or not. To penetrate a block, the blocks hardness is subtracted from the signal strength - with the minimum being one for air blocks. If no strength remains to reach the receiver, the message will not be received. This is not an exact science however - sometimes messages may still reach the target. In general you will want to make sure the line of sight between the sender and receiver are clear.
|
||||
The higher the signal strength, the more energy it will take to send a single message. The terrain between the sender and receiver also determines whether a message will be successfully transmitted or not. To penetrate a block, the blocks hardness is subtracted from the signal strength - with the minimum being one for air blocks. If no strength remains to reach the receiver, the message will not be received. This is not an exact science however - sometimes messages may still reach the target. In general you will want to make sure the line of sight between the sender and receiver is clear.
|
||||
|
||||
@ -0,0 +1,5 @@
|
||||
# Scrench
|
||||
|
||||
|
||||
|
||||
Like pretty much any other technology-focused mod, OpenComputers has it's own version of a wrench tool. In this case, it is a hybrid of a screwdriver and a wrench, that looks like it's incredibly awkward to use. It can be used to rotate most blocks, and is also compatible with most other mods' blocks that can be interacted with by using wrench-like tools.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 5.5 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.5 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 236 KiB |
@ -0,0 +1,11 @@
|
||||
# Точка доступа
|
||||
|
||||
|
||||
|
||||
Точки доступа, это беспроводные версии [коммутаторов](switch.md). Они могут быть использованы, когда требуется разделить подсети, чтобы устройства не видели [компоненты](../general/computer.md) в других сетях, однако сохраняя при этом возможность передачи сообщений между подсетями.
|
||||
|
||||
В дополнение к этому, точки доступа могут использоваться как повторители: они могут перенаправлять сообщения из проводной линии другим устройствам; или беспроводные сообщения как проводные, так и беспроводные.
|
||||
|
||||
Коммутаторы и [коммутаторы](switch.md) *не* отслеживают, какие пакеты и куда они передали, поэтому в сети могут образовываться петли или вы можете получать одно сообщение несколько раз. Из-за ограниченного буфера сообщений коммутатора, частое отправление сообщений приводит к их потере. Вы можете улучшить [коммутатор](switch.md) или точку доступа для увеличения скорости обработки сообщений, а также увеличения размера сообщений.
|
||||
|
||||
Сообщения, могут перенаправлены всего несколько раз, поэтому цепочки с произвольным количеством коммутаторов или точек доступа невозможны. По умолчанию, сообщение может быть перенаправлено пять раз.
|
||||
@ -0,0 +1,7 @@
|
||||
# Адаптер
|
||||
|
||||
|
||||
|
||||
Адаптеры позволяют [компьютерам](../general/computer.md) взаимодействовать с блоками Minecraft и блоками из других модов. Поддерживаемые блоки, прилегающие к адаптеру, будут отображаться как компоненты [компьютера](../general/computer.md), подключенного к адаптеру.
|
||||
|
||||
В дополнение к этому, адаптеры добавляют слот для нескольких улучшений. Например, [контроллер инвентаря](../item/inventoryControllerUpgrade.md) позволяет компьютеру получать подробную информацию о предметах в инвентаре, для блока подключенного через адаптер, также это улучшение может быть установлено и в другие устройства (например [роботов](robot.md) или [дронов](../item/drone.md)), также [контроллер бака](../item/tankControllerUpgrade.md) предоставляет аналогичный функционал, только для жидкостей.
|
||||
@ -0,0 +1,13 @@
|
||||
# Сборщик роботов
|
||||
|
||||
|
||||
|
||||
Сборщик роботов, это продвинутая система, позволяющая собирать такие сложные устройства, как [роботы](robot.md), [дроны](../item/drone.md) и [планшеты](../item/tablet.md). Они требуют для сборки большое количество энергии, поэтому рекомендуется использовать их совместно с [конденсатором энергии](capacitor.md).
|
||||
|
||||
Для создания устройства с помощью сборщика, необходимо вставить корпус устройства. Для [роботов](robot.md) это [системный блок](case1.md) любого уровня; а для [планшетов](../item/tablet.md) это [корпус планшета](../item/tabletCase1.md). Также как в других устройствах OpenComputers, компоненты должны быть помещены в указанные слоты; при наведении курсора на компонент, подсвечивается слот, куда его можно вставить. Если у вас открыт NEI, со списком компонентов OpenComputers, совместимые компоненты также будут подсвечены в NEI. Вставьте все необходимые компоненты. Не забудьте про операционную систему или установите ее позже (для роботов вы можете вставить [дисковод](diskDrive.md) для чтения [дискет](../item/floppy.md)). Для большинства устройств их [EEPROM](../item/eeprom.md) может быть изменен после сборки, достаточно поместить устройство с новым [EEPROM](../item/eeprom.md) в верстаке. Старый [EEPROM](../item/eeprom.md) при этом будет возвращен вам в инвентарь.
|
||||
|
||||
Также [роботы](robot.md) могут иметь [монитор](screen1.md), для этого нужно установить в них [монитор первого уровня](screen1.md), а для возможности печатать на [мониторе](screen1.md), требуется установить [клавиатуру](keyboard.md). Для [планшетов](../item/tablet.md), [монитор](screen1.md) уже установлен в [корпус планшета](../item/tabletCase1.md), но вы должны установить [клавиатуру](keyboard.md) для возможности печатать на [планшете](../item/tablet.md).
|
||||
|
||||
После того, как вы поместили все нужные компоненты, нажмите кнопку старта и ожидайте, пока устройство будет собрано и заряжено. Также стоит заметить, что вы *не* сможете изменить устройство после разборки. Если вы что-то забыли или допустили ошибку, вам придется разобрать устройство в [разборщике](disassembler.md), при этом некоторые предметы имеют шанс поломаться.
|
||||
|
||||
О сложности: уровень предмета означает, пунктов сложности они будут занимать, компоненты уровня 1 занимают 1 пункт сложности, уровня 2, требуют 2 пункта, а уровня 3, 3 пункта. Улучшения - контейнеры, имеют двойную сложность (например: [контейнеры](../item/upgradeContainer1.md) уровня 2 требуют 4 пункта сложности, аналогично для [контейнера карт](../item/cardContainer1.md)).
|
||||
@ -0,0 +1,9 @@
|
||||
# Кабель
|
||||
|
||||
|
||||
|
||||
Кабель необходим для соединения [компьютеров](../general/computer.md) и машин, которые далеки друг от друга. Если вы используете компактную сборку, где все компоненты касаются друг друга (напрямую или нет, большинство блоков ведут себя как кабели), тогда вам не нужны кабели.
|
||||
|
||||
Кабели могут быть окрашены с помощью красок. Цветные кабели могут соединяться только с кабелями этого же цвета и светло-серого цвета - цветом по умолчанию. Это можно использовать для запуска кабелей в нескольких подсетей параллельно, без оболочки.
|
||||
|
||||
Если необходимо, кабели могут быть накрыты оболочкой из Forge MultiPart или Immibis Microblocks. Имейте ввиду, что [3D печать](print.md) совместима с Forge MultiPart, что делает возможным печать дополнительных оболочек.
|
||||
@ -0,0 +1,9 @@
|
||||
# Конденсатор энергии
|
||||
|
||||
|
||||
|
||||
Конденсатор энергии хранит энергию, используемую в сети, действуя в качестве буфера энергии, когда это необходимо. В отличие от конвертации энергии других модов во внутреннюю энергию OpenComputers (с помощью [конвертера энергии](powerConverter.md) например), передает энергию внутри одной подсети мгновенно. Наличие энергетического буфера можно использовать, когда необходимо большое количество энергии, например, в [сборщике роботов](assembler.md) и/или [зарядном устройстве](charger.md) для [роботов](robot.md) или [дронов](../item/drone.md).
|
||||
|
||||
Эффективность хранения возрастает с увеличением количества конденсаторов, находящихся рядом друг с другом или в непосредственной близости. Например, два конденсатора в непосредственной близости друг от друга, будут иметь большую емкость, чем 2 отдельно стоящих. Данный бонус распространяется на конденсаторы энергии, находящиеся в радиусе двух блоков относительно друг друга и уменьшается, с увеличением расстояния между ними.
|
||||
|
||||
Конденсатор может быть подключен к [распределителю энергии](powerDistributor.md) для передачи энергии другим [компьютерам](../general/computer.md) или машинам в сети.
|
||||
@ -0,0 +1,37 @@
|
||||
# Системный блок
|
||||
|
||||
|
||||
|
||||
Системные блоки имеют 3 различных уровня, различающихся количеством компонентов, которые могут быть в них вставлены. Также есть креативный системный блок. Системные блоки могут быть помещены в [сборщик роботов](assembler.md) для создания [робота](robot.md).
|
||||
|
||||
Максимальный уровень компонента, который может быть помещен в слот, указан в самом слоте с помощью цифры. Слот 2 уровня также может содержать компоненты 1 уровня.
|
||||
|
||||
Системный блок 1 уровня может содержать следующие компоненты:
|
||||
- 2x платы расширения уровня 1 (например [видеокарты](../item/graphicsCard1.md), [сетевые карты](../item/lanCard.md) и т.д.)
|
||||
- 1x [процессор](../item/cpu1.md) уровня 1
|
||||
- 2x [планки памяти](../item/ram1.md) уровня 1
|
||||
- 1x [жесткий диск](../item/hdd1.md) уровня 1
|
||||
|
||||
Системный блок 2 уровня может содержать следующие компоненты
|
||||
- 1x плату расширения уровня 1 (например [видеокарты](../item/graphicsCard1.md), [сетевые карты](../item/lanCard.md) и т.д.
|
||||
- 1x плату расширения уровня 2
|
||||
- 1x [процессор](../item/cpu2.md) уровня 2
|
||||
- 2x [планки памяти](../item/ram3.md) уровня 2
|
||||
- 1x [жесткий диск](../item/hdd1.md) уровня 1
|
||||
- 1x [жесткий диск](../item/hdd2.md) уровня 2
|
||||
|
||||
Системный блок 3 уровня может содержать следующие компоненты
|
||||
- 1x плату расширения уровня уровня 3 (например [видеокарты](../item/graphicsCard1.md), [сетевые карты](../item/lanCard.md) и т.д.)
|
||||
- 2x платы расширения уровня уровня 2
|
||||
- 1x [процессор](../item/cpu3.md) уровня 3
|
||||
- 2x [планки памяти](../item/ram5.md) уровня 3
|
||||
- 1x [жесткий диск](../item/hdd2.md) уровня 2
|
||||
- 1x [жесткий диск](../item/hdd3.md) уровня 3
|
||||
- 1x [дискету](../item/floppy.md)
|
||||
|
||||
Системный блок 4 уровня (креатив) может содержать следующие компоненты
|
||||
- 3x платы расширения уровня уровня 3 (например [видеокарты](../item/graphicsCard1.md), [сетевые карты](../item/lanCard.md) и т.д.)
|
||||
- 1x [процессор](../item/cpu3.md) уровня 3
|
||||
- 2x [планки памяти](../item/ram5.md) уровня 3
|
||||
- 2x [жестких диска](../item/hdd3.md) уровня 3
|
||||
- 1x [дискету](../item/floppy.md)
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user