Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- # 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.
- # Note that this file is only written if it doesn't exist or is empty. This
- # means that if new settings are added to mod, they will *not* appear in an
- # already existing config file! Sorry about the inconvenience.
- opencomputers {
- # Computer related settings, concerns server performance and security.
- computer {
- # 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
- # 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
- # 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 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
- # 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 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
- ]
- # 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 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
- }
- # Client side settings, presentation and performance related stuff.
- client {
- # 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
- # 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
- # 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
- }
- # HTTP settings, security related.
- http {
- # 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+$"
- ]
- # 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
- # 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$",
- "^(:?www\\.)?pastebin\\.com$"
- ]
- }
- 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
- ]
- }
- # Power settings, buffer sizes and power consumption.
- power {
- buffer {
- # 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
- # The amount of energy a single capacitor can store.
- capacitor=1600
- # 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
- # 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
- # The amount of power robots can store in their internal buffer.
- robot=50000
- }
- # 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
- # Conversion ratio for Thermal Expansion's RF. This is how many internal
- # energy units one RF generates.
- ratioThermalExpansion=0.1
- # 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
- # Conversion ratio for IndustrialCraft2's EU. This is how many internal
- # energy units one EU generates.
- ratioIndustrialCraft2=0.4
- # 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
- # Conversion ratio for Universal Electricity's Joules. This is how many
- # internal energy units one Joule generates.
- ratioUniversalElectricity=1
- cost {
- # The amount of energy a computer consumes per tick when running.
- computer=0.5
- # 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 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
- # 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
- # 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 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
- # 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 it takes a robot to perform a 90 degree turn.
- robotTurn=2.5
- # 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
- # The amount of energy it takes a robot to move a single block.
- robotMove=15
- # 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 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 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 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
- }
- }
- # Robot related settings, what they may do and general balancing.
- robot {
- # 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 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
- 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
- # 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
- # 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
- # 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 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 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 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
- # This controls how fast robots gain experience, and how that experience
- # alters the stats.
- xp {
- constantGrowth=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
- # 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
- exponentialGrowth=3
- # 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
- # 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 required amount per level is computed like this:
- # xp(level) = baseValue + (level * constantGrowth) ^ exponentialGrowth
- baseValue=50
- }
- # 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 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"
- # 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 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 '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
- # 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
- }
- # 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 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 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
- # 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 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 size of writable floppy disks, in kilobytes.
- floppySize=512
- }
- # Other settings that you might find useful to tweak.
- misc {
- # 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 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 maximum width of multi-block screens, in blocks.
- # See also: `maxScreenHeight`.
- maxScreenWidth=8
- # 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 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
- # 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
- }
- }
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement