mirror of
https://github.com/MightyPirates/OpenComputers.git
synced 2025-09-19 12:17:17 -04:00
Added general documentation for a bunch of blocks and items via an extra NEI usage handler.
This commit is contained in:
Florian Nücke
parent
cb2bec3227
commit
5502838e84
@ -271,3 +271,53 @@ oc:tooltip.UpgradeTank=This upgrade provides a tank for fluid storage to the rob
|
||||
oc:tooltip.UpgradeTankController=This upgrade allows the robot more control in how it interacts with external tanks, and allows it to transfer fluids into and out of fluid tank items in its inventory.
|
||||
oc:tooltip.UpgradeTractorBeam=Equips the robot with extremely advanced technology, nicknamed the "Item Magnet". Allows it to pick up items anywhere within 3 blocks of its location.
|
||||
oc:tooltip.WirelessNetworkCard=Allows wireless sending of network messages in addition to normal ones. You can adjust the §fsignal strength§7 to control how far messages are sent. Higher signal strength results in higher energy consumption.
|
||||
|
||||
# NEI Usage Pages
|
||||
item.oc.AbstractBusCard.usage=This card allows computers, servers 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.
|
||||
item.oc.Analyzer.usage=The §oAnalyzer§r 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.[nl][nl]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.
|
||||
item.oc.ComponentBus.usage=A §oComponent Bus§r is a server-specific upgrade that allows the server to communicate with more components at the same time, without shutting down. Like with CPUs, higher tier buses provide higher component limits.
|
||||
item.oc.CPU.usage=The §oCentral Processing Unit§r 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.
|
||||
item.oc.DebugCard.usage=The §oDebug Card§r is a non-craftable 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.
|
||||
item.oc.FloppyDisk.usage=The §oFloppy Disk§r 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 and robots. You may also find floppy disks with useful programs on them in dungeon chests.[nl][nl]Beware: shift-rightclicking while holding a floppy disk in your hand will wipe the floppy disk!
|
||||
item.oc.GraphicsCard.usage=The §oGraphics Card§r is an essential part for most computers and allows the computer to display text on a connected §oScreen§r. Graphics cards come in several tiers, and like screens, support different resolutions and color depths.[nl][nl]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. 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.
|
||||
item.oc.HardDiskDrive.usage=The §oHard Disk Drives§r 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 (although servers could use an external disk drive, for example).[nl][nl]Beware: shift-rightclicking while holding a hard disk in your hand will wipe the disk!
|
||||
item.oc.InternetCard.usage=The §oInternet Card§r 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.[nl][nl]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.
|
||||
item.oc.LinkedCard.usage=The §oLinked Card§r is a specialized but advanced version of a network card. 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.
|
||||
item.oc.Memory.usage=§oMemory§r is, like a §oCPU§r, 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.
|
||||
item.oc.NetworkCard.usage=The §oNetwork Card§r 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. §oSwitches§r and §oAccess Points§r 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.
|
||||
item.oc.RedstoneCard.usage=The §oRedstone Card§r 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.[nl][nl]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.[nl][nl]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.
|
||||
item.oc.Server.usage=§oServers§r 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, memory and cards, the server has to be placed inside a §oServer Rack§r. For more information see the server rack entry.
|
||||
item.oc.TabletCase.usage=The §oTablet Case§r is the base part when building tablets in the §oAssembler§r. 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 can (using simple §oNetwork Cards§r or §oRedstone Cards§r 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.[nl][nl]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.
|
||||
item.oc.Terminal.usage=The §oRemote Terminal§r can be used to remote control §oServers§r. To use it, sneak-activate a server that is installed in a §oServer Rack§r (click on the server rack block in the world, targeting the server to bind the terminal to). When a terminal is bound to a server, a virtual screen and keyboard 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.[nl][nl]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.
|
||||
item.oc.UpgradeChunkloader.usage=The §oChunkloader Upgrade§r can be installed in robots 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 robot.[nl][nl]The upgrade is automatically enabled when the robot powers up, and automatically disabled when the robot powers down.
|
||||
item.oc.UpgradeContainerCard.usage=The §oCard Container§r is a container type upgrade for robots 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.
|
||||
item.oc.UpgradeContainerUpgrade.usage=The §oUpgrade Container§r is a container type upgrade for robots 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.
|
||||
item.oc.UpgradeCrafting.usage=The §oCrafting Upgrade§r allows robots 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.
|
||||
item.oc.UpgradeExperience.usage=The §oExperience Upgrade§r is a very special upgrade, as it allows robots to collect experience by performing various actions, such as digging up ores and killing entities. Robots can gain up to 30 levels, and gain 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.[nl][nl]The actual experience is stored inside the upgrade, meaning if the upgrade is transferred to another robot, so is the experience.
|
||||
item.oc.UpgradeGenerator.usage=The §oGenerator Upgrade§r allows robots 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.[nl][nl]The efficiency of generators is lower than that of usual generators of other mods, meaning it is usually more fuel efficient to power robots using a §oCharger§r.
|
||||
item.oc.UpgradeInventory.usage=The §oInventory Upgrade§r provides inventory slots to robots. For each inventory upgrade a robot will gain an addition 16 inventory slots, up to a maximum of 64 slots in total. If no inventory upgrade is installed in a robot it will not be able to store or pick up items.
|
||||
item.oc.UpgradeInventoryController.usage=The §oInventory Controller Upgrade§r provides extended inventory interaction to robots. It allows the robots to excplicitly target slots in external inventories when dropping or sucking items. It also allows robots to read detailed information about item stacks. Lastly it provides robots with a means to change their equipped tool without external help.[nl][nl]This upgrade can also be placed in §oAdapters§r, 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.
|
||||
item.oc.UpgradeNavigation.usage=The §oNavigation Upgrade§r provides location and orientation information to §oRobots§r and §oTablets§r 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.[nl][nl]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.
|
||||
item.oc.UpgradeTank.usage=The §oTank Upgrade§r allows robots to store fluids. Each tank can only hold a single type of fluids, and provides a volume of 16 buckets (16000mB). Robots 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 robot.
|
||||
item.oc.UpgradeTankController.usage=The §oTank Controller Upgrade§r is to fluid tanks what the §oInventory Controller Upgrade§r is to normal inventories. It allows robots to query more detailed information about tanks in and next to the robot.[nl][nl]This upgrade can also be installed in §oAdapters§r, allowing computers connected to the adapter to query information about the tanks adjacent to the adapter.
|
||||
item.oc.UpgradeTractorBeam.usage=The §oTractor Beam Upgrade§r allows robots to pick up items in a three block radius around them. This can be highly useful when employing robots 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.
|
||||
item.oc.WirelessNetworkCard.usage=The §oWireless Network Card§r is an upgraded §oNetwork Card§r than, 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.[nl][nl]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.
|
||||
tile.oc.accessPoint.usage=The §oAccess Point§r is the wireless version of the switch block. 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.[nl][nl]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.[nl][nl]Switches and access point do §lnot§r keep track of which packets they relayed recently, so avoid cycles in your network, or you may receive the same packet multiple times.[nl][nl]Packets are only re-sent a certain number of times, so chaining an arbitrary number of switches or access points is not possible.
|
||||
tile.oc.adapter.usage=The §oAdapter§r allows computers to interact with a number of blocks that are not part of OC, 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 connected to the adapter.[nl][nl]In addition to this, the adapter provides a slot for a few select upgrades. For example, the §oInventory Controller Upgrade§r allows computers to query more information from an inventory adjacent to the adapter, similar to when the upgrade is installed in a robot, and a §oTank Controller Upgrade§r provides similar functionality for fluid tanks next to the adapter.
|
||||
tile.oc.assembler.usage=The §oAssembler§r is an advanced workstation that can be used to build more complex electronic devices, such as §oRobots§r and §oTablets§r. They usually require a relatively large amount of energy to assemble these devices, to it is recommended to power them sufficiently.[nl][nl]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. 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 to insert and remove floppies later on, for example).[nl][nl]Also note that for robots to have a screen you need to install a tier one screen in them, and to allow typing on the screen you also need to install a keyboard. 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.[nl][nl]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 §oDisassembler§r, which has a slight chance of breaking parts in the process.
|
||||
tile.oc.cable.usage=The §oCable§r 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.[nl][nl]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.[nl][nl]Speaking of which, cables can be covered using either Forge MultiPart covers or immibis Microblocks covers.
|
||||
tile.oc.capacitor.usage=The §oCapacitor§r 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 §oAssembler§r or charging §oRobots§r.[nl][nl]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.
|
||||
tile.oc.case.usage=The §oComputer Case§r is the most basic computer you can build, and usually what you'll get started with. The different tiers of computers have a different layout of slots available for parts, as well as increasing level of supported component tier (indicated by the roman numeral in applicable slots).[nl][nl]To get a running computer you'll need to install a §oCPU§r and some §oMemory§r (RAM) in a computer case. You'll usually also want to install a §oGraphics Card§r to be able to display text on a connected screen, and a §oHard Drive§r to install an operating system on (after booting from an OS floppy from an external §oDisk Drive§r for the first time, for example).[nl][nl]Computers can be upgraded using several different cards. For example, using a §oRedstone Card§r computers are able to read and emit redstone signals. Using §oNetwork Cards§r they can send and receive network messages, allowing them to communicate with other computers.[nl][nl]If a computer stops working / crashes, try using the §oAnalyzer§r tool on it (sneak-activate) to see the error message that caused the computer to stop.[nl][nl]Computer cases can be dyed using any dye. This is purely for aesthetic reasons, and has no practical implications.[nl][nl]Computer cases also serve as the base part when building robots in the §oAssembler§r. The different tiers determine the available slots for building the robot. When using a creative case, the robot will also provide itself with power, as does the normal creative case.
|
||||
tile.oc.charger.usage=The §oCharger§r is used to charge devices such as §oRobots§r and §oTablets§r. 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%.[nl][nl]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.[nl][nl]When a tablet is placed in the charger, its first hard drive is also exposed to computers connected to the charger, similar to how §oFloppies§r in §oDisk Drives§r are. This allows copying data onto or from a tablet, if desired.
|
||||
tile.oc.disassembler.usage=The §oDisassembler§r 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 without an operating system).[nl][nl]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.
|
||||
tile.oc.diskDrive.usage=The §oDisk Drive§r can be used to read §oFloppies§r 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).[nl][nl]It can also be installed in robots 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 §oNetwork Cards§r.
|
||||
tile.oc.geolyzer.usage=The §oGeolyzer§r 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 §oHologram Projectors§r as well as to detect potentially valuable blocks (ores are usually harder than dirt and stone).[nl][nl]The geolyzer can also be installed in robots 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.
|
||||
tile.oc.keyboard.usage=A §oKeyboard§r is needed to type text on §oScreens§r, be they in the world or built into devices such as §oRobots§r or §oTablets§r.[nl][nl]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.
|
||||
tile.oc.hologram.usage=The §oHologram Projector§r 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.[nl][nl]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.
|
||||
tile.oc.motionSensor.usage=The §oMotion Sensor§r 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.[nl][nl]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.
|
||||
tile.oc.powerConverter.usage=The §oPower Converter§r 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 §oAssembler§r or §oCharger§r, it is usually a good idea to use a converter, instead of directly connecting them to external power.
|
||||
tile.oc.powerDistributor.usage=The §oPower Distributor§r is for energy what the §oSwitch§r 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 §lrelative§r amount of energy is the same in them.
|
||||
tile.oc.redstone.usage=The §oRedstone I/O§r block can be used to remotely read and emit redstone signals. It behaves like a hybrid of a tier one and two §oRedstone Card§r, in that it can read and emit simple analog as well as bundled signals, but cannot read or emit wireless redstone signals.[nl][nl]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.[nl][nl]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.
|
||||
tile.oc.screen.usage=A §oScreen§r is used in combination with a §oGraphics Card§r 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.[nl][nl]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.[nl][nl]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.[nl][nl]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.
|
||||
tile.oc.serverRack.usage=A §oServer Rack§r houses up to four §oServers§r. A server is a higher tier computer, which can only run when inside a server rack. Servers can be remote controlled using a §oRemote Terminal§r. 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.[nl][nl]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.[nl][nl]Server racks act as §oSwitch§r and §oPower Distributor§r 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.
|
||||
tile.oc.switch.usage=The §oSwitch§r 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).[nl][nl]There is also a wireless variation of this block, the §oAccess Point§r, which will also relay messages wirelessly.[nl][nl]Switches and access point do §lnot§r keep track of which packets they relayed recently, so avoid cycles in your network, or you may receive the same packet multiple times.[nl][nl]Packets are only re-sent a certain number of times, so chaining an arbitrary number of switches or access points is not possible.
|
||||
@ -6,7 +6,9 @@ import net.minecraft.util.ChatComponentTranslation
|
||||
import net.minecraft.util.StatCollector
|
||||
|
||||
object Localization {
|
||||
private def resolveKey(key: String) = if (StatCollector.canTranslate(Settings.namespace + key)) Settings.namespace + key else key
|
||||
private def resolveKey(key: String) = if (canLocalize(Settings.namespace + key)) Settings.namespace + key else key
|
||||
|
||||
def canLocalize(key: String) = StatCollector.canTranslate(key)
|
||||
|
||||
def localizeLater(formatKey: String, values: AnyRef*) = new ChatComponentTranslation(resolveKey(formatKey), values: _*)
|
||||
|
||||
|
||||
@ -0,0 +1,65 @@
|
||||
package li.cil.oc.integration.nei
|
||||
|
||||
import codechicken.nei.recipe.IUsageHandler
|
||||
import com.google.common.base.Strings
|
||||
import li.cil.oc.api.driver.EnvironmentAware
|
||||
import li.cil.oc.server.driver.Registry
|
||||
import li.cil.oc.server.machine.Callbacks
|
||||
import net.minecraft.item.ItemStack
|
||||
import net.minecraft.util.EnumChatFormatting
|
||||
|
||||
import scala.collection.convert.WrapAsScala._
|
||||
|
||||
class CallbackDocHandler(pages: Option[Array[String]]) extends PagedUsageHandler(pages) {
|
||||
def this() = this(None)
|
||||
|
||||
private val DocPattern = """^function(\([^)]*\)[^-]*) -- (.*)$""".r
|
||||
|
||||
private val VexPattern = """^function(\([^)]*\)[^-]*); (.*)$""".r
|
||||
|
||||
override def getRecipeName = "OpenComputers API"
|
||||
|
||||
override def getUsageHandler(input: String, ingredients: AnyRef*): IUsageHandler = {
|
||||
if (input == "item") {
|
||||
ingredients.collect {
|
||||
case stack: ItemStack if stack.getItem != null =>
|
||||
val callbacks = Option(Registry.driverFor(stack)) match {
|
||||
case Some(driver: EnvironmentAware) =>
|
||||
getCallbacks(driver.providedEnvironment(stack))
|
||||
case _ => Registry.blocks.collect {
|
||||
case driver: EnvironmentAware => driver.providedEnvironment(stack)
|
||||
}.filter(_ != null).map(getCallbacks).flatten
|
||||
}
|
||||
|
||||
if (callbacks.size > 0) {
|
||||
val fullDocumentation = callbacks.toArray.sorted.mkString("\n\n")
|
||||
val pages = fullDocumentation.lines.grouped(12).map(_.mkString("\n")).toArray
|
||||
Option(new CallbackDocHandler(Option(pages)))
|
||||
}
|
||||
else None
|
||||
}.collectFirst {
|
||||
case Some(handler) => handler
|
||||
}.getOrElse(this)
|
||||
}
|
||||
else this
|
||||
}
|
||||
|
||||
private def getCallbacks(env: Class[_]) = if (env != null) {
|
||||
Callbacks.fromClass(env).map {
|
||||
case (name, callback) =>
|
||||
val doc = callback.annotation.doc
|
||||
if (Strings.isNullOrEmpty(doc)) name
|
||||
else {
|
||||
val (signature, documentation) = doc match {
|
||||
case DocPattern(head, tail) => (name + head, tail)
|
||||
case VexPattern(head, tail) => (name + head, tail)
|
||||
case _ => (name, doc)
|
||||
}
|
||||
wrap(signature, 160).map(EnumChatFormatting.BLACK.toString + _).mkString("\n") +
|
||||
EnumChatFormatting.RESET + "\n" +
|
||||
wrap(documentation, 152).map(" " + _).mkString("\n")
|
||||
}
|
||||
}
|
||||
}
|
||||
else Seq.empty
|
||||
}
|
||||
@ -1,109 +0,0 @@
|
||||
package li.cil.oc.integration.nei
|
||||
|
||||
import java.util
|
||||
|
||||
import codechicken.lib.gui.GuiDraw
|
||||
import codechicken.nei.PositionedStack
|
||||
import codechicken.nei.recipe.GuiRecipe
|
||||
import codechicken.nei.recipe.IUsageHandler
|
||||
import com.google.common.base.Strings
|
||||
import li.cil.oc.api.driver.EnvironmentAware
|
||||
import li.cil.oc.server.driver.Registry
|
||||
import li.cil.oc.server.machine.Callbacks
|
||||
import net.minecraft.client.gui.inventory.GuiContainer
|
||||
import net.minecraft.inventory.Container
|
||||
import net.minecraft.item.ItemStack
|
||||
import net.minecraft.util.EnumChatFormatting
|
||||
|
||||
import scala.collection.convert.WrapAsScala._
|
||||
|
||||
class DocumentationHandler(val pages: Option[Array[String]]) extends IUsageHandler {
|
||||
def this() = this(None)
|
||||
|
||||
private val DocPattern = """^function(\([^)]*\)[^-]*) -- (.*)$""".r
|
||||
|
||||
private val VexPattern = """^function(\([^)]*\)[^-]*); (.*)$""".r
|
||||
|
||||
private def wrap(line: String, width: Int) = GuiDraw.fontRenderer.listFormattedStringToWidth(line, width)
|
||||
|
||||
override def getUsageHandler(input: String, ingredients: AnyRef*): IUsageHandler = {
|
||||
if (input == "item") {
|
||||
ingredients.collect {
|
||||
case stack: ItemStack if stack.getItem != null =>
|
||||
def getCallbacks(env: Class[_]) = if (env != null) {
|
||||
Callbacks.fromClass(env).map {
|
||||
case (name, callback) =>
|
||||
val doc = callback.annotation.doc
|
||||
if (Strings.isNullOrEmpty(doc)) name
|
||||
else {
|
||||
val (signature, documentation) = doc match {
|
||||
case DocPattern(head, tail) => (name + head, tail)
|
||||
case VexPattern(head, tail) => (name + head, tail)
|
||||
case _ => (name, doc)
|
||||
}
|
||||
wrap(signature, 160).map(EnumChatFormatting.BLACK.toString + _).mkString("\n") +
|
||||
EnumChatFormatting.RESET + "\n" +
|
||||
wrap(documentation, 152).map(" " + _).mkString("\n")
|
||||
}
|
||||
}
|
||||
}
|
||||
else Seq.empty
|
||||
|
||||
val callbacks = Option(Registry.driverFor(stack)) match {
|
||||
case Some(driver: EnvironmentAware) =>
|
||||
getCallbacks(driver.providedEnvironment(stack))
|
||||
case _ => Registry.blocks.collect {
|
||||
case driver: EnvironmentAware => driver.providedEnvironment(stack)
|
||||
}.filter(_ != null).map(getCallbacks).flatten
|
||||
}
|
||||
|
||||
if (callbacks.size > 0) {
|
||||
val fullDocumentation = callbacks.toArray.sorted.mkString("\n\n")
|
||||
val pages = fullDocumentation.lines.grouped(12).map(_.mkString("\n")).toArray
|
||||
return new DocumentationHandler(Option(pages))
|
||||
}
|
||||
}
|
||||
}
|
||||
this
|
||||
}
|
||||
|
||||
override def getRecipeName = "OpenComputers API"
|
||||
|
||||
override def recipiesPerPage = 1
|
||||
|
||||
override def numRecipes = pages.fold(0)(_.length)
|
||||
|
||||
override def drawBackground(recipe: Int) {}
|
||||
|
||||
override def drawForeground(recipe: Int) {
|
||||
pages match {
|
||||
case Some(data) =>
|
||||
for ((text, line) <- data(recipe).lines.zipWithIndex) {
|
||||
GuiDraw.drawString(text, 4, 4 + line * 10, 0x333333, false)
|
||||
}
|
||||
case _ =>
|
||||
}
|
||||
}
|
||||
|
||||
override def getIngredientStacks(recipe: Int) = new util.ArrayList[PositionedStack]()
|
||||
|
||||
override def getOtherStacks(recipe: Int) = new util.ArrayList[PositionedStack]()
|
||||
|
||||
override def getResultStack(recipe: Int) = null
|
||||
|
||||
override def onUpdate() {}
|
||||
|
||||
override def hasOverlay(gui: GuiContainer, container: Container, recipe: Int) = false
|
||||
|
||||
override def getOverlayHandler(gui: GuiContainer, recipe: Int) = null
|
||||
|
||||
override def getOverlayRenderer(gui: GuiContainer, recipe: Int) = null
|
||||
|
||||
override def handleTooltip(gui: GuiRecipe, tooltip: util.List[String], recipe: Int) = tooltip
|
||||
|
||||
override def handleItemTooltip(gui: GuiRecipe, stack: ItemStack, tooltip: util.List[String], recipe: Int) = tooltip
|
||||
|
||||
override def keyTyped(gui: GuiRecipe, char: Char, code: Int, recipe: Int) = false
|
||||
|
||||
override def mouseClicked(gui: GuiRecipe, x: Int, y: Int) = false
|
||||
}
|
||||
@ -0,0 +1,28 @@
|
||||
package li.cil.oc.integration.nei
|
||||
|
||||
import li.cil.oc.Localization
|
||||
import li.cil.oc.api
|
||||
import codechicken.nei.recipe.IUsageHandler
|
||||
import net.minecraft.item.ItemStack
|
||||
|
||||
import scala.collection.convert.WrapAsScala._
|
||||
|
||||
class GeneralUsageHandler(pages: Option[Array[String]]) extends PagedUsageHandler(pages) {
|
||||
def this() = this(None)
|
||||
|
||||
override def getRecipeName = "Manual"
|
||||
|
||||
override def getUsageHandler(input: String, ingredients: AnyRef*): IUsageHandler = {
|
||||
if (input == "item") {
|
||||
ingredients.collectFirst {
|
||||
case stack: ItemStack if api.Items.get(stack) != null && Localization.canLocalize(usageKey(stack)) =>
|
||||
val fullDocumentation = wrap(Localization.localizeImmediately(usageKey(stack)).replaceAllLiterally("[nl]", "\n"), 160).mkString("\n")
|
||||
val pages = fullDocumentation.lines.grouped(12).map(_.mkString("\n")).toArray
|
||||
new GeneralUsageHandler(Option(pages))
|
||||
}.getOrElse(this)
|
||||
}
|
||||
else this
|
||||
}
|
||||
|
||||
private def usageKey(stack: ItemStack) = stack.getUnlocalizedName.stripSuffix(".name").replaceFirst("""\d+$""", "") + ".usage"
|
||||
}
|
||||
@ -14,7 +14,11 @@ class NEIOpenComputersConfig extends IConfigureNEI {
|
||||
override def getVersion = "1.0.0"
|
||||
|
||||
override def loadConfig() {
|
||||
API.registerUsageHandler(new DocumentationHandler())
|
||||
// Non-alphabetic order haunts my OCD, but I want the "Manual" to show up
|
||||
// before the API doc.
|
||||
API.registerUsageHandler(new GeneralUsageHandler())
|
||||
API.registerUsageHandler(new CallbackDocHandler())
|
||||
|
||||
for (block <- NEI.hiddenBlocks) {
|
||||
API.hideItem(new ItemStack(block))
|
||||
}
|
||||
|
||||
@ -0,0 +1,53 @@
|
||||
package li.cil.oc.integration.nei
|
||||
|
||||
import java.util
|
||||
|
||||
import codechicken.lib.gui.GuiDraw
|
||||
import codechicken.nei.PositionedStack
|
||||
import codechicken.nei.recipe.GuiRecipe
|
||||
import codechicken.nei.recipe.IUsageHandler
|
||||
import net.minecraft.client.gui.inventory.GuiContainer
|
||||
import net.minecraft.inventory.Container
|
||||
import net.minecraft.item.ItemStack
|
||||
|
||||
abstract class PagedUsageHandler(val pages: Option[Array[String]]) extends IUsageHandler {
|
||||
protected def wrap(line: String, width: Int) = GuiDraw.fontRenderer.listFormattedStringToWidth(line, width)
|
||||
|
||||
override def recipiesPerPage = 1
|
||||
|
||||
override def numRecipes = pages.fold(0)(_.length)
|
||||
|
||||
override def drawForeground(recipe: Int) {
|
||||
pages match {
|
||||
case Some(data) =>
|
||||
for ((text, line) <- data(recipe).lines.zipWithIndex) {
|
||||
GuiDraw.drawString(text, 4, 4 + line * 10, 0x333333, false)
|
||||
}
|
||||
case _ =>
|
||||
}
|
||||
}
|
||||
|
||||
override def drawBackground(recipe: Int) {}
|
||||
|
||||
override def getIngredientStacks(recipe: Int) = new util.ArrayList[PositionedStack]()
|
||||
|
||||
override def getOtherStacks(recipe: Int) = new util.ArrayList[PositionedStack]()
|
||||
|
||||
override def getResultStack(recipe: Int) = null
|
||||
|
||||
override def onUpdate() {}
|
||||
|
||||
override def hasOverlay(gui: GuiContainer, container: Container, recipe: Int) = false
|
||||
|
||||
override def getOverlayHandler(gui: GuiContainer, recipe: Int) = null
|
||||
|
||||
override def getOverlayRenderer(gui: GuiContainer, recipe: Int) = null
|
||||
|
||||
override def handleTooltip(gui: GuiRecipe, tooltip: util.List[String], recipe: Int) = tooltip
|
||||
|
||||
override def handleItemTooltip(gui: GuiRecipe, stack: ItemStack, tooltip: util.List[String], recipe: Int) = tooltip
|
||||
|
||||
override def keyTyped(gui: GuiRecipe, char: Char, code: Int, recipe: Int) = false
|
||||
|
||||
override def mouseClicked(gui: GuiRecipe, x: Int, y: Int) = false
|
||||
}
|
||||
Loading…
x
Reference in New Issue
Block a user