| # 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 |
| |
| # The amount of energy a Charger transfers to each adjacent robot per tick |
| # if a maximum strength redstone signal is set. Chargers load robots with |
| # a controllable speed, based on the maximum strength of redstone signals |
| # going into the block. So if a redstone signal of eight is set, it'll |
| # charge robots at roughly half speed. |
| chargerChargeRate: 2500.0 |
| |
| # The energy efficiency of the generator upgrade. At 1.0 this will |
| # generate as much energy as you'd get by burning the fuel in a BuildCraft |
| # Stirling Engine (1MJ per fuel value / burn ticks). To discourage fully |
| # autonomous robots the efficiency of generators is slighly reduced by |
| # default. |
| generatorEfficiency: 0.8 |
| |
| 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.1 |
| |
| # 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: 10.0 |
| |
| # The amount of energy it takes a robot to move a single block. |
| robotMove: 60.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 size of writable floppy disks, in kilobytes. |
| floppySize: 512 |
| |
| # The size of the /tmp filesystem that each computer gets for free. If |
| # set to a non-positive value the tmp file system will not be created. |
| tmpSize: 64 |
| |
| # 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 size of network packets to allow sending via network cards. |
| # This has *nothing to do* with real network traffic, it's just a limit |
| # for the network cards, mostly to reduce the chance of computer with a |
| # lot of RAM killing those with less by sending huge packets. This does |
| # not apply to HTTP traffic. |
| maxNetworkPacketSize: 8192 |
| |
| # 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 |
| } |
| } |