mirror of
https://github.com/MightyPirates/OpenComputers.git
synced 2025-09-13 17:28:52 -04:00
Merge pull request #1036 from rashdanml/master-MC1.7.10
In-game documentation files
This commit is contained in:
Florian "Sangar" Nücke
commit
f28fd0dba4
@ -2,10 +2,10 @@
|
||||
|
||||
|
||||
|
||||
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, to 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 usually require a relatively large amount of energy to assemble these devices, so it is recommended to power them sufficiently.
|
||||
|
||||
To build a device using an assembler, first insert the base part for that device. For robots that is a computer case of any tier, for tablets that is a tablet case, 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, 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).
|
||||
|
||||
Also note that for robots 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 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.
|
||||
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).
|
||||
|
||||
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 §lcannot§r 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.
|
||||
|
||||
@ -6,4 +6,4 @@ The Cable simply serves as a way of connecting computers and machines that are f
|
||||
|
||||
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.
|
||||
|
||||
Speaking of which, cables can be covered using either Forge MultiPart covers or immibis Microblocks covers.
|
||||
If necessary, Cables can be covered using Forge MultiPart covers, or Immibis Microblocks covers.
|
||||
@ -2,6 +2,8 @@
|
||||
|
||||
|
||||
|
||||
The Capacitor has one job, storing a bunch of energy, either as a failsafe or for quick use. Unlike when converting energy from other mods' power systems to the internal energy format, transfer inside a single OC subnetwork is pretty much instantaneous, so it can be of advantage 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 OC's internal energy type (using a [power converter](powerConverter.md), transfering energy inside a single OC 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 storage efficiency of capacitors increases the more capacitors are in their direct and indirect 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, with slightly less of a bonus for capacitors two blocks away than for capacitors one block away.
|
||||
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.
|
||||
|
||||
The Capacitor can be connected to a [power distributor](powerDistributor.md) to provide power to other [computers](../general/computer.md) or machines on the network.
|
||||
@ -11,25 +11,25 @@ The tier 1 case can house up to and including the following components:
|
||||
- 1x tier 1 [HDD](../item/hdd1.md)
|
||||
|
||||
The tier 2 case can house up to and including the following components:
|
||||
- 1x tier 1 expansion card (such as [graphics cards](../item/graphicsCard1.md), [network cards](../item/lanCard.md), etc)
|
||||
- 1x tier 2 expansion card
|
||||
- 1x tier 2 [CPU](../item/cpu1.md)
|
||||
- 2x tier 2 [RAM](../item/ram1.md)
|
||||
- 1x tier 1 Expansion card (such as [graphics cards](../item/graphicsCard1.md), [network cards](../item/lanCard.md), etc)
|
||||
- 1x tier 2 Expansion card
|
||||
- 1x tier 2 [CPU](../item/cpu2.md)
|
||||
- 2x tier 2 [RAM](../item/ram3.md)
|
||||
- 1x tier 1 [HDD](../item/hdd1.md)
|
||||
- 1x tier 2 [HDD](../item/hdd1.md)
|
||||
- 1x tier 2 [HDD](../item/hdd2.md)
|
||||
|
||||
The tier 3 case can house up to and including the following components:
|
||||
- 1x tier 3 expansion card (such as [graphics cards](../item/graphicsCard1.md), [network cards](../item/lanCard.md), etc)
|
||||
- 2x tier 2 expansion card
|
||||
- 1x tier 3 [CPU](../item/cpu1.md)
|
||||
- 2x tier 3 [RAM](../item/ram1.md)
|
||||
- 1x tier 2 [HDD](../item/hdd1.md)
|
||||
- 1x tier 3 [HDD](../item/hdd1.md)
|
||||
- 1x tier 3 Expansion card (such as [graphics cards](../item/graphicsCard1.md), [network cards](../item/lanCard.md), etc)
|
||||
- 2x tier 2 Expansion card
|
||||
- 1x tier 3 [CPU](../item/cpu3.md)
|
||||
- 2x tier 3 [RAM](../item/ram5.md)
|
||||
- 1x tier 2 [HDD](../item/hdd2.md)
|
||||
- 1x tier 3 [HDD](../item/hdd3.md)
|
||||
- 1x [floppy disk](../item/floppy.md)
|
||||
|
||||
The tier 4 (Creative) case can house the following components:
|
||||
- 3x tier 3 expansion cards (such as [graphics cards](../item/graphicsCard1.md), [network cards](../item/lanCard.md), etc)
|
||||
- 1x tier 3 [CPU](../item/cpu1.md)
|
||||
- 2x tier 3 [RAM](../item/ram1.md)
|
||||
- 2x tier 3 [HDD](../item/hdd1.md)
|
||||
- 3x tier 3 Expansion cards (such as [graphics cards](../item/graphicsCard1.md), [network cards](../item/lanCard.md), etc)
|
||||
- 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)
|
||||
@ -6,4 +6,4 @@ The Charger is used to charge devices such as [robots](robot.md), [drones](../it
|
||||
|
||||
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.
|
||||
|
||||
When a tablet 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 copying data onto or from a tablet, if desired.
|
||||
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).
|
||||
|
||||
@ -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 decompose devices that are either no longer needed or built broken (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).
|
||||
|
||||
Disassembling items takes a relatively long time, and quite some energy. It also has a certain risk to destroy the reclaimed items - this chance is applied to each extracted item - so be sure to not carelessly throw things into the disassembler.
|
||||
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.
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The Disk Drive can be used to read [floppies](../item/floppy.md) using a computer connected to the disk drive. This is useful to get started, since the lower tier computer cases do not have a built-in floppy slot, and you'll need an operating system to get started - which usually only come on floppy disks (such the craftable OpenOS one).
|
||||
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.
|
||||
|
||||
It can also be installed in [robots](robot.md) to allow inserting an removing floppy disks into and from the robot at any time, which can be very useful, since the only other way to transfer data 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 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).
|
||||
|
||||
@ -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).
|
||||
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 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 excessivly may quickly drain a robot's batteries.
|
||||
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 excessivly may quickly drain a [robot](robot.md)'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 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. 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.
|
||||
|
||||
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 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.
|
||||
|
||||
@ -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 in the world, it has to be placed next to the screen, facing that screen, or placed directly on the screen (on top or on one of its sides). You can tell that a keyboard is "connected" to a screen if by right-clicking the keyboard the screen's 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 by right-clicking the keyboard the [screen's](../screen1.md) GUI opens up.
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The Motion Sensor allows computers to detect movement of living entities. If an entity moves faster than a set threshold, a signal will be injected into computers 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 via the component 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,7 @@
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
Power conversion rates are as follows:
|
||||
-
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
The Power Distributor is for energy what the [switch](switch.md) is for network messages. It allows 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,8 +2,8 @@
|
||||
|
||||
|
||||
|
||||
The Raid block houses three hard drives 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 and is available to all computers 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 disks are present. The disks may differ in size.
|
||||
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 to the raid block will wipe it of its contents. Removing a single disk 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 also wipe the raid. Adding the disk back in will *not* restore it, the raid's new file system will not contain any files.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
|
||||
|
||||
The Redstone I/O block can be used to remotely read and emit redstone signals. It behaves like a hybrid of a tier one and two [redstone card](../item/redstoneCard1.md), in that 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.
|
||||
|
||||
|
||||
@ -4,4 +4,6 @@
|
||||
|
||||
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.
|
||||
|
||||
Robots are built by placing a [computer case](case1.md) in an [assembler](assembler.md).
|
||||
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.
|
||||
|
||||
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](../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).
|
||||
|
||||
@ -2,10 +2,15 @@
|
||||
|
||||
|
||||
|
||||
A Screen is used in combination with a [graphics card](../item/graphicsCard1.md), to allow computers to display text. Different screen tiers have different capabilties, that being that they support different resolutions and color depths, ranging from very low resolution, monochrome displays, to very high resolutions with up to 256 different colors.
|
||||
A Screen is used in combination with a [graphics card](../item/graphicsCard1.md), to allow computers to display text. Different screen tiers have different capabilties, 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 weakest link. When using a tier one graphics card with a tier three screen, only the tier one 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.
|
||||
|
||||
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.
|
||||
|
||||
Tier two and tier three 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.
|
||||
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 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.
|
||||
@ -2,8 +2,8 @@
|
||||
|
||||
|
||||
|
||||
A Server Rack houses up to four [servers](../item/server.md). A server is a higher tier computer, which can only run when inside a server rack. Servers 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 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.
|
||||
|
||||
Each server 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 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, 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 in the rack, they will not be automatically relayed to the other faces of the rack. Servers 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. 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.
|
||||
|
||||
@ -4,8 +4,8 @@
|
||||
|
||||
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).
|
||||
|
||||
There is also a wireless variation of this block, 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.
|
||||
|
||||
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 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.
|
||||
|
||||
Packets are only re-sent a certain number of times, so chaining an arbitrary number of switches or access points is not possible.
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
This card allows [computers](../general/computer.md), [servers](server.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 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 @@
|
||||
|
||||
|
||||
|
||||
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 slot can hold is equal to the tier of the container. Unlike normal upgrades, the complexity of containers is twice their tier.
|
||||
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.
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The Chunkloader Upgrade can be installed in devices to allow them too keep the chunk they are in - as well as the surrounding chunks - loaded. This consumes quite a bit of energy, however. The chunkloader can be turned on and off using the component the upgrade exposes to the device.
|
||||
The Chunkloader 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 chunkloader can be turned on and off using the component 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,9 @@
|
||||
|
||||
|
||||
|
||||
A Component Bus is a [server](server.md)-specific upgrade that allows the server to communicate with more components at the same time, without shutting down. Like with [CPUs](cpu.md), higher tier buses provide higher component limits.
|
||||
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.
|
||||
|
||||
The number of components each component bus allows access to is as follows:
|
||||
- Tier 1: 8 components.
|
||||
- Tier 2: 12 components.
|
||||
- Tier 3: 16 components.
|
||||
@ -2,4 +2,9 @@
|
||||
|
||||
|
||||
|
||||
The Central Processing Unit is a core part for each computer. 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, 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 number of components that the CPU allows access to is as follows:
|
||||
- Tier 1: 8 components.
|
||||
- Tier 2: 12 components.
|
||||
- Tier 3: 16 components.
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
The Crafting Upgrade allows [robots](../block/robot.md) to craft shaped and shapeless recipes using items in their inventory. When crafting, the top-left three by three grid in the robot's inventory 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's inventory. As when picking up items, the result will preferrably placed into the selected slot, and failing so continue to search forwards until an empty slot is found. 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 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.
|
||||
|
||||
@ -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 but with more limited functionality.
|
||||
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 than robots, and are controlled using client program on a computer. The drone will need a configured [EEPROM](eeprom.md) to listen for commands to be executed.
|
||||
|
||||
@ -2,8 +2,33 @@
|
||||
|
||||
|
||||
|
||||
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. 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 are light-weight, fast and very mobile machines with limited functionality (fewer Upgrade and Componet 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.
|
||||
|
||||
Like [microcontrollers](../block/microcontroller.md), Drones can only be programmed using their [EEPROM](eeprom.md). Accordingly, the EEPROM can be changed by recrafting the Drone with another EEPROM.
|
||||
Like [microcontrollers](../block/microcontroller.md), Drones can only be programmed using their [EEPROM](eeprom.md). Accordingly, the [EEPROM](eeprom.md) can be changed by recrafting the Drone with another [EEPROM](eeprom.md).
|
||||
|
||||
The tier 1 Drone case is capable of taking the following components:
|
||||
- 1x tier 1 [CPU](cpu1.md)
|
||||
- 1x tier 1 [RAM](ram1.md)
|
||||
- 1x [EEPROM](eeprom.md)
|
||||
- 1x Expansion card (tier 2)
|
||||
- 1x Expansion card (tier 1)
|
||||
- 1x Upgrade (tier 1)
|
||||
- 1x Upgrade (tier 2)
|
||||
|
||||
The tier 2 Drone case is capable of taking the following components:
|
||||
- 1x tier 1 [CPU)](cpu1.md)
|
||||
- 2x tier 1 [RAM](ram1.md)
|
||||
- 1x [EEPROM](eeprom.md)
|
||||
- 2x Expansion card (tier 2)
|
||||
- 1x Upgrade (tier 1)
|
||||
- 1x Upgrade (tier 2)
|
||||
- 1x Upgrade (tier 3)
|
||||
|
||||
The tier 4 (Creative) Drone case is capable of taking the following components:
|
||||
- 1x tier 3 [CPU](cpu3.md)
|
||||
- 2x tier 3 [RAM](ram5.md)
|
||||
- 1x [EEPROM](eeprom.md)
|
||||
- 3x Expansion card (tier 3)
|
||||
- 9x Upgrade (tier 3)
|
||||
@ -3,3 +3,5 @@
|
||||
|
||||
|
||||
The EEPROM is what contains the code used to initialize a computer when it is being booted. This data is stored as a plain byte array, and may mean different things to different [CPU](cpu1.md) architectures. For example, for Lua it is usually a small script that searches for file systems with an init script, for other architectures it may be actual machine code.
|
||||
|
||||
EEPROMs can be programmed for specialized purposes, such as [drones](drone.md) and [microcontrollers](microcontroller.md).
|
||||
|
||||
@ -4,6 +4,6 @@
|
||||
|
||||
The Experience Upgrade is a very special upgrade, as it allows [robots](../block/robot.md) and [drones](drone.md) to collect experience by performing various actions, such as digging up ores and killing entities. A single upgrade can store up to 30 levels, providing passive bonuses with each level, including faster harvest speeds and increased energy buffer capacity.
|
||||
|
||||
Robots at level ten and above will get a golden tint, robots at level twenty and above will get a diamond tint.
|
||||
[Robots](../block/robot.md) at level ten and above will get a golden tint, [robots](../block/robot.md) at level twenty and above will get a diamond tint.
|
||||
|
||||
The actual experience is stored inside the upgrade, meaning if the upgrade is transferred to another device, so is the experience.
|
||||
|
||||
@ -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.
|
||||
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 intentory 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 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 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).
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The Graphics Card is an essential part for most computers and allows the computer to display text on a connected [screen](../block/screen1.md). Graphics cards come in several tiers, and like screens, support different resolutions and color depths.
|
||||
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 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' 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.
|
||||
|
||||
@ -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).
|
||||
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.
|
||||
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The Internet Card grants computers 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.
|
||||
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 computer 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 and to pastebin as well as a wannabe wget clone that allows downloading data from arbitrary HTTP URLs.
|
||||
|
||||
@ -4,4 +4,4 @@
|
||||
|
||||
The Inventory Controller Upgrade provides extended inventory interaction to [robots](../block/robot.md) and [drones](drone.md). It allows the device to excplicitly 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.
|
||||
|
||||
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 and drones.
|
||||
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).
|
||||
|
||||
@ -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, 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 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.
|
||||
|
||||
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.
|
||||
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).
|
||||
|
||||
@ -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 when in different 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. In return, the distance the cards can communicate over is unlimited. They can even communicate across dimensions.
|
||||
|
||||
@ -0,0 +1,7 @@
|
||||
# Microcontroller
|
||||
|
||||
|
||||
|
||||
Microcontrollers are built using a [microcontroller case](microcontrollerCase1.md) in the [assembler](../block/assembler.md). They have less functionality compared to computers.
|
||||
|
||||
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.
|
||||
@ -4,6 +4,28 @@
|
||||
|
||||
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.
|
||||
|
||||
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 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 microcontroller 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.
|
||||
|
||||
The tier 1 Microcontroller case can accept the following components:
|
||||
- 1x tier 1 [CPU](cpu1.md)
|
||||
- 1x tier 1 [RAM](ram1.md)
|
||||
- 1x [EEPROM](eeprom.md)
|
||||
- 2x Expansion cards (tier 1)
|
||||
- 1x Upgrade (tier 2)
|
||||
|
||||
The tier 2 Microcontroller case can accept the following components:
|
||||
- 1x tier 1 [CPU](cpu1.md)
|
||||
- 2x tier 1 [RAM](ram1.md)
|
||||
- 1x [EEPROM](eeprom.md)
|
||||
- 1x Expansion card (tier 2)
|
||||
- 1x Expansion card (tier 1)
|
||||
- 1x Upgrade (tier 3)
|
||||
|
||||
The tier 1 Microcontroller case can accept the following components:
|
||||
- 1x tier 3 [CPU](cpu3.md)
|
||||
- 2x tier 3 [RAM](ram5.md)
|
||||
- 1x [EEPROM](eeprom.md)
|
||||
- 3x Expansion cards (tier 3)
|
||||
- 9x Upgrades (tier 3)
|
||||
@ -2,4 +2,12 @@
|
||||
|
||||
|
||||
|
||||
Memory is, like a [CPU](cpu1.md), an essential part in all computers. 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'll need more RAM.
|
||||
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.
|
||||
|
||||
RAM is available in multiple tiers with the following capacities, by default (configurable):
|
||||
- Tier 1: 192KB
|
||||
- Tier 1.5: 256KB
|
||||
- Tier 2: 384KB
|
||||
- Tier 2.5: 512KB
|
||||
- Tier 3: 768KB
|
||||
- Tier 3.5: 1024KB
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
|
||||
|
||||
|
||||
The Redstone Card allows computers to read and emit analog redstone signal in adjacent blocks. When an ingoing signal strength changes, a signal is injected into the computer.
|
||||
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.
|
||||
|
||||
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 / robot / server rack. That means when looking at the front of the computer, right is at your left and vice versa.
|
||||
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,4 +2,38 @@
|
||||
|
||||
|
||||
|
||||
Servers are a form of higher tier computer. They can be configured by holding them in the hand and rightclicking - like opening a backpack or ender pouch, for example. After inserting [CPU](cpu1.md), [memory](ram1.md) and 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 right-clicking - 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.
|
||||
|
||||
The tier 1 Server is capable of taking the following components:
|
||||
- 1x tier 2 [CPU](cpu2.md)
|
||||
- 2x tier 2 [RAM](ram3.md)
|
||||
- 2x tier 2 [HDD](hdd2.md)
|
||||
- 1x tier 2 [component bus](componentBus2.md)
|
||||
- 2x Expansion cards (tier 2)
|
||||
- 1x [EEPROM](eeprom.md)
|
||||
|
||||
The tier 2 Server is capable of taking the following components:
|
||||
- 1x tier 3 [CPU](cpu3.md)
|
||||
- 3x tier 3 [RAM](ram5.md)
|
||||
- 3x tier 3 [HDD](hdd3.md)
|
||||
- 2x tier 3 [component bus](componentBus3.md)
|
||||
- 2x Expansion cards (tier 2)
|
||||
- 1x Expansion card (tier 3)
|
||||
- 1x [EEPROM](eeprom.md)
|
||||
|
||||
The tier 3 Server is capable of taking the following components:
|
||||
- 1x tier 3 [CPU](cpu3.md)
|
||||
- 4x tier 3 [RAM](ram5.md)
|
||||
- 4x tier 3 [HDD](hdd3.md)
|
||||
- 3x tier 3 [component bus](componentBus3.md)
|
||||
- 2x Expansion cards (tier 2)
|
||||
- 2x Expansion cards (tier 3)
|
||||
- 1x [EEPROM](eeprom.md)
|
||||
|
||||
The tier 4 (Creative) Server is capable of taking the following components:
|
||||
- 1x tier 3 [CPU](cpu3.md)
|
||||
- 4x tier 3 [RAM](ram5.md)
|
||||
- 4x tier 3 [HDD](hdd3.md)
|
||||
- 3x tier 3 [component bus](componentBus3.md)
|
||||
- 4x Expansion cards (tier 3)
|
||||
- 1x [EEPROM](eeprom.md)
|
||||
|
||||
@ -0,0 +1 @@
|
||||
#REDIRECT server1.md
|
||||
@ -2,8 +2,8 @@
|
||||
|
||||
|
||||
|
||||
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, however, do, such as the [sign upgrade](signUpgrade.md) or the [piston upgrade](pistonUpgrade.md).
|
||||
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, shift-rightclick 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).
|
||||
|
||||
Tablets can be put into a [charger](../block/charger.md) to refill their energy, and to access the first [hard disk](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.
|
||||
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.
|
||||
|
||||
@ -7,3 +7,33 @@ The Tablet Case is the base part when building [tablets](tablet.md) in the [asse
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
The tier 1 Tablet case can hold the following components:
|
||||
- 1x [CPU (tier 2)](cpu2.md)
|
||||
- 2x [RAM (tier 2)](ram3.md)
|
||||
- 1x [HDD (tier 2)](hdd2.md)
|
||||
- 2x Expansion cards (tier 2)
|
||||
- 1x [EEPROM](eeprom.md)
|
||||
- 1x Upgrade (tier 1)
|
||||
- 1x Upgrade (tier 2)
|
||||
- 1x Upgrade (tier 3)
|
||||
|
||||
The tier 2 Tablet case can hold the following components:
|
||||
- 1x [CPU (tier 3)](cpu3.md)
|
||||
- 2x [RAM (tier 2)](ram3.md)
|
||||
- 1x [HDD (tier 2)](hdd2.md)
|
||||
- 1x Expansion card (tier 2)
|
||||
- 1x Expansion card (tier 3)
|
||||
- 1x [EEPROM](eeprom.md)
|
||||
- 2x Upgrade (tier 2)
|
||||
- 1x Upgrade (tier 3)
|
||||
- 1x [Upgrade](upgradeContainer2.md) or [Card container](cardContainer2.md) (tier 2)
|
||||
|
||||
The tier 4 (Creative) Tablet case can hold the following components:
|
||||
- 1x [CPU (tier 3)](cpu3.md)
|
||||
- 2x [RAM (tier 3)](ram5.md)
|
||||
- 1x [HDD (tier 3)](hdd3.md)
|
||||
- 3x Expansion cards (tier 3)
|
||||
- 1x [EEPROM](eeprom.md)
|
||||
- 9x Upgrade (tier 3)
|
||||
- 1x [Upgrade](upgradeContainer3.md) or [Card container](cardContainer3.md) (tier 3)
|
||||
@ -2,6 +2,6 @@
|
||||
|
||||
|
||||
|
||||
The tank controller upgrade is to fluid tanks what the [inventory controller upgrade](inventoryControllerUpgrade.md) is to normal inventories. It allows devices to query more detailed information about tanks in and next to them.
|
||||
The tank controller upgrade is to fluid tanks what the [inventory controller upgrade](inventoryControllerUpgrade.md) is to normal inventories. It allows devices to query more detailed information about tanks inside and next to them.
|
||||
|
||||
This upgrade can also be installed in [adapters](../block/adapter.md), allowing computers connected to the adapter to query information about the tanks adjacent to the adapter.
|
||||
This upgrade can also be installed in [adapters](../block/adapter.md), allowing [computers](../general/computer.md) connected to the [adapter](../block/adapter.md) to query information about the tanks adjacent to the [adapter](../block/adapter.md).
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
The Tank Upgrade allows devices to store fluids. Each tank can only hold a single type of fluids, and provides a volume of 16 buckets (16000mB). [Robots](../block/robot.md) and [drones](drone.md) can drain liquids from the world and from other fluid tanks, and can fill the fluids back into fluid tanks, and, when supported by the fluid, place them back into the world. There is no limit to the number of tanks that can be installed in a device.
|
||||
The Tank upgrade allows devices to store fluids. Each tank can only hold a single type of fluid, and provides a volume of 16 buckets (16000mB). [Robots](../block/robot.md) and [drones](drone.md) can drain liquids from the world and from other fluid tanks, and can fill the fluids back into fluid tanks, and when supported by the fluid, place them back into the world. There is no limit to the number of tanks that can be installed in a device.
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
|
||||
|
||||
|
||||
The Remote Terminal can be used to remote control [servers](server.md). To use it, sneak-activate a server that is installed in a [server rack](../block/serverRack.md) (click on the server rack block in the world, targeting the server to bind the terminal to).
|
||||
The Remote Terminal can be used to remote control [servers](server.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, 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 rightclicking with the terminal in hand after binding it, a GUI will open, the same as when opening the GUI of a screen with an attached keyboard.
|
||||
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 right-clicking with 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).
|
||||
|
||||
Multiple terminals can be bound to one server, but they will all display the same information, as they will share the virtual screen and keyboard. The number of terminals that can be bound to a server depends on the server's tier. The range in which the terminals work can be configured in the server rack's GUI.
|
||||
Multiple terminals can be bound to one [server](server1.md), but they will all display the same information, as they will share the virtual [screen](../block/screen1.md) and [keyboard](../block/keyboard.md). The number of terminals that can be bound to a [server](server1.md) depends on the [server](server1.md)'s tier. The range in which the terminals work can be configured in the [server rack](../block/serverRack.md)'s GUI.
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
|
||||
|
||||
|
||||
The Tractor Beam Upgrade allows devices to pick up items in a three block radius around them. This can be highly useful when employing [robots](../block/robot.md) in tree or other farms, or when having them use tools that break multiple blocks around them (such as Tinker's Construct tools). Each operation will try to suck a single item stack in range and consume some energy.
|
||||
The Tractor beam upgrade allows devices to pick up items in a three block radius around them. This can be highly useful when using [robots](../block/robot.md) in tree or other farms, or when having them use tools that break multiple blocks around them (such as Tinker's Construct tools). Each operation will try to suck a single item stack in range and consume some energy.
|
||||
|
||||
@ -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 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.
|
||||
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.
|
||||
|
||||
@ -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 that 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'll want to make sure the line of sight between sender and receiver are clear, however.
|
||||
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.
|
||||
|
||||
@ -0,0 +1,5 @@
|
||||
# World Sensor Card
|
||||
|
||||
|
||||
|
||||
The World sensor card allows reading of atmospheric information as well as gravity on different planets added by Galacticraft. This can be useful for [robots](../block/robot.md) or [drones](drone.md) operating in space.
|
||||
Loading…
x
Reference in New Issue
Block a user