mirror of
https://github.com/MightyPirates/OpenComputers.git
synced 2025-09-22 03:45:54 -04:00
660 lines
33 KiB
Plaintext
660 lines
33 KiB
Plaintext
# 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.
|
|
opencomputers {
|
|
|
|
# IDs used by the mod, adjust these if you get conflicts.
|
|
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
|
|
|
|
# If you prefer the text on the screens to be aliased (you know, *not*
|
|
# anti-aliased / smoothed) turn this option off.
|
|
textAntiAlias: true
|
|
|
|
# The keyboard shortcut that is used to send the current text in the
|
|
# clipboard to the currently opened screen (if said screen has a keyboard
|
|
# attached to it). For valid key names, please see the following list:
|
|
# https://github.com/LWJGL/lwjgl/blob/master/src/java/org/lwjgl/input/Keyboard.java#L73
|
|
pasteShortcut: [LSHIFT, INSERT]
|
|
}
|
|
|
|
# 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
|
|
|
|
# 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
|
|
|
|
# Whether to actively run Lua's garbage collector each time before the
|
|
# Lua state of a computer is resumed. This has two advantages: memory is
|
|
# less likely to run out because the emergency gargabe collection fails
|
|
# to release certain structures, and Lua programs will get a better idea
|
|
# of how much ram is *really* still available (otherwise the numbers you
|
|
# get from os.freeMemory() will jump - a lot). The downside is that this
|
|
# obviously is slightly more computationally expensive. However, since
|
|
# the memory sizes for Lua states will generally be very small, due to
|
|
# limited amount reachable via RAM items (per default 2*256KB) and being
|
|
# run in a low-priority worker thread, this should be barely noticeable.
|
|
activeGC: true
|
|
|
|
# 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 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
|
|
|
|
# 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
|
|
|
|
# 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
|
|
}
|
|
|
|
# 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. Note that calling either
|
|
# `robot.place` or `robot.use` without a side will cause the robot to try
|
|
# all valid sides.
|
|
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
|
|
|
|
# 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
|
|
constantGrowth: 3
|
|
exponentialGrowth: 3
|
|
|
|
# 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 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: 20
|
|
|
|
# Conversion ratio for BuildCraft's MJ. This is how many internal energy
|
|
# units one MJ generates.
|
|
ratioBuildCraft: 1.0
|
|
|
|
# Conversion ratio for IndustrialCraft2's EU. This is how many internal
|
|
# energy units one EU generates.
|
|
ratioIndustrialCraft2: 0.4
|
|
|
|
# Conversion ratio for Universal Electricity's Joules. This is how many
|
|
# internal energy units one Joule generates.
|
|
ratioUniversalElectricity: 1.0
|
|
|
|
# Conversion ratio for Thermal Expansion's RF. This is how many internal
|
|
# energy units one RF generates.
|
|
ratioThermalExpansion: 0.1
|
|
|
|
# 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 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
|
|
|
|
# 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 power 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 power robots can store in their internal buffer.
|
|
robot: 50000.0
|
|
|
|
# The amount of power 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
|
|
}
|
|
|
|
# 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
|
|
# twice as high as 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.1
|
|
|
|
# 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.5
|
|
|
|
# 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.25
|
|
|
|
# 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.5
|
|
|
|
# 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 * `wirelessStrength`. In other words, the higher this value,
|
|
# the higher the cost of wireless messages.
|
|
# See also: `maxWirelessRange`.
|
|
wirelessStrength: 0.05
|
|
|
|
# The cost of a single packet sent via StargateTech 2's abstract bus.
|
|
abstractBusPacket: 1
|
|
}
|
|
}
|
|
|
|
# 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: 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
|
|
|
|
# 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
|
|
|
|
# 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. Examples:
|
|
# "^gist\\.github\\.com$", "^(:?www\\.)?pastebin\\.com$"
|
|
whitelist: []
|
|
}
|
|
|
|
# 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: `wirelessStrength`.
|
|
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
|
|
}
|
|
} |