reference.conf - minecraft/opencomputers - Rivoreo Source Code Repositories

 # OpenComputers configuration. This file uses typesafe config's HOCON syntax.
 # Try setting your syntax highlighting to YAML, to help readability. At least
 # in Sublime Text that works really well.
 opencomputers {

   ids {
     # The item ID used for all non-damageable items.
     item: 4600

     # List of block IDs the mod uses for different types of blocks. This list
     # must contain exactly four entries, or it will be ignored.
     block: [
         3650
         3651
         3652
         3653
     ]
   }

   # Client side settings, presentation and performance related stuff.
   client {
       # The distance at which to start fading out the text on screens. This is
       # purely cosmetic, to avoid text disappearing instantly when moving too
       # far away from a screen. This should have no measurable impact on
       # performance. Note that this needs OpenGL 1.4 to work, otherwise text
       # will always just instantly disappear when moving away from the screen
       # displaying it.
       screenTextFadeStartDistance: 8.0

       # The maximum distance at which to render text on screens. Rendering text
       # can be pretty expensive, so if you have a lot of screens you'll want to
       # avoid huge numbers here. Note that this setting is client-sided, and
       # only has an impact on render performance on clients.
       maxScreenTextRenderDistance: 10.0

       # Whether to apply linear filtering for text displayed on screens when the
       # screen has to be scaled down - i.e. the text is rendered at a resolution
       # lower than their native one, e.g. when the GUI scale is less than one or
       # when looking at a far away screen. This leads to smoother text for
       # scaled down text but results in characters not perfectly connecting
       # anymore (for example for box drawing characters. Look it up on
       # Wikipedia.)
       textLinearFiltering: false
   }

   # Computer related settings, concerns server performance and security.
   computer {
       # The overall number of threads to use to drive computers. Whenever a
       # computer should run, for example because a signal should be processed or
       # some sleep timer expired it is queued for execution by a worker thread.
       # The higher the number of worker threads, the less likely it will be that
       # computers block each other from running, but the higher the host
       # system's load may become.
       threads: 4

       # The time in seconds a program may run without yielding before it is
       # forcibly aborted. This is used to avoid stupidly written or malicious
       # programs blocking other computers by locking down the executor threads.
       # Note that changing this won't have any effect on computers that are
       # already running - they'll have to be rebooted for this to take effect.
       timeout: 1.0

       # The time in seconds to wait after a computer has been restored before it
       # continues to run. This is meant to allow the world around the computer
       # to settle, avoiding issues such as components in neighboring chunks
       # being removed and then re-connected and other odd things that might
       # happen.
       startupDelay: 0.25

       # The sizes of the three tiers of RAM, in kilobytes. This list must
       # contain exactly three entries, or it will be ignored.
       ramSizes: [
           64
           128
           256
       ]

       # This determines whether computers can only be used by players that are
       # registered as users on them. Per default a newly placed computer has no
       # users. Whenever there are no users the computer is free for all. Users
       # can be managed via the Lua API (os.addUser, os.removeUser, os.users). If
       # this is true, the following interactions are only possible for users:
       # - input via the keyboard.
       # - inventory management.
       # - breaking the computer block.
       # If this is set to false, all computers will always be usable by all
       # players, no matter the contents of the user list. Note that operators
       # are treated as if they were in the user list of every computer, i.e. no
       # restrictions apply to them.
       # See also: `maxUsers` and `maxUsernameLength`.
       canComputersBeOwned: true

       # The maximum number of users that can be registered with a single
       # computer. This is used to avoid computers allocating unchecked amounts
       # of memory by registering an unlimited number of users. See also:
       # `canComputersBeOwned`.
       maxUsers: 16

       # Sanity check for username length for users registered with computers. We
       # store the actual user names instead of a hash to allow iterating the
       # list of registered users on the Lua side.
       # See also: `canComputersBeOwned`.
       maxUsernameLength: 32
   }

   # Robot related settings, what they may do and general balancing.
   robot {
       # Whether robots may place blocks in thin air, i.e. without a reference
       # point (as is required for real players). Set this to true to emulate
       # ComputerCraft's Turtles' behavior. When left false robots have to target
       # an existing block face to place another block. For example, if the
       # robots stands on a perfect plane, you have to call
       # `robot.place(sides.down)` to place a block, instead of just
       # `robot.place()`, which will default to `robot.place(sides.front)`.
       canPlaceInAir: false

       # Whether robots may 'activate' blocks in the world. This includes
       # pressing buttons and flipping levers, for example. Disable this if it
       # causes problems with some mod (but let me know!) or if you think this
       # feature is too over-powered.
       allowActivateBlocks: true

       # Whether robots may use items for a specifiable duration. This allows
       # robots to use items such as bows, for which the right mouse button has
       # to be held down for a longer period of time. For robots this works
       # slightly different: the item is told it was used for the specified
       # duration immediately, but the robot will not resume execution until the
       # time that the item was supposedly being used has elapsed. This way
       # robots cannot rapidly fire critical shots with a bow, for example.
       allowUseItemsWithDuration: true

       # Whether robots may damage players if they get in their way. This
       # includes all 'player' entities, which may be more than just real players
       # in the game.
       canAttackPlayers: false

       # The 'range' of robots when swinging an equipped tool (left click). This
       # is the distance to the center of block the robot swings the tool in to
       # the side the tool is swung towards. I.e. for the collision check, which
       # is performed via ray tracing, this determines the end point of the ray
       # like so:
       # `block_center + unit_vector_towards_side * swingRange`
       # This defaults to a value just below 0.5 to ensure the robots will not
       # hit anything that's actually outside said block.
       swingRange: 0.49

       # The 'range' of robots when using an equipped tool (right click) or when
       # placing items from their inventory. See `robot.swingRange`. This
       # defaults to a value large enough to allow robots to detect 'farmland',
       # i.e. tilled dirt, so that they can plant seeds.
       useAndPlaceRange: 0.65

       # The rate at which items used as tools by robots take damage. A value of
       # one means that items lose durability as quickly as when they are used by
       # a real player. A value of zero means they will not lose any durability
       # at all. This only applies to items that can actually be damaged (such as
       # swords, pickaxes, axes and shovels).
       # Note that this actually is the *chance* of an item losing durability
       # when it is used. Or in other words, it's the inverse chance that the
       # item will be automatically repaired for the damage it just took
       # immediately after it was used.
       itemDamageRate: 0.05

       # The name format to use for robots. The substring '$player$' is
       # replaced with the name of the player that owns the robot, so for the
       # first robot placed this will be the name of the player that placed it.
       # This is transitive, i.e. when a robot in turn places a robot, that
       # robot's owner, too will be the owner of the placing robot.
       # The substring $random$ will be replaced with a random number in the
       # interval [1, 0xFFFFFF], which may be useful if you need to differentiate
       # individual robots.
       # If a robot is placed by something that is not a player, e.g. by some
       # block from another mod, the name will default to 'OpenComputers'.
       nameFormat: "$player$.robot"

       delays {
           # The time in seconds to pause execution after a robot turned either
           # left or right. Note that this essentially determines hw fast robots
           # can turn around, since this also determines the length of the turn
           # animation.
           turn: 0.4

           # The time in seconds to pause execution after a robot issued a
           # successful move command. Note that this essentially determines how
           # fast robots can move around, since this also determines the length
           # of the move animation.
           move: 0.4

           # The time in seconds to pause execution after a robot successfully
           # swung a tool (or it's 'hands' if nothing is equipped). Successful in
           # this case means that it hit something, either by attacking an entity
           # or by breaking a block.
           swing: 0.4

           # The time in seconds to pause execution after a robot successfully
           # used an equipped tool (or it's 'hands' if nothing is equipped).
           # Successful in this case means that it either used the equipped item,
           # for example bone meal, or that it activated a block, for example by
           # pushing a button.
           # Note that if an item is used for a specific amount of time, like
           # when shooting a bow, the maximum of this and the duration of the
           # item use is taken.
           use: 0.4

           # The time in seconds to pause execution after a robot successfully
           # placed an item from its inventory.
           place: 0.4

           # The time in seconds to pause execution after an item was
           # successfully dropped from a robot's inventory.
           drop: 0.1

           # The time in seconds to pause execution after a robot successfully
           # picked up an item after triggering a suck command.
           suck: 0.1
       }
   }

   # Power settings, buffer sizes and power consumption.
   power {
       # Whether to ignore any power requirements. Whenever something requires
       # power to function, it will try to get the amount of energy it needs from
       # the buffer of its connector node, and in case it fails it won't perform
       # the action / trigger a shutdown / whatever. Setting this to `true` will
       # simply make the check 'is there enough energy' succeed unconditionally.
       # Note that buffers are still filled and emptied following the usual
       # rules, there just is no failure case anymore. The converter will however
       # not accept power from other mods.
       ignorePower: false

       # Conversion ratio for BuildCraft's MJ. This is how many internal energy
       # units one MJ generates.
       ratioBuildCraft: 5.0

       # Conversion ratio for IndustrialCraft2's EU. This is how many internal
       # energy units one EU generates.
       ratioIndustrialCraft2: 2.0

       # Conversion ratio for Universal Electricity's Joules. This is how many
       # internal energy units one Joule generates.
       ratioUniversalElectricity: 5.0

       buffer {
           # The amount of energy a single capacitor can store.
           capacitor: 8000.0

           # The amount of bonus energy a capacitor can store for each other
           # capacitor it shares a face with. This bonus applies to both of the
           # involved capacitors. It reaches a total of two blocks, where the
           # bonus is halved for the second neighbor. So three capacitors in a
           # row will give a total of 44k storage with default values:
           # (8 + 4 + 2)k + (4 + 8 + 4)k + (2 + 4 + 8)k
           capacitorAdjacencyBonus: 4000.0

           # The amount of power robots can store in their internal buffer.
           robot: 1000000.0
       }

       cost {
           # The amount of energy a computer consumes per tick when running.
           computer: 1.0

           # The amount of energy a robot consumes per tick when running. This is
           # per default less than a normal computer uses because... well... they
           # are better optimized? It balances out due to the cost for movement,
           # interaction and whatnot, and the fact that robots cannot connect to
           # component networks directly, so they are no replacements for normal
           # computers.
           robot: 0.5

           # The actual cost per tick for computers and robots is multiplied
           # with this value if they are currently in a "sleeping" state. They
           # enter this state either by calling `os.sleep()` or by pulling
           # signals. Note that this does not apply in the tick they resume, so
           # you can't fake sleep by calling `os.sleep(0)`.
           sleepFactor: 0.25

           # The amount of energy a screen consumes per displayed character per
           # tick. If a screen cannot consume the defined amount of energy it
           # will stop rendering the text that should be displayed on it. It will
           # *not* forget that text, however, so when enough power is available
           # again it will restore the previously displayed text (with any
           # changes possibly made in the meantime). Note that for multi-block
           # screens *each* screen that is part of it will consume this amount of
           # energy per tick.
           screen: 0.1

           # Energy it takes read a single byte from a file system. Note that non
           # I/O operations on file systems such as `list` or `getFreeSpace` do
           # *not* consume power.
           hddRead: 0.000625

           # Energy it takes to write a single byte to a file system.
           hddWrite: 0.00125

           # Energy it takes to change a single 'pixel' via the set command. For
           # calls to set with a string, this means the total cost will be the
           # string length times this.
           gpuSet: 0.0125

           # Energy it takes to change a single 'pixel' via the fill command.
           # This means the total cost of the fill command will be its area times
           # this.
           gpuFill: 0.01

           # Energy it takes to change a single 'pixel' to blank using the fill
           # command. This means the total cost of the fill command will be its
           # area times this.
           gpuClear: 0.0025

           # Energy it takes to move a single 'pixel' via the copy command. This
           # means the total cost of the copy command will be its area times
           # this.
           gpuCopy: 0.0050

           # The amount of energy it takes a robot to perform a 90 degree turn.
           robotTurn: 5.0

           # The amount of energy it takes a robot to move a single block.
           robotMove: 40.0

           # The conversion rate of exhaustion from using items to energy
           # consumed. Zero means exhaustion does not require energy, one is a
           # one to one conversion. For example, breaking a block generates 0.025
           # exhaustion, attacking an entity generates 0.3 exhaustion.
           robotExhaustion: 1.0

           # The amount of energy it costs to send a signal with strength one,
           # which means the signal reaches one block. This is scaled up
           # linearly, so for example to send a signal 400 blocks a signal
           # strength of 400 is required, costing a total of 400 *
           # `wirelessCostPerRange`. In other words, the higher this value, the
           # higher the cost of wireless messages.
           # See also: `maxWirelessRange`.
           wirelessStrength: 0.05
       }
   }

   # File system related settings, performance and and balancing.
   filesystem {
       # Whether persistent file systems such as disk drivers should be
       # 'buffered', and only written to disk when the world is saved. This
       # applies to all hard drives. The advantage of having this enabled is that
       # data will never go 'out of sync' with the computer's state if the game
       # crashes. The price is slightly higher memory consumption, since all
       # loaded files have to be kept in memory (loaded as in when the hard drive
       # is in a computer).
       bufferChanges: true

       # The base 'cost' of a single file or directory on a limited file system,
       # such as hard drives. When computing the used space we add this cost to
       # the real size of each file (and folders, which are zero sized
       # otherwise). This is to ensure that users cannot spam the file system
       # with an infinite number of files and/or folders. Note that the size
       # returned via the API will always be the real file size, however.
       fileCost: 512

       # The sizes of the three tiers of hard drives, in kilobytes. This list
       # must contain exactly three entries, or it will be ignored.
       hddSizes: [
           2048
           4096
           8192
       ]

       # The maximum number of file handles any single computer may have open at
       # a time. Note that this is *per filesystem*. Also note that this is only
       # enforced by the filesystem node - if an add-on decides to be fancy it
       # may well ignore this. Since file systems are usually 'virtual' this will
       # usually not have any real impact on performance and won't be noticeable
       # on the host operating system.
       maxHandles: 16

       # The maximum block size that can be read in one 'read' call on a file
       # system. This is used to limit the amount of memory a call from a user
       # program can cause to be allocated on the host side: when 'read' is,
       # called a byte array with the specified size has to be allocated. So if
       # this weren't limited, a Lua program could trigger massive memory
       # allocations regardless of the amount of RAM installed in the computer it
       # runs on. As a side effect this pretty much determines the read
       # performance of file systems.
       maxReadBuffer: 8192
   }

   # HTTP settings, security related.
   http {
       # Whether to allow HTTP requests via wireless network cards. When enabled,
       # pass a URL to `send`, to perform an HTTP request. The second parameter
       # becomes an optional string to send as POST data. When the request
       # finishes, it will push a signal named `http_response`. If the request
       # cannot be performed because the URL is not allowed or this is disabled
       # the card will fall back to the normal send logic.
       enable: true

       # The number of threads used for processing HTTP requests in the
       # background. The more there are, the more concurrent connections can
       # potentially be opened by computers, and the less likely they are to
       # delay each other.
       threads: 4

       # This is a list of blacklisted domain names. If an HTTP request is made
       # and the host name (domain) of the target URL matches any of the patterns
       # in this list, the request will be denied.
       # All entries are regular expression patterns, but they will only be
       # applied to the host name (domain) of a given URL.
       blacklist: [
           "127\\.0\\.0\\.1"
           "10\\.\\d+\\.\\d+\\.\\d+"
           "192\\.\\d+\\.\\d+\\.\\d+"
       ]

       # This is a list of whitelisted domain names. Requests may only be made to
       # domains that match any pattern in this list. If this list is empty,
       # requests may be made to all domains not blacklisted. Note that the
       # blacklist is always applied, so if an entry is present in both the
       # whitelist and the blacklist, the blacklist will win.
       # All entries are regular expression patterns, but they will only be
       # applied to the host name (domain) of a given URL.
       whitelist: [
           "gist\\.github\\.com"
           "pastebin\\.com"
       ]
   }

   # Other settings that you might find useful to tweak.
   misc {
       # The maximum width of multi-block screens, in blocks.
       # See also: `maxScreenHeight`.
       maxScreenWidth: 8

       # The maximum height of multi-block screens, in blocks. This is limited to
       # avoid excessive computations for merging screens. If you really need
       # bigger screens it's probably safe to bump this quite a bit before you
       # notice anything, since at least incremental updates should be very
       # efficient (i.e. when adding/removing a single screen).
       maxScreenHeight: 6

       # The maximum length of a string that may be pasted. This is used to limit
       # the size of the data sent to the server when the user tries to paste a
       # string from the clipboard (Shift+Ins on a screen with a keyboard).
       maxClipboard: 1024

       # The maximum distance a wireless message can be sent. In other words,
       # this is the maximum signal strength a wireless network card supports.
       # This is used to limit the search range in which to check for modems,
       # which may or may not lead to performance issues for ridiculous ranges -
       # like, you know, more than the loaded area.
       # See also: `wirelessCostPerRange`.
       maxWirelessRange: 400

       # The user name to specify when executing a command via a command block.
       # If you leave this empty it will use the address of the network node that
       # sent the execution request - which will usually be a computer.
       commandUser: OpenComputers
   }
 }
	# OpenComputers configuration. This file uses typesafe config's HOCON syntax.
	# Try setting your syntax highlighting to YAML, to help readability. At least
	# in Sublime Text that works really well.
	opencomputers {

	ids {
	# The item ID used for all non-damageable items.
	item: 4600

	# List of block IDs the mod uses for different types of blocks. This list
	# must contain exactly four entries, or it will be ignored.
	block: [
	3650
	3651
	3652
	3653
	]
	}

	# Client side settings, presentation and performance related stuff.
	client {
	# The distance at which to start fading out the text on screens. This is
	# purely cosmetic, to avoid text disappearing instantly when moving too
	# far away from a screen. This should have no measurable impact on
	# performance. Note that this needs OpenGL 1.4 to work, otherwise text
	# will always just instantly disappear when moving away from the screen
	# displaying it.
	screenTextFadeStartDistance: 8.0

	# The maximum distance at which to render text on screens. Rendering text
	# can be pretty expensive, so if you have a lot of screens you'll want to
	# avoid huge numbers here. Note that this setting is client-sided, and
	# only has an impact on render performance on clients.
	maxScreenTextRenderDistance: 10.0

	# Whether to apply linear filtering for text displayed on screens when the
	# screen has to be scaled down - i.e. the text is rendered at a resolution
	# lower than their native one, e.g. when the GUI scale is less than one or
	# when looking at a far away screen. This leads to smoother text for
	# scaled down text but results in characters not perfectly connecting
	# anymore (for example for box drawing characters. Look it up on
	# Wikipedia.)
	textLinearFiltering: false
	}

	# Computer related settings, concerns server performance and security.
	computer {
	# The overall number of threads to use to drive computers. Whenever a
	# computer should run, for example because a signal should be processed or
	# some sleep timer expired it is queued for execution by a worker thread.
	# The higher the number of worker threads, the less likely it will be that
	# computers block each other from running, but the higher the host
	# system's load may become.
	threads: 4

	# The time in seconds a program may run without yielding before it is
	# forcibly aborted. This is used to avoid stupidly written or malicious
	# programs blocking other computers by locking down the executor threads.
	# Note that changing this won't have any effect on computers that are
	# already running - they'll have to be rebooted for this to take effect.
	timeout: 1.0

	# The time in seconds to wait after a computer has been restored before it
	# continues to run. This is meant to allow the world around the computer
	# to settle, avoiding issues such as components in neighboring chunks
	# being removed and then re-connected and other odd things that might
	# happen.
	startupDelay: 0.25

	# The sizes of the three tiers of RAM, in kilobytes. This list must
	# contain exactly three entries, or it will be ignored.
	ramSizes: [
	64
	128
	256
	]

	# This determines whether computers can only be used by players that are
	# registered as users on them. Per default a newly placed computer has no
	# users. Whenever there are no users the computer is free for all. Users
	# can be managed via the Lua API (os.addUser, os.removeUser, os.users). If
	# this is true, the following interactions are only possible for users:
	# - input via the keyboard.
	# - inventory management.
	# - breaking the computer block.
	# If this is set to false, all computers will always be usable by all
	# players, no matter the contents of the user list. Note that operators
	# are treated as if they were in the user list of every computer, i.e. no
	# restrictions apply to them.
	# See also: `maxUsers` and `maxUsernameLength`.
	canComputersBeOwned: true

	# The maximum number of users that can be registered with a single
	# computer. This is used to avoid computers allocating unchecked amounts
	# of memory by registering an unlimited number of users. See also:
	# `canComputersBeOwned`.
	maxUsers: 16

	# Sanity check for username length for users registered with computers. We
	# store the actual user names instead of a hash to allow iterating the
	# list of registered users on the Lua side.
	# See also: `canComputersBeOwned`.
	maxUsernameLength: 32
	}

	# Robot related settings, what they may do and general balancing.
	robot {
	# Whether robots may place blocks in thin air, i.e. without a reference
	# point (as is required for real players). Set this to true to emulate
	# ComputerCraft's Turtles' behavior. When left false robots have to target
	# an existing block face to place another block. For example, if the
	# robots stands on a perfect plane, you have to call
	# `robot.place(sides.down)` to place a block, instead of just
	# `robot.place()`, which will default to `robot.place(sides.front)`.
	canPlaceInAir: false

	# Whether robots may 'activate' blocks in the world. This includes
	# pressing buttons and flipping levers, for example. Disable this if it
	# causes problems with some mod (but let me know!) or if you think this
	# feature is too over-powered.
	allowActivateBlocks: true

	# Whether robots may use items for a specifiable duration. This allows
	# robots to use items such as bows, for which the right mouse button has
	# to be held down for a longer period of time. For robots this works
	# slightly different: the item is told it was used for the specified
	# duration immediately, but the robot will not resume execution until the
	# time that the item was supposedly being used has elapsed. This way
	# robots cannot rapidly fire critical shots with a bow, for example.
	allowUseItemsWithDuration: true

	# Whether robots may damage players if they get in their way. This
	# includes all 'player' entities, which may be more than just real players
	# in the game.
	canAttackPlayers: false

	# The 'range' of robots when swinging an equipped tool (left click). This
	# is the distance to the center of block the robot swings the tool in to
	# the side the tool is swung towards. I.e. for the collision check, which
	# is performed via ray tracing, this determines the end point of the ray
	# like so:
	# `block_center + unit_vector_towards_side * swingRange`
	# This defaults to a value just below 0.5 to ensure the robots will not
	# hit anything that's actually outside said block.
	swingRange: 0.49

	# The 'range' of robots when using an equipped tool (right click) or when
	# placing items from their inventory. See `robot.swingRange`. This
	# defaults to a value large enough to allow robots to detect 'farmland',
	# i.e. tilled dirt, so that they can plant seeds.
	useAndPlaceRange: 0.65

	# The rate at which items used as tools by robots take damage. A value of
	# one means that items lose durability as quickly as when they are used by
	# a real player. A value of zero means they will not lose any durability
	# at all. This only applies to items that can actually be damaged (such as
	# swords, pickaxes, axes and shovels).
	# Note that this actually is the chance of an item losing durability
	# when it is used. Or in other words, it's the inverse chance that the
	# item will be automatically repaired for the damage it just took
	# immediately after it was used.
	itemDamageRate: 0.05

	# The name format to use for robots. The substring '$player$' is
	# replaced with the name of the player that owns the robot, so for the
	# first robot placed this will be the name of the player that placed it.
	# This is transitive, i.e. when a robot in turn places a robot, that
	# robot's owner, too will be the owner of the placing robot.
	# The substring $random$ will be replaced with a random number in the
	# interval [1, 0xFFFFFF], which may be useful if you need to differentiate
	# individual robots.
	# If a robot is placed by something that is not a player, e.g. by some
	# block from another mod, the name will default to 'OpenComputers'.
	nameFormat: "$player$.robot"

	delays {
	# The time in seconds to pause execution after a robot turned either
	# left or right. Note that this essentially determines hw fast robots
	# can turn around, since this also determines the length of the turn
	# animation.
	turn: 0.4

	# The time in seconds to pause execution after a robot issued a
	# successful move command. Note that this essentially determines how
	# fast robots can move around, since this also determines the length
	# of the move animation.
	move: 0.4

	# The time in seconds to pause execution after a robot successfully
	# swung a tool (or it's 'hands' if nothing is equipped). Successful in
	# this case means that it hit something, either by attacking an entity
	# or by breaking a block.
	swing: 0.4

	# The time in seconds to pause execution after a robot successfully
	# used an equipped tool (or it's 'hands' if nothing is equipped).
	# Successful in this case means that it either used the equipped item,
	# for example bone meal, or that it activated a block, for example by
	# pushing a button.
	# Note that if an item is used for a specific amount of time, like
	# when shooting a bow, the maximum of this and the duration of the
	# item use is taken.
	use: 0.4

	# The time in seconds to pause execution after a robot successfully
	# placed an item from its inventory.
	place: 0.4

	# The time in seconds to pause execution after an item was
	# successfully dropped from a robot's inventory.
	drop: 0.1

	# The time in seconds to pause execution after a robot successfully
	# picked up an item after triggering a suck command.
	suck: 0.1
	}
	}

	# Power settings, buffer sizes and power consumption.
	power {
	# Whether to ignore any power requirements. Whenever something requires
	# power to function, it will try to get the amount of energy it needs from
	# the buffer of its connector node, and in case it fails it won't perform
	# the action / trigger a shutdown / whatever. Setting this to `true` will
	# simply make the check 'is there enough energy' succeed unconditionally.
	# Note that buffers are still filled and emptied following the usual
	# rules, there just is no failure case anymore. The converter will however
	# not accept power from other mods.
	ignorePower: false

	# Conversion ratio for BuildCraft's MJ. This is how many internal energy
	# units one MJ generates.
	ratioBuildCraft: 5.0

	# Conversion ratio for IndustrialCraft2's EU. This is how many internal
	# energy units one EU generates.
	ratioIndustrialCraft2: 2.0

	# Conversion ratio for Universal Electricity's Joules. This is how many
	# internal energy units one Joule generates.
	ratioUniversalElectricity: 5.0

	buffer {
	# The amount of energy a single capacitor can store.
	capacitor: 8000.0

	# The amount of bonus energy a capacitor can store for each other
	# capacitor it shares a face with. This bonus applies to both of the
	# involved capacitors. It reaches a total of two blocks, where the
	# bonus is halved for the second neighbor. So three capacitors in a
	# row will give a total of 44k storage with default values:
	# (8 + 4 + 2)k + (4 + 8 + 4)k + (2 + 4 + 8)k
	capacitorAdjacencyBonus: 4000.0

	# The amount of power robots can store in their internal buffer.
	robot: 1000000.0
	}

	cost {
	# The amount of energy a computer consumes per tick when running.
	computer: 1.0

	# The amount of energy a robot consumes per tick when running. This is
	# per default less than a normal computer uses because... well... they
	# are better optimized? It balances out due to the cost for movement,
	# interaction and whatnot, and the fact that robots cannot connect to
	# component networks directly, so they are no replacements for normal
	# computers.
	robot: 0.5

	# The actual cost per tick for computers and robots is multiplied
	# with this value if they are currently in a "sleeping" state. They
	# enter this state either by calling `os.sleep()` or by pulling
	# signals. Note that this does not apply in the tick they resume, so
	# you can't fake sleep by calling `os.sleep(0)`.
	sleepFactor: 0.25

	# The amount of energy a screen consumes per displayed character per
	# tick. If a screen cannot consume the defined amount of energy it
	# will stop rendering the text that should be displayed on it. It will
	# not forget that text, however, so when enough power is available
	# again it will restore the previously displayed text (with any
	# changes possibly made in the meantime). Note that for multi-block
	# screens each screen that is part of it will consume this amount of
	# energy per tick.
	screen: 0.1

	# Energy it takes read a single byte from a file system. Note that non
	# I/O operations on file systems such as `list` or `getFreeSpace` do
	# not consume power.
	hddRead: 0.000625

	# Energy it takes to write a single byte to a file system.
	hddWrite: 0.00125

	# Energy it takes to change a single 'pixel' via the set command. For
	# calls to set with a string, this means the total cost will be the
	# string length times this.
	gpuSet: 0.0125

	# Energy it takes to change a single 'pixel' via the fill command.
	# This means the total cost of the fill command will be its area times
	# this.
	gpuFill: 0.01

	# Energy it takes to change a single 'pixel' to blank using the fill
	# command. This means the total cost of the fill command will be its
	# area times this.
	gpuClear: 0.0025

	# Energy it takes to move a single 'pixel' via the copy command. This
	# means the total cost of the copy command will be its area times
	# this.
	gpuCopy: 0.0050

	# The amount of energy it takes a robot to perform a 90 degree turn.
	robotTurn: 5.0

	# The amount of energy it takes a robot to move a single block.
	robotMove: 40.0

	# The conversion rate of exhaustion from using items to energy
	# consumed. Zero means exhaustion does not require energy, one is a
	# one to one conversion. For example, breaking a block generates 0.025
	# exhaustion, attacking an entity generates 0.3 exhaustion.
	robotExhaustion: 1.0

	# The amount of energy it costs to send a signal with strength one,
	# which means the signal reaches one block. This is scaled up
	# linearly, so for example to send a signal 400 blocks a signal
	# strength of 400 is required, costing a total of 400 *
	# `wirelessCostPerRange`. In other words, the higher this value, the
	# higher the cost of wireless messages.
	# See also: `maxWirelessRange`.
	wirelessStrength: 0.05
	}
	}

	# File system related settings, performance and and balancing.
	filesystem {
	# Whether persistent file systems such as disk drivers should be
	# 'buffered', and only written to disk when the world is saved. This
	# applies to all hard drives. The advantage of having this enabled is that
	# data will never go 'out of sync' with the computer's state if the game
	# crashes. The price is slightly higher memory consumption, since all
	# loaded files have to be kept in memory (loaded as in when the hard drive
	# is in a computer).
	bufferChanges: true

	# The base 'cost' of a single file or directory on a limited file system,
	# such as hard drives. When computing the used space we add this cost to
	# the real size of each file (and folders, which are zero sized
	# otherwise). This is to ensure that users cannot spam the file system
	# with an infinite number of files and/or folders. Note that the size
	# returned via the API will always be the real file size, however.
	fileCost: 512

	# The sizes of the three tiers of hard drives, in kilobytes. This list
	# must contain exactly three entries, or it will be ignored.
	hddSizes: [
	2048
	4096
	8192
	]

	# The maximum number of file handles any single computer may have open at
	# a time. Note that this is per filesystem. Also note that this is only
	# enforced by the filesystem node - if an add-on decides to be fancy it
	# may well ignore this. Since file systems are usually 'virtual' this will
	# usually not have any real impact on performance and won't be noticeable
	# on the host operating system.
	maxHandles: 16

	# The maximum block size that can be read in one 'read' call on a file
	# system. This is used to limit the amount of memory a call from a user
	# program can cause to be allocated on the host side: when 'read' is,
	# called a byte array with the specified size has to be allocated. So if
	# this weren't limited, a Lua program could trigger massive memory
	# allocations regardless of the amount of RAM installed in the computer it
	# runs on. As a side effect this pretty much determines the read
	# performance of file systems.
	maxReadBuffer: 8192
	}

	# HTTP settings, security related.
	http {
	# Whether to allow HTTP requests via wireless network cards. When enabled,
	# pass a URL to `send`, to perform an HTTP request. The second parameter
	# becomes an optional string to send as POST data. When the request
	# finishes, it will push a signal named `http_response`. If the request
	# cannot be performed because the URL is not allowed or this is disabled
	# the card will fall back to the normal send logic.
	enable: true

	# The number of threads used for processing HTTP requests in the
	# background. The more there are, the more concurrent connections can
	# potentially be opened by computers, and the less likely they are to
	# delay each other.
	threads: 4

	# This is a list of blacklisted domain names. If an HTTP request is made
	# and the host name (domain) of the target URL matches any of the patterns
	# in this list, the request will be denied.
	# All entries are regular expression patterns, but they will only be
	# applied to the host name (domain) of a given URL.
	blacklist: [
	"127\\.0\\.0\\.1"
	"10\\.\\d+\\.\\d+\\.\\d+"
	"192\\.\\d+\\.\\d+\\.\\d+"
	]

	# This is a list of whitelisted domain names. Requests may only be made to
	# domains that match any pattern in this list. If this list is empty,
	# requests may be made to all domains not blacklisted. Note that the
	# blacklist is always applied, so if an entry is present in both the
	# whitelist and the blacklist, the blacklist will win.
	# All entries are regular expression patterns, but they will only be
	# applied to the host name (domain) of a given URL.
	whitelist: [
	"gist\\.github\\.com"
	"pastebin\\.com"
	]
	}

	# Other settings that you might find useful to tweak.
	misc {
	# The maximum width of multi-block screens, in blocks.
	# See also: `maxScreenHeight`.
	maxScreenWidth: 8

	# The maximum height of multi-block screens, in blocks. This is limited to
	# avoid excessive computations for merging screens. If you really need
	# bigger screens it's probably safe to bump this quite a bit before you
	# notice anything, since at least incremental updates should be very
	# efficient (i.e. when adding/removing a single screen).
	maxScreenHeight: 6

	# The maximum length of a string that may be pasted. This is used to limit
	# the size of the data sent to the server when the user tries to paste a
	# string from the clipboard (Shift+Ins on a screen with a keyboard).
	maxClipboard: 1024

	# The maximum distance a wireless message can be sent. In other words,
	# this is the maximum signal strength a wireless network card supports.
	# This is used to limit the search range in which to check for modems,
	# which may or may not lead to performance issues for ridiculous ranges -
	# like, you know, more than the loaded area.
	# See also: `wirelessCostPerRange`.
	maxWirelessRange: 400

	# The user name to specify when executing a command via a command block.
	# If you leave this empty it will use the address of the network node that
	# sent the execution request - which will usually be a computer.
	commandUser: OpenComputers
	}
	}