Blocks
For those that don't like images: the wiki has moved to a new place, http://ocdoc.cil.li/.
This wiki will no longer be updated.
This page lists all blocks OpenComputers adds to the game. Please check the recipes via NEI. Alternatively, here you can find a graphical representation of the recipes here. They are sorted alphabetically as far as I can tell.
The Computer Case is the basic building block for computers and houses the computer's extension cards, RAM and hard disks.
- Slots: 2,1,1/2,2,2/3,2,3.
From left to right: Card slots/RAM slots/HDD slots. Note that for tier three, the the third storage slot is for floppy disks, not for a third hard disk.
Each tier also provides a CPU slot of the same tier as the case.
For simple use cases a basic case will be quite adequate. When you want to run more complex applications or control multiple/bigger screens you will need to upgrade to a higher tier case, though.
Computers offer an API to the programs running on them and neighbored blocks, allowing them to start or stop the computer, and to inspect its running state, for example.
The server rack houses up to four Servers. Servers are basically computer cases in item format. Their main advantage is that they can allow for multiple CPUs, allowing more components to be controlled than via a normal computer.
The server rack also acts like a Power Distributor and Switch in one block, including the built-in servers. Each server slot can be configured to connect to one side directly, though, so the server in the slot can be used to control external block components, such as the Redstone I/O block.
The range in which Remote Terminals bound to servers in the rack can be used is configured in the server rack's GUI and applies to all servers in it.
Display text, controlled by a Graphics Card in a Case.
- Maximum resolution: 50x16/80x25/160x50.
- Maximum color depth: 1/4/8.
Screens allow computers to display text, by binding them on a graphics card and then changing their text buffer. Think of these screens more like... chalk boards. You don't have to send the data to display each "frame", instead you set something to display, and the screen will continue displaying it until it's told to display something else. There are a few scenarios where a screen's buffer will be cleared, though: when they are merged into a multi-block screen, when the controlling computer is turned off, and when they are bound by a graphics card.
Note that screens of all tiers can be controlled by graphics cards of all tiers. However, the minimum capabilities of each combination apply. For example, when using an advanced screen via a basic graphics card, the maximum resolution and color depth will be limited by that of the graphics card.
Tier two and three screens allow mouse input: it generates a touch signal on all computers in its network whenever a user either right-clicks/activates the display area of a screen without a keyboard - like a giant touch screen - or when left clicking on the display area in the GUI of a screen with a keyboard.
As of version 1.3, tier 2 screens use a 16 color palette, that defaults to the Minecraft colors and can be manipulated as desired. Tier 3 screens have a hybrid color system, where 240 colors are "automatic" and a 16 color palette exists that defaults to different shades of grey, but can also be manipulated as desired.
Can be attached to screens to allow typing on them. Note that keyboards will only work on screens they are placed on or point towards.
For multi-block screens it can very much matter where on the screen you place the keyboard, since you have to be within range of the keyboard to type - meaning you may be able to open the screen's GUI, but not be able to type.
Note that a screen block for itself is just that. A screen. Displaying stuff. Once you attach a keyboard to it, a GUI will open when you right-click/activate it, allowing text input. Note that tier two and three screens allow "clicking" them in the world directly (by right-clicking/activating them), i.e. a touch signal will be generated. They're touch-screens, so to speak. This only works if they have no keyboard.
This block projects a hologram in the area over it. The size of the hologram can be scaled from 1x1x1 block to 9x9x6 blocks. The number of 'voxels' will stay the same, regardless of scale though. It has resolution of 48x32x48 monochrome voxels (they can either be on or off). Each voxel in that 3D array can be set individually. Generated holograms will look like this.
The second tier of the hologram projector is also capable of displaying colored voxels - in three different colors. These colors can be set to any desired value, i.e. the color palette is editable.
Tier 2 since version 1.3.
Stores energy for later use. Can be filled and emptied very quickly. Note that some blocks have a small, internal storage capacity, to allow getting started quickly with a small setup (e.g. computer cases and Power Converters). This means you will have to keep supplying power almost non-stop, to avoid computers shutting down due to power loss. To increase the time a network can continue to function without new power being injected into it you can build capacitors to increase the networks' energy storage capacity.
You'll also want to have some capacitors ready to allow charging robots at a reasonable pace without bringing down all other components in your network. Otherwise they'll just suck your network dry.
Converts power from other mods to the internal energy type.
The default conversion rates are:
- BuildCraft MJ: 1:1.
- IndustrialCraft² EU: 2.5:1.
- Thermal Expansion RF: 10:1
- Universal Electricity Joules: 1:1.
Note that computer cases and server racks, as well as the assembler, disassembler and charger blocks also act as power converters, i.e. you can feed power from other mods directly into those, too, at the same rates. The rule of thumb is: if it requires power to run and can operate independent of a computer (or is a computer) it can accept power.
Since there is no way to generate the mods internal energy directly at this point you'll definitely need one of these. Well, the exception is the generator upgrade for robots, but that energy can only be used by the robot with the upgrade.
Distributes energy between different networks. This can be useful for powering multiple sub-networks that should not connect to each other. For example, you'll usually want to try and keep different computers in different networks - unless you have a startup script on each computer that manually assigns the primary components. Otherwise you'll frequently end up with the computers binding the wrong screen and/or keyboard on startup, for example, or even multiple computer binding to the same screen.
The Switch allows connecting different networks to each other. Only network messages will be passed along, components will not be visible through this. Use this to separate networks while still allowing communication using Network Cards. The reasoning is the same as for the Power Distributor not connecting its adjacent networks: you may often wish to keep your sub-networks separate. This allows computers in different sub-networks to communicate without having to go all out and use wireless networks.
Note that switches have a limited bandwidth. They will only transfer one packet per 5 ticks (250ms) and their internal queue is limited to 20 packets. If you exceed this limit you will experience dropped packets. Also note that packets can be relayed no more than 5 times. After that the packet is dropped.
Switches will not route packets back where they came from, but it is still possible to generate loops where packets will then arrive multiple times, so keep that in mind.
The Switch block also serves as a ComputerCraft peripheral, providing an interface imitating that of ComputerCraft's (wired) modems. It will forward network messages sent from ComputerCraft to the OpenComputers side, which can be received if a Network Card is installed. It will also receive OpenComputers' network messages and push a corresponding signal in CC computers attached to the adapter. Note that network messages in OpenComputers do not require a "response port" like ComputerCraft does. If the first argument for the network message is a number, it will be interpreted as the response port to tell ComputerCraft receivers, otherwise the response port will be set to -1.
Note: this functionality was available via the Adapter block before 1.1.0.
The Access Point is an improved version of the Switch. It allows for the same functionality and more: it also receives and relays wireless messages! It converts wireless messages into wired ones and vice versa, given its signal strength is not set to zero. For example, placing an Access Point next to a computer with a normal network card will allow it to send network messages to another computer with a wireless network card that is in range of the access point, as well as receive messages from it.
A cheap way of connecting blocks. As described on the start page, most blocks in OpenComputers will serve as "connectors", i.e. components will automatically be available to any computers the are indirectly connected to. A few exceptions are the Switch and the Power Distributor blocks, which explicitly should not connect different networks they are adjacent to. Cables are the least expensive way of building such connections over longer distances. For example, if you wish to have your actual computer in a safe place, and the screen somewhere more visible, you may wish to connect the screen to your computer using cables. Instead of... capacitors. Or more screens.
Allows reading and writing floppies. ComputerCraft floppies are also supported.
The main use of floppies - except being cheaper than hard drives - is to get data onto robots, since they cannot connect to external components, and only have a component slot for floppies, but not for hard drives. If you have the materials, you can build a tier three case, which has a built-in disk drive. Until then, this block is your new best friend.
Allows reading and emitting redstone signals around the block. Can be controlled by any computer the block is connected to. This is basically like an external redstone card.
- This also supports RedLogic wires, if present, including colored and bundled wires.
- This also supports MineFactory Reloaded RedNet cables.
- This also supports Project: Red wires, including colored and bundled wires.
Like redstone cards, this offers the redstone component API. Note that while redstone cards rely on the container's orientation for the sides in their API, the redstone I/O block always uses absolute directions, e.g. sides.north.
This block can be used to... recycle OC's items and blocks. It will take items put into it apart, and output the original parts of the item or block. If there is an adjacent inventory, output will be placed into that inventory. Otherwise the items are spawned in the world.
This block is particularly useful for taking apart old tier one equipment, or for disassembling robots that didn't quite turn out the way you wanted them to.
Warning: there is a 5% chance for each outputted item to break. For example, when disassembling and object that consists of 100 items of type "X", on average you will only get 95 of them back. This value can be changed in the config, if you think this is too harsh / not harsh enough.
Since version 1.3.
This block allows scanning its surroundings for the hardness of blocks. It's vertical range is 32 blocks up and down, so a column of height 64 in total. It operates in "columns", e.g. when scanning at the relative coordinates (0, 0) it will scan the blocks 32 below and above (and including) the geolyzer block.
The returned values are (with some noise) the hardness values of the scanned blocks. This is useful for detecting ores (which are usually harder than stone) and for generating 'maps' that can be displayed on the hologram projector.
Since version 1.3.
Used to control non-component blocks, such as vanilla blocks or blocks from other mods. You will most likely also install OpenComponents to make this block more useful.
This block allows interfacing with all kinds of blocks, as long as a driver is made available to OpenComputers. For example, OpenComponents comes with such drivers for the vanilla Command Block and Note Block, as well as drivers for a bunch of tech mods such as BuildCraft IndustrialCraft2 and ThermalExpansion. OpenComponents will also allow the Adapter to interface with most ComputerCraft peripherals.
If you're a modder it's pretty easy to write a driver, you just have to implement the corresponding interface from the API and register it with OpenComputers in the init phase. Have a look at the implementation of OpenComponents, if you find the documentation in the interfaces is insufficient.
This machine is used to assemble a robot from its individual parts. You can configure your robot in a lot of detail here, but keep in mind that most parts will be fixed once the robot is assembled, so choose wisely. Assembly takes a short amount of time, but consumes a good bit of energy.
For a basic robot you will generally want to add the parts you also use to build a computer, i.e. a CPU, RAM, a medium with an operating system on it, and unless you want a "headless" robot, a screen, a keyboard and a GPU.
Since version 1.3.
Transfers energy from capacitors into adjacent robots. The transfer rate depends on the incoming redstone signal, where no signal means don't charge robots, and maximum strength means charge at full speed.
You'll need one of these to get your robots running. There is the generator upgrade, but you can only put fuel into the generator via the API, meaning you have to get some energy into your robot some other way, first. And that way is the Charger block.
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 or create some low-level protocol using redstone signals via a Redstone Card.