| # OpenComputers configuration. This file uses typesafe config's HOCON syntax. |
| # Try setting your syntax highlighting to Ruby, to help readability. At least |
| # in Sublime Text that works really well. Note that this file is overwritten |
| # whenever you start the game! Changes to the comments may vanish. |
| # Note that all mentions of 'KB' or 'kilobyte' mean 1024 bytes. |
| opencomputers { |
| # The version of OC this config was generated by. This is used to allow the |
| # mod to reset parts of the config when their meaning changed across |
| # versions, so that the user does not have to delete it. |
| version: "@VERSION@" |
| |
| # 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: 15.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: 20.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 |
| |
| # If you prefer the text on the screens to be aliased (you know, *not* |
| # anti-aliased / smoothed) turn this option off. |
| textAntiAlias: true |
| |
| # Render robots' names as a label above them when near them |
| robotLabels: true |
| |
| # The volume multiplier applied to sounds from this mod like the computer |
| # running noise. Disable sounds by setting this to zero. |
| soundVolume: 1.0 |
| |
| # This is the scaling of the individual chars rendered on screens. This |
| # is set to slightly overscale per default, to avoid gaps between fully |
| # filled chars to appear (i.e. the block symbol that is used for cursor |
| # blinking for example) on less accurate hardware. |
| fontCharScale: 1.01 |
| |
| # The maximum render distance of a hologram projected by a highest tier |
| # hologram projector when at maximum scale. Render distance is scaled |
| # down with the actual scale of the hologram. |
| hologramRenderDistance: 64 |
| |
| # The distance at which to start fading out the hologram (as with |
| # hologramRenderDistance). This is purely cosmetic, to avoid image |
| # disappearing instantly when moving too far away from a projector. |
| # It does not affect performance. Holograms are transparent anyway. |
| hologramFadeStartDistance: 48 |
| |
| # This controls how often holograms 'flicker'. This is the chance that it |
| # flickers for *each frame*, meaning if you're running at high FPS you |
| # may want to lower this a bit, to avoid it flickering too much. |
| hologramFlickerFrequency: 0.025 |
| |
| # This controls the maximum scales of holograms, by tier. |
| # The size at scale 1 is 3x2x3 blocks, at scale 3 the hologram will |
| # span up to 9x6x9 blocks. Unlike most other `client' settings, this |
| # value is only used for validation *on the server*, with the effects |
| # only being visible on the client. |
| # Warning: very large values may lead to rendering and/or performance |
| # issues due to the high view distance! Increase at your own peril. |
| hologramMaxScale: [ |
| 3 |
| 4 |
| ] |
| |
| # This controls the maximum translation of holograms, by tier. |
| # The scale is in "hologram sizes", i.e. scale 1 allows offsetting a |
| # hologram once by its own size. |
| hologramMaxTranslation: [ |
| 0.25 |
| 0.5 |
| ] |
| |
| # The color of monochrome text (i.e. displayed when in 1-bit color depth, |
| # e.g. tier one screens / GPUs, or higher tier set to 1-bit color depth). |
| # Defaults to white, feel free to make it some other color, tho! |
| monochromeColor: 0xFFFFFF |
| |
| # Which font renderer to use. Defaults to `unifont` if invalid. |
| # Possible values: |
| # - unifont: the (since 1.3.2) default font renderer. Based on the |
| # Unifont and capable of rendering many unicode glyphs. |
| # The used font data can be swapped out using resource packs, |
| # but is harder to work with, since it involves binary data. |
| # - texture: the old, font-texture based font renderer that was used |
| # in OC versions prior to 1.3.2. This will allow overriding |
| # the font texture as before. Keep in mind that this renderer |
| # is slightly less efficient than the new one, and more |
| # importantly, can only render code page 437 (as opposed to... |
| # a *lot* of unicode). |
| fontRenderer: "unifont" |
| } |
| |
| # 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: 5.0 |
| |
| # Whether to allow loading precompiled bytecode via Lua's `load` function, |
| # or related functions (`loadfile`, `dofile`). Enable this only if you |
| # absolutely trust all users on your server and all Lua code you run. This |
| # can be a MASSIVE SECURITY RISK, since precompiled code can easily be |
| # used for exploits, running arbitrary code on the real server! I cannot |
| # stress this enough: only enable this is you know what you're doing. |
| allowBytecode: false |
| |
| # 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 six levels of RAM, in kilobytes. This list must |
| # contain exactly six entries, or it will be ignored. Note that while |
| # there are six levels of RAM, they still fall into the three tiers of |
| # items (level 1, 2 = tier 1, level 3, 4 = tier 2, level 5, 6 = tier 3). |
| ramSizes: [ |
| 192 |
| 256 |
| 384 |
| 512 |
| 768 |
| 1024 |
| ] |
| |
| # This setting allows you to fine-tune how RAM sizes are scaled internally |
| # on 64 Bit machines (i.e. when the Minecraft server runs in a 64 Bit VM). |
| # Why is this even necessary? Because objects consume more memory in a 64 |
| # Bit environment than in a 32 Bit one, due to pointers and possibly some |
| # integer types being twice as large. It's actually impossible to break |
| # this down to a single number, so this is really just a rough guess. If |
| # you notice this doesn't match what some Lua program would use on 32 bit, |
| # feel free to play with this and report your findings! |
| # Note that the values *displayed* to Lua via `computer.totalMemory` and |
| # `computer.freeMemory` will be scaled by the inverse, so that they always |
| # correspond to the "apparent" sizes of the installed memory modules. For |
| # example, when running a computer with a 64KB RAM module, even if it's |
| # scaled up to 96KB, `computer.totalMemory` will return 64KB, and if there |
| # are really 45KB free, `computer.freeMemory` will return 32KB. |
| ramScaleFor64Bit: 1.8 |
| |
| # The number of components the different CPU tiers support. This list |
| # must contain exactly three entries, or it will be ignored. |
| cpuComponentCount: [ |
| 8 |
| 12 |
| 16 |
| ] |
| |
| # The provided call budgets by the three tiers of CPU. Higher budgets |
| # mean that more direct calls can be performed per tick. You can raise |
| # this to increase the "speed" of computers at the cost of higher real |
| # CPU time. Lower this to lower the load Lua executors put on your |
| # machine / server, at the cost of slower computers. This list must |
| # contain exactly three entries, or it will be ignored. |
| callBudgets: [ |
| 0.5 |
| 1.0 |
| 1.5 |
| ] |
| |
| # 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 (computer.addUser, computer.removeUser, |
| # computer.users). If this is true, the following interactions are only |
| # possible for users: |
| # - input via the keyboard and touch screen. |
| # - 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 |
| |
| # Whether to delete all contents in the /tmp file system when performing |
| # a 'soft' reboot (i.e. via `computer.shutdown(true)`). The tmpfs will |
| # always be erased when the computer is completely powered off, even if |
| # it crashed. This setting is purely for software-triggered reboots. |
| eraseTmpOnReboot: false |
| |
| # The time in milliseconds that scheduled computers are forced to wait |
| # before executing more code. This avoids computers to "busy idle", |
| # leading to artificially high CPU load. If you're worried about |
| # performance on your server, increase this number a little (it should |
| # never exceed 50, a single tick, though) to reduce CPU load even more. |
| executionDelay: 12 |
| } |
| |
| # Robot related settings, what they may do and general balancing. |
| robot { |
| # 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 |
| |
| # Determines whether robots are a pretty cool guy. Ususally cobwebs are |
| # the bane of anything using a tool other than a sword or shears. This is |
| # an utter pain in the part you sit on, because it makes robots meant to |
| # dig holes utterly useless: the poor things couldn't break cobwebs in |
| # mining shafts with their golden pick axes. So, if this setting is true, |
| # we check for cobwebs and allow robots to break 'em anyway, no matter |
| # their current tool. After all, the hardness value of cobweb can only |
| # rationally explained by Steve's fear of spiders, anyway. |
| notAfraidOfSpiders: true |
| |
| # 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.1 |
| |
| # 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" |
| |
| # This controls how fast robots gain experience, and how that experience |
| # alters the stats. |
| xp { |
| # The required amount per level is computed like this: |
| # xp(level) = baseValue + (level * constantGrowth) ^ exponentialGrowth |
| baseValue: 50 |
| |
| # The required amount per level is computed like this: |
| # xp(level) = baseValue + (level * constantGrowth) ^ exponentialGrowth |
| constantGrowth: 8 |
| |
| # The required amount per level is computed like this: |
| # xp(level) = baseValue + (level * constantGrowth) ^ exponentialGrowth |
| exponentialGrowth: 2 |
| |
| # This controls how much experience a robot gains for each successful |
| # action it performs. "Actions" only include the following: swinging a |
| # tool and killing something or destroying a block and placing a block |
| # successfully. Note that a call to `swing` or `use` while "bare handed" |
| # will *not* gain a robot any experience. |
| actionXp: 0.05 |
| |
| # This determines how much "exhaustion" contributes to a robots |
| # experience. This is additive to the "action" xp, so digging a block |
| # will per default give 0.05 + 0.025 [exhaustion] * 1.0 = 0.075 XP. |
| exhaustionXpRate: 1.0 |
| |
| # This determines how much experience a robot gets for each real XP orb |
| # an ore it harvested would have dropped. For example, coal is worth |
| # two real experience points, redstone is worth 5. |
| oreXpRate: 4.0 |
| |
| # This is the amount of additional energy that fits into a robots |
| # internal buffer for each level it gains. So with the default values, |
| # at maximum level (30) a robot will have an internal buffer size of |
| # two hundred thousand. |
| bufferPerLevel: 5000 |
| |
| # The additional "efficiency" a robot gains in using tools with each |
| # level. This basically increases the chances of a tool not losing |
| # durability when used, relative to the base rate. So for example, a |
| # robot with level 15 gets a 0.15 bonus, with the default damage rate |
| # that would lead to a damage rate of 0.1 * (1 - 0.15) = 0.085. |
| toolEfficiencyPerLevel: 0.01 |
| |
| # The increase in block harvest speed a robot gains per level. The time |
| # it takes to break a block is computed as actualTime * (1 - bonus). |
| # For example at level 20, with a bonus of 0.4 instead of taking 0.3 |
| # seconds to break a stone block with a diamond pick axe it only takes |
| # 0.12 seconds. |
| harvestSpeedBoostPerLevel: 0.02 |
| } |
| |
| # Allows fine-tuning of delays for robot actions. |
| 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, i.e. it attacked an entity or |
| # extinguishing fires. |
| # When breaking blocks the normal harvest time scaled with the |
| # `harvestRatio` (see below) applies. |
| 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 a splash potion, 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.5 |
| |
| # The time in seconds to pause execution after a robot successfully |
| # picked up an item after triggering a suck command. |
| suck: 0.5 |
| |
| # This is the *ratio* of the time a player would require to harvest a |
| # block. Note that robots cannot break blocks they cannot harvest. So |
| # the time a robot is forced to sleep after harvesting a block is |
| # breakTime * harvestRatio |
| # Breaking a block will always at least take one tick, 0.05 seconds. |
| harvestRatio: 1.0 |
| } |
| } |
| |
| # 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 |
| |
| # This determines how often continuous power sinks try to actually try to |
| # consume energy from the network. This includes computers, robots and |
| # screens. This also controls how frequent distributors revalidate their |
| # global state and secondary distributors, as well as how often the power |
| # converter queries sources for energy (for now: only BuildCraft). If set |
| # to 1, this would query every tick. The default queries every 20 ticks, |
| # or in other words once per second. |
| # Higher values mean more responsive power consumption, but slightly more |
| # work per tick (shouldn't be that noticeable, though). Note that this |
| # has no influence on the actual amount of energy required by computers |
| # and screens. The power cost is directly scaled up accordingly: |
| # `tickFrequency * cost`. |
| tickFrequency: 10 |
| |
| # 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: 100.0 |
| |
| # The amount of energy a Charger transfers into a tablet, if present, per |
| # tick. This is also based on configured charge speed, as for robots. |
| chargerChargeRateTablet: 10.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 |
| |
| # The energy efficiency of the solar generator upgrade. At 1.0 this will |
| # generate as much energy as you'd get by burning fuel in a BuildCraft |
| # Stirling Engine . To discourage fully autonomous robots the efficiency |
| # of solar generators is greatly reduced by default. |
| solarGeneratorEfficiency: 0.2 |
| |
| # The amount of energy the robot assembler can apply per tick. This |
| # controls the speed at which robots are assembled, basically. |
| assemblerTickAmount: 50 |
| |
| # The amount of energy the disassembler can apply per tick. This |
| # controls the speed at which items are disassembled, basically. |
| disassemblerTickAmount: 25 |
| |
| # If you don't want OpenComputers to accept power from one or more of the |
| # supported power mods, for example because it doesn't suit the vision |
| # of your mod pack, you can disable support for them here. To stop |
| # OpenComputers accepting power from a mod, enter its mod id here, e.g. |
| # `BuildCraftAPI|power`, `IC2`, `factorization`, ... |
| modBlacklist: [] |
| |
| # Default "buffer" sizes, i.e. how much energy certain blocks can store. |
| buffer { |
| # The amount of energy a single capacitor can store. |
| capacitor: 1600.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 8.8k storage with default values: |
| # (1.6 + 0.8 + 0.4)k + (0.8 + 1.6 + 0.8)k + (0.4 + 0.8 + 1.6)k |
| capacitorAdjacencyBonus: 800.0 |
| |
| # The amount of energy a capacitor can store when installed as an |
| # upgrade into a robot. |
| batteryUpgrades: [ |
| 10000 |
| 15000 |
| 20000 |
| ] |
| |
| # The amount of energy a computer can store. This allows you to get a |
| # computer up and running without also having to build a capacitor. |
| computer: 500.0 |
| |
| # The amount of energy robots can store in their internal buffer. |
| robot: 20000.0 |
| |
| # The amount of energy a converter can store. This allows directly |
| # connecting a converter to a distributor, without having to have a |
| # capacitor on the side of the converter. |
| converter: 1000.0 |
| |
| # The amount of energy each face of a distributor can story. This |
| # allows connecting two power distributors directly. If the buffer |
| # capacity between the two distributors is zero, they won't be able |
| # to exchange energy. This basically controls the bandwidth. You can |
| # add capacitors between two distributors to increase this bandwidth. |
| distributor: 500 |
| |
| # The amount a tablet can store in its internal buffer. |
| tablet: 10000 |
| |
| # The amount of energy an access point can store. |
| accessPoint: 600.0 |
| } |
| |
| # Default "costs", i.e. how much energy certain operations consume. |
| cost { |
| # The amount of energy a computer consumes per tick when running. |
| computer: 0.5 |
| |
| # 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.25 |
| |
| # 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 tick. For each lit pixel |
| # (each character that is not blank) this cost increases linearly: |
| # for basic screens, if all pixels are lit the cost per tick will be |
| # this value. Higher tier screens can become even more expensive to |
| # run, due to their higher resolution. 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.05 |
| |
| # The amount of energy a hologram projetor consumes per tick. This |
| # is the cost if every column is lit. If not a single voxel is |
| # displayed the hologram projector will not drain energy. |
| hologram: 0.2 |
| |
| # Energy it takes read one kilobyte from a file system. Note that non |
| # I/O operations on file systems such as `list` or `getFreeSpace` do |
| # *not* consume power. Note that this very much determines how much |
| # energy you need in store to start a computer, since you need enough |
| # to have the computer read all the libraries, which is around 60KB |
| # at the time of writing. |
| # Note: internally this is adjusted to a cost per byte, and applied |
| # as such. It's just specified per kilobyte to be more intuitive. |
| hddRead: 0.1 |
| |
| # Energy it takes to write one kilobyte to a file system. |
| # Note: internally this is adjusted to a cost per byte, and applied |
| # as such. It's just specified per kilobyte to be more intuitive. |
| hddWrite: 0.25 |
| |
| # Energy it takes to change *every* 'pixel' via the set command of a |
| # basic screen via the `set` command. |
| # Note: internally this is adjusted to a cost per pixel, and applied |
| # as such, so this also implicitly defines the cost for higher tier |
| # screens. |
| gpuSet: 2.0 |
| |
| # Energy it takes to change a basic screen with the fill command. |
| # Note: internally this is adjusted to a cost per pixel, and applied |
| # as such, so this also implicitly defines the cost for higher tier |
| # screens. |
| gpuFill: 1.0 |
| |
| # Energy it takes to clear a basic screen using the fill command with |
| # 'space' as the fill char. |
| # Note: internally this is adjusted to a cost per pixel, and applied |
| # as such, so this also implicitly defines the cost for higher tier |
| # screens. |
| gpuClear: 0.1 |
| |
| # Energy it takes to copy half of a basic screen via the copy command. |
| # Note: internally this is adjusted to a cost per pixel, and applied |
| # as such, so this also implicitly defines the cost for higher tier |
| # screens. |
| gpuCopy: 0.25 |
| |
| # The amount of energy it takes a robot to perform a 90 degree turn. |
| robotTurn: 2.5 |
| |
| # The amount of energy it takes a robot to move a single block. |
| robotMove: 15.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: 10.0 |
| |
| # The amount of energy it costs to send a wireless message with signal |
| # 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`. |
| wirelessCostPerRange: 0.05 |
| |
| # The cost of a single packet sent via StargateTech 2's abstract bus. |
| abstractBusPacket: 1 |
| |
| # How much energy is consumed when the Geolyzer scans a block. |
| geolyzerScan: 10 |
| |
| # The base energy cost for assembling a robot. |
| robotAssemblyBase: 50000 |
| |
| # The additional amount of energy required to assemble a robot for |
| # each point of complexity. |
| robotAssemblyComplexity: 10000 |
| |
| # The base energy cost for assembling a tablet. |
| tabletAssemblyBase: 20000 |
| |
| # The additional amount of energy required to assemble a tablet for |
| # each point of complexity. |
| tabletAssemblyComplexity: 5000 |
| |
| # The amount of energy it takes to extract one ingredient from an |
| # item that is being disassembled. For example, if an item that was |
| # crafted from three other items gets disassembled, a total of 15000 |
| # energy will be required by default. |
| # Note that this is consumed over time, and each time this amount is |
| # reached *one* ingredient gets ejected (unless it breaks, see the |
| # disassemblerBreakChance setting). |
| disassemblerPerItem: 2000 |
| |
| # The amount of energy the chunkloader upgrade draws per tick while |
| # it is enabled, i.e. actually loading a chunk. |
| chunkloaderCost: 0.06 |
| |
| # The amount of energy pushing blocks with the piston upgrade costs. |
| pistonPush: 20 |
| } |
| |
| # The rate at which different blocks accept external power. All of these |
| # values are in OC energy / tick. |
| rate { |
| accessPoint: 10.0 |
| assembler: 100.0 |
| case: [ |
| 5.0 |
| 10.0 |
| 20.0 |
| ] |
| charger: 200.0 |
| disassembler: 50.0 |
| powerConverter: 500.0 |
| serverRack: 50.0 |
| } |
| |
| # Power values for different power systems. |
| value { |
| AppliedEnergistics2: 100.0 |
| BuildCraft: 500.0 |
| Factorization: 6.5 |
| Galacticraft: 24.0 |
| IndustrialCraft2: 200.0 |
| Mekanism: 700.0 |
| RedstoneFlux: 18.0 |
| UniversalElectricity: 1750.0 |
| } |
| } |
| |
| # 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: [ |
| 1024 |
| 2048 |
| 4096 |
| ] |
| |
| # 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: 2048 |
| } |
| |
| # Internet settings, security related. |
| internet { |
| # Whether to allow HTTP requests via internet cards. When enabled, |
| # the `request` method on internet card components becomes available. |
| enableHttp: true |
| |
| # Whether to allow TCP connections via internet cards. When enabled, |
| # the `connect` method on internet card components becomes available. |
| enableTcp: true |
| |
| # This is a list of blacklisted domain names. If an HTTP request is made |
| # or a socket connection is opened the target address will be compared |
| # to the addresses / adress ranges in this list. It it is present in this |
| # list, the request will be denied. |
| # Entries are either domain names (www.example.com) or IP addresses in |
| # string format (10.0.0.3), optionally in CIDR notation to make it easier |
| # to define address ranges (1.0.0.0/8). Domains are resolved to their |
| # actual IP once on startup, future requests are resolved and compared |
| # to the resolved addresses. |
| # By default all local addresses are blocked. This is only meant as a |
| # thin layer of security, to avoid average users hosting a game on their |
| # local machine having players access services in their local network. |
| # Server hosters are expected to configure their network outside of the |
| # mod's context in an appropriate manner, e.g. using a system firewall. |
| blacklist: [ |
| "127.0.0.0/8" |
| "10.0.0.0/8" |
| "192.168.0.0/16" |
| "172.16.0.0/12" |
| ] |
| |
| # This is a list of whitelisted domain names. Requests may only be made |
| # to addresses that are present in this list. If this list is empty, |
| # requests may be made to all addresses 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. |
| # Entries are of the same format as in the blacklist. Examples: |
| # "gist.github.com", "www.pastebin.com" |
| whitelist: [] |
| |
| # The time in seconds to wait for a response to a request before timing |
| # out and returning an error message. If this is zero (the default) the |
| # request will never time out. |
| requestTimeout: 0 |
| |
| # The maximum size of files / data that can be downloaded using HTTP- |
| # requests. This is to limit the size of the data that is written when |
| # the world is saved. If this is too large you run into danger of having |
| # chunks not save properly because Minecraft is derpy like that, and |
| # memory consumption can explode, too, if the requested data is not |
| # fetched by the requesting state (e.g. downloading a very large file). |
| # This is in bytes. Four MB is probably still too lenient. Consider |
| # reducing this number on servers. |
| requestMaxDownloadSize: 4194304 |
| |
| # The maximum concurrent TCP connections *each* internet card can have |
| # open at a time. |
| maxTcpConnections: 4 |
| |
| # The number of threads used for processing host name lookups and 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 |
| } |
| |
| # Switch and access point network message forwarding logic related stuff. |
| switch { |
| # The delay a switch has by default between relaying packets (in ticks). |
| # WARNING: lowering this value will result in higher maximum CPU load, |
| # and may in extreme cases cause server lag. |
| defaultRelayDelay: 5 |
| |
| # The amount of ticks the delay is *reduced* by per tier of the CPU |
| # inserted into a switch. |
| relayDelayUpgrade: 1 |
| |
| # This is the size of the queue of a not upgraded switch. Increasing it |
| # avoids packets being dropped when many messages are sent in a single |
| # burst. |
| defaultMaxQueueSize: 20 |
| |
| # This is the amount by which the queue size increases per tier of the |
| # hard drive installed in the switch. |
| queueSizeUpgrade: 10 |
| |
| # The base number of packets that get relayed in one 'cycle'. The |
| # cooldown between cycles is determined by the delay. |
| defaultRelayAmount: 1 |
| |
| # The number of additional packets that get relayed per cycle, based on |
| # the tier of RAM installed in the switch. For built-in RAM this |
| # increases by one per half-tier, for third-party ram this increases by |
| # two per item tier. |
| relayAmountUpgrade: 1 |
| } |
| |
| # 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 |
| |
| # Whether to pass along the name of the user that caused an input signals |
| # to the computer (mouse and keyboard signals). If you feel this breaks |
| # the game's immersion, disable it. |
| # Note: also applies to the motion sensor. |
| inputUsername: true |
| |
| # 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 number of ports a single network card can have opened at |
| # any given time. |
| maxOpenPorts: 16 |
| |
| # 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 number of remote terminals supported by each server tier. |
| terminalsPerTier: [2, 4, 8] |
| |
| # Whether to perform an update check and informing local players and OPs |
| # if a new version is available (contacts Github once the first player |
| # joins a server / the first map in single player is opened). |
| updateCheck: true |
| |
| # The probability (or rather, weighted chance) that a program disk is |
| # spawned as loot in a treasure chest. For reference, iron ingots have |
| # a value of 10, gold ingots a value of 5 and and diamonds a value of 3. |
| # This is the chance *that* a disk is created. Which disk that will be |
| # is decided in an extra roll of the dice. |
| lootProbability: 5 |
| |
| # The range, in blocks, in which the Geolyzer can scan blocks. Note that |
| # it uses the maximum-distance, not the euclidean one, i.e. it can scan |
| # in a cube surrounding it with twice this value as its edge length. |
| geolyzerRange: 32 |
| |
| # Controls how noisy results from the Geolyzer are. This is the maximum |
| # deviation from the original value at the maximum vertical distance |
| # from the geolyzer. Noise increases linearly with the vertical distance |
| # to the Geolyzer. So yes, on the same height, the returned value are of |
| # equal 'quality', regardless of the real distance. This is a performance |
| # trade-off. |
| geolyzerNoise: 4 |
| |
| # By default the disassembler can only be used to disassemble items from |
| # OpenComputers itself (or objects whitelisted via the API). If you'd |
| # like to allow the disassembler to work on all kinds of items, even from |
| # other mods, set this to true. |
| disassembleAllTheThings: false |
| |
| # The probability that an item breaks when disassembled. This chance |
| # applies *per extracted item*. For example, if an item was crafted from |
| # three other items and gets disassembled, each of those three items has |
| # this chance of breaking in the process. |
| disassemblerBreakChance: 0.05 |
| |
| # Whether to not show your special thinger (if you have one you know it). |
| hideOwnSpecial: false |
| |
| # Allow robots to get a table representation of item stacks using the |
| # inventory controller upgrade? (i.e. whether the getStackInSlot method |
| # of said upgrade is enabled or not). Also applies to tank controller |
| # upgrade and it's fluid getter method. |
| allowItemStackInspection: true |
| } |
| |
| # Settings for mod integration (the mod previously known as OpenComponents). |
| integration { |
| # A list of mods (by mod id) for which support should NOT be enabled. Use |
| # this to disable support for mods you feel should not be controllable via |
| # computers (such as magic related mods, which is why Thaumcraft is on this |
| # list by default.) |
| modBlacklist: [ |
| "Thaumcraft" |
| ] |
| # A list of tile entities by class name that should NOT be accessible via |
| # the Adapter block. Add blocks here that can lead to crashes or deadlocks |
| # (and report them, please!) |
| peripheralBlacklist: [ |
| "net.minecraft.tileentity.TileEntityCommandBlock" |
| ] |
| |
| # The UUID to use for the global fake player needed for some mod |
| # interactions. |
| fakePlayerUuid: "7e506b5d-2ccb-4ac4-a249-5624925b0c67" |
| |
| # The name to use for the global fake player needed for some mod |
| # interactions. |
| fakePlayerName: "[OpenComputers]" |
| } |
| |
| # Settings that are intended for debugging issues, not for normal use. |
| # You usually don't want to touch these unless asked to do so by a developer. |
| debug { |
| # Forces the use of the LuaJ fallback instead of the native libraries. |
| # Use this if you have concerns using native libraries or experience |
| # issues with the native library. |
| forceLuaJ: false |
| |
| # This setting is meant for debugging errors that occur in Lua callbacks. |
| # Per default, if an error occurs and it has a message set, only the |
| # message is pushed back to Lua, and that's it. If you encounter weird |
| # errors or are developing an addon you'll want the stacktrace for those |
| # errors. Enabling this setting will log them to the game log. This is |
| # disabled per default to avoid spamming the log with inconsequentual |
| # exceptions such as IllegalArgumentExceptions and the like. |
| logCallbackErrors: false |
| |
| # Disable user data support. This means any otherwise supported |
| # userdata (implementing the Value interface) will not be pushed |
| # to the Lua state. |
| disableUserdata: false |
| |
| # Disable computer state persistence. This means that computers will |
| # automatically be rebooted when loaded after being unloaded, instead |
| # of resuming with their exection (it also means the state is not even |
| # saved). Only relevant when using the native library. |
| disablePersistence: false |
| |
| # Disable memory limit enforcement. This means Lua states can |
| # theoretically use as much memory as they want. Only relevant when |
| # using the native library. |
| disableMemoryLimit: false |
| |
| # Force the buffered file system to be case insensitive. This makes it |
| # impossible to have multiple files whose names only differ in their |
| # capitalization, which is commonly the case on Windows, for example. |
| # This only takes effect when bufferChanges is set to true. |
| forceCaseInsensitiveFS: false |
| |
| # Logs the full error when a native library fails to load. This is |
| # disabled by default to avoid spamming the log, since libraries are |
| # iterated until one works, so it's very likely for some to fail. Use |
| # this in case all libraries fail to load even though you'd expect one |
| # to work. |
| logFullNativeLibLoadErrors: false |
| |
| # Force loading one specific library, to avoid trying to load any |
| # others. Use this if you get warnings in the log or are told to do |
| # so for debugging purposes ;-) |
| forceNativeLibWithName: "" |
| |
| # Used to suppress log spam for OpenGL errors on derpy drivers. I'm |
| # quite certain the code in the font render is valid, display list |
| # compatible OpenGL, but it seems to cause 'invalid operation' errors |
| # when executed as a display list. I'd be happy to be proven wrong, |
| # since it'd restore some of my trust into AMD drivers... |
| logOpenGLErrors: false |
| |
| # On some platforms the native library can crash the game, so there are |
| # a few checks in place to avoid trying to load it in those cases. This |
| # is Windows XP and Windows Server 2003, right. If you think it might |
| # work nonetheless (newer builds of Server2k3 e.g.) you might want to |
| # try setting this to `true`. Use this at your own risk. If the game |
| # crashes as a result of setting this to `true` DO NOT REPORT IT. |
| alwaysTryNative: false |
| |
| # This is meant for debugging errors. Enabling this has a high impact |
| # on computers' save and load performance, so you should not enable |
| # this unless you're asked to. |
| verbosePersistenceErrors: false |
| |
| # Logs information about malformed glyphs (i.e. glyphs that deviate in |
| # width from what wcwidth says). |
| logUnifontErrors: false |
| |
| # Extract the native library with Lua into the system's temporary |
| # directory instead of the game directory (e.g. /tmp on Linux). The |
| # default is to extract into the game directory, to avoid issues when |
| # the temporary directory is mounted as noexec (meaning the lib cannot) |
| # be loaded. There is also less of a chance of conflicts when running |
| # multiple servers or server and client on the same machine. |
| nativeInTmpDir: false |
| |
| # Due to a bug in Minecraft's lighting code there's an issue where |
| # lighting does not properly update near light emitting blocks that are |
| # fully solid - like screens, for example. This can be annoying when |
| # using other blocks that dynamically change their brightness (e.g. for |
| # the addon mod OpenLights). Enable this to force light emitting blocks |
| # in oc to periodically (every two seconds) do an update. This should |
| # not have an overly noticeable impact on performance, but it's disabled |
| # by default because it is unnecessary in *most* cases. |
| periodicallyForceLightUpdate: false |
| |
| # Pass along IDs of items and fluids when converting them to a table |
| # representation for Lua. |
| insertIdsInConverters: false |
| |
| # Enable debug card functionality. This may also be of use for custom |
| # maps, so it is enabled by default. If you run a server where people |
| # may cheat in items but should not have op/admin-like rights, you may |
| # want to set this to false. This will *not* remove the card, it will |
| # just make all functions it provides error out. |
| enableDebugCard: true |
| } |
| } |