1526 lines
67 KiB
INI
1526 lines
67 KiB
INI
# 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 {
|
|
|
|
# Client side settings, presentation and performance related stuff.
|
|
client {
|
|
|
|
# The radius in which computer beeps can be heard.
|
|
beepRadius=16
|
|
|
|
# The sample rate used for generating beeps of computers' internal
|
|
# speakers. Use custom values at your own responsibility here; if it
|
|
# breaks OC you'll get no support. Some potentially reasonable
|
|
# lower values are 16000 or even 8000 (which was the old default, but
|
|
# leads to artifacting on certain frequencies).
|
|
beepSampleRate=44100
|
|
|
|
# The base volume of beeps generated by computers. This may be in a
|
|
# range of [0, 127], where 0 means mute (the sound will not even be
|
|
# generated), and 127 means maximum amplitude / volume.
|
|
beepVolume=32
|
|
|
|
# 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
|
|
|
|
# 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
|
|
|
|
# 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
|
|
|
|
# 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 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
|
|
|
|
# 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"
|
|
|
|
# Position of the power indicator for nanomachines, by default left to the
|
|
# player's health, specified by negative values. Values in [0, 1) will be
|
|
# treated as relative positions, values in [1, inf) will be treated as
|
|
# absolute positions.
|
|
nanomachineHudPos=[
|
|
-1,
|
|
-1
|
|
]
|
|
|
|
# Render robots' names as a label above them when near them
|
|
robotLabels=true
|
|
|
|
# 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
|
|
|
|
# The volume multiplier applied to sounds from this mod like the computer
|
|
# running noise. Disable sounds by setting this to zero.
|
|
soundVolume=1
|
|
|
|
# If you prefer the text on the screens to be aliased (you know, *not*
|
|
# anti-aliased / smoothed) turn this option off.
|
|
textAntiAlias=true
|
|
|
|
# Whether to apply linear filtering for text displayed on screens when the
|
|
# screen has to be scaled down - i.e. the text is rendered at a resolution
|
|
# lower than their native one, e.g. when the GUI scale is less than one or
|
|
# when looking at a far away screen. This leads to smoother text for
|
|
# scaled down text but results in characters not perfectly connecting
|
|
# anymore (for example for box drawing characters. Look it up on
|
|
# Wikipedia.)
|
|
textLinearFiltering=false
|
|
}
|
|
|
|
# Computer related settings, concerns server performance and security.
|
|
computer {
|
|
|
|
# The 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,
|
|
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 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 maximum size of the byte array that can be stored on EEPROMs as configuration data.
|
|
eepromDataSize=256
|
|
|
|
# The maximum size of the byte array that can be stored on EEPROMs as executable data..
|
|
eepromSize=4096
|
|
|
|
# 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
|
|
|
|
# Settings specific to the Lua architecture.
|
|
lua {
|
|
|
|
# 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
|
|
|
|
# Whether to make the Lua 5.3 architecture available. If enabled, you
|
|
# can reconfigure any CPU to use the Lua 5.3 architecture.
|
|
enableLua53=true
|
|
|
|
# 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 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
|
|
]
|
|
}
|
|
|
|
# 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
|
|
|
|
# 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 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
|
|
}
|
|
|
|
# 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 {
|
|
|
|
# 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
|
|
|
|
# Prevent OC calling Lua's os.setlocale method to ensure number
|
|
# formatting is the same on all systems it is run on. Use this if you
|
|
# suspect this might mess with some other part of Java (this affects
|
|
# the native C locale).
|
|
disableLocaleChanging=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
|
|
|
|
# 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 user data support. This means any otherwise supported
|
|
# userdata (implementing the Value interface) will not be pushed
|
|
# to the Lua state.
|
|
disableUserdata=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
|
|
|
|
# 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
|
|
|
|
# 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
|
|
|
|
# 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=""
|
|
|
|
# Pass along IDs of items and fluids when converting them to a table
|
|
# representation for Lua.
|
|
insertIdsInConverters=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
|
|
|
|
# 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
|
|
|
|
# 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
|
|
|
|
# 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
|
|
|
|
# Whether to always register the LuaJ architecture - even if the native
|
|
# library is available. In that case it is possible to switch between
|
|
# the two like any other registered architecture.
|
|
registerLuaJArchitecture=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
|
|
}
|
|
|
|
# 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 size of writable floppy disks, in kilobytes.
|
|
floppySize=512
|
|
|
|
# Number of physical platters to pretend a disk has in unmanaged mode. This
|
|
# controls seek times, in how it emulates sectors overlapping (thus sharing
|
|
# a common head position for access).
|
|
hddPlatterCounts=[
|
|
2,
|
|
4,
|
|
6
|
|
]
|
|
|
|
# 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=2048
|
|
|
|
# When skipping more than this number of sectors in unmanaged mode, the
|
|
# pause specified in sectorSeekTime will be enforced. We use this instead
|
|
# of linear scaling for movement because those values would have to be
|
|
# really small, which is hard to conceptualize and configure.
|
|
sectorSeekThreshold=128
|
|
|
|
# The time to pause when the head movement threshold is exceeded.
|
|
sectorSeekTime=0.1
|
|
|
|
# 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
|
|
}
|
|
hologram {
|
|
|
|
# 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.
|
|
maxScale=[
|
|
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.
|
|
maxTranslation=[
|
|
0.25,
|
|
0.5
|
|
]
|
|
|
|
# The delay forced on computers between calls to `hologram.setRaw`, in
|
|
# seconds. Lower this if you want faster updates, raise this if you're
|
|
# worried about bandwidth use; in *normal* use-cases this will never be
|
|
# an issue. When abused, `setRaw` can be used to generate network traffic
|
|
# due to changed data being sent to clients. With the default settings,
|
|
# the *worst case* is ~30KB/s/client. Again, for normal use-cases this
|
|
# is actually barely noticeable.
|
|
setRawDelay=0.2
|
|
}
|
|
|
|
# Settings for mod integration (the mod previously known as OpenComponents).
|
|
integration {
|
|
buildcraft {
|
|
|
|
# Cost to convert a loot disk to another in the BuildCraft programming table.
|
|
programmingTableCost=5000
|
|
}
|
|
|
|
# The name to use for the global fake player needed for some mod
|
|
# interactions.
|
|
fakePlayerName="[OpenComputers]"
|
|
|
|
# The UUID to use for the global fake player needed for some mod
|
|
# interactions.
|
|
fakePlayerUuid="7e506b5d-2ccb-4ac4-a249-5624925b0c67"
|
|
|
|
# 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"
|
|
]
|
|
|
|
# Vanilla integration related settings.
|
|
vanilla {
|
|
|
|
# Whether to allow the item stack converter to push NBT data in
|
|
# compressed format (GZIP'ed). This can be useful for pushing this
|
|
# data back to other callbacks. However, given a sophisticated
|
|
# enough software (Lua script) it is possible to decode this data,
|
|
# and get access to things that should be considered implementation
|
|
# detail / private (mods may keep "secret" data in such NBT tags).
|
|
# The recommended method is to use the database component instead.
|
|
allowItemStackNBTTags=false
|
|
|
|
# Whether to enable the command block driver. Enabling this allows
|
|
# computers to set and execute commands via command blocks next to
|
|
# adapter blocks. The commands are run using OC's general fake player.
|
|
enableCommandBlockDriver=false
|
|
|
|
# Whether to enable the inventory driver. This driver allows interacting
|
|
# with inventories adjacent to adapters in a way similar to what the
|
|
# inventory controller upgrade allows when built into a robot or placed
|
|
# inside an adapter. It is therefore considered to be somewhat cheaty by
|
|
# some, and disabled by default. If you don't care about that, feel free
|
|
# to enable this driver.
|
|
enableInventoryDriver=false
|
|
|
|
# Whether to enable the tank driver. This driver is like the inventory
|
|
# driver, just for fluid tanks, and is disabled by default with the same
|
|
# reasoning as the inventory driver - using a tank controller upgrade in
|
|
# an adapter has pretty much the same effect.
|
|
enableTankDriver=false
|
|
}
|
|
}
|
|
|
|
# Internet settings, security related.
|
|
internet {
|
|
|
|
# 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"
|
|
]
|
|
|
|
# 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
|
|
|
|
# The maximum concurrent TCP connections *each* internet card can have
|
|
# open at a time.
|
|
maxTcpConnections=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
|
|
|
|
# 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
|
|
|
|
# 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=[]
|
|
}
|
|
|
|
# Other settings that you might find useful to tweak.
|
|
misc {
|
|
|
|
# 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
|
|
|
|
# List of item descriptors of assembler template base items to blacklist,
|
|
# i.e. for disabling the assembler template for. Entries must be of the
|
|
# format 'itemid@damage', were the damage is optional.
|
|
# Examples: 'OpenComputers:case3', 'minecraft:stonebrick@1'
|
|
assemblerBlacklist=[]
|
|
|
|
# Hard limit for size of byte arrays passed to data card callbacks. If this
|
|
# limit is exceeded, the call fails and does nothing.
|
|
dataCardHardLimit=1048576
|
|
|
|
# Soft limit for size of byte arrays passed to data card callbacks. If this
|
|
# limit is exceeded, a longer sleep is enforced (see dataCardTimeout).
|
|
dataCardSoftLimit=8192
|
|
|
|
# Time in seconds to pause a calling machine when the soft limit for a data
|
|
# card callback is exceeded.
|
|
dataCardTimeout=1
|
|
|
|
# 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
|
|
|
|
# Names of items / blocks that are blacklisted. Recipes containing these
|
|
# as inputs will be ignored by the disassembler.
|
|
disassemblerInputBlacklist=[
|
|
"minecraft:fire"
|
|
]
|
|
|
|
# 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=2
|
|
|
|
# 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
|
|
|
|
# Whether to give a new player a free copy of the manual. This will only
|
|
# happen one time per game, not per world, not per death. Once. If this
|
|
# is still too much for your taste, disable it here ;-)
|
|
giveManualToNewPlayers=true
|
|
|
|
# Whether to not show your special thinger (if you have one you know it).
|
|
hideOwnSpecial=false
|
|
|
|
# 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 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 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 number of "data parts" a network packet is allowed to have.
|
|
# When sending a network message, from Lua this may look like so:
|
|
# component.modem.broadcast(port, "first", true, "third", 123)
|
|
# This limits how many arguments can be passed and are wrapped into a
|
|
# packet. This limit mostly serves as a protection for lower-tier
|
|
# computers, to avoid them getting nuked by more powerful computers.
|
|
maxNetworkPacketParts=8
|
|
|
|
# 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 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 width of multi-block screens, in blocks.
|
|
# See also: `maxScreenHeight`.
|
|
maxScreenWidth=8
|
|
|
|
# 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
|
|
|
|
# Probablility that at certain celebratory times crafting an OC item will
|
|
# spawn a present in the crafting player's inventory. Set to zero to
|
|
# disable.
|
|
presentChance=0.05
|
|
|
|
# Enforced delay when changing a redstone emitting component's output,
|
|
# such as the redstone card and redstone I/O block. Lowering this can
|
|
# have very negative impact on server TPS, so beware.
|
|
redstoneDelay=0.1
|
|
|
|
# The general upgrade tier of the switch built into server racks, i.e. how
|
|
# upgraded server racks' switching logic is. Prior to the introduction of
|
|
# this setting (1.5.15) this was always none. This applies to all
|
|
# properties, i.e. througput, frequency and buffer size.
|
|
# Valid values are: 0 = none, 1 = tier 1, 2 = tier 2, 3 = tier 3.
|
|
serverRackSwitchTier=1
|
|
|
|
# The number of remote terminals supported by each server tier.
|
|
terminalsPerTier=[
|
|
2,
|
|
4,
|
|
8
|
|
]
|
|
|
|
# Override for the worker threads' thread priority. If set to a value
|
|
# lower than 1 it will use the default value, which is half-way between
|
|
# the system minimum and normal priority. Valid values may differ between
|
|
# Java versions, but usually the minimum value (lowest priority) is 1,
|
|
# the normal value is 5 and the maximum value is 10. If a manual value is
|
|
# given it is automatically capped at the maximum.
|
|
# USE THIS WITH GREAT CARE. Using a high priority for worker threads may
|
|
# avoid issues with computers timing out, but can also lead to higher
|
|
# server load. AGAIN, USE WITH CARE!
|
|
threadPriority=-1
|
|
|
|
# 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=false
|
|
}
|
|
|
|
# Nanomachine related values. Note that most of these are relative, as
|
|
# they scale with the number of total effects controlled by nanomachines,
|
|
# which may very much vary depending on other mods used together with OC.
|
|
# To configure this, you'll need to know how this works a bit more in-
|
|
# depth, so here goes: there are three layers, the behavior layer, the
|
|
# connector layer, and the input layer. The behavior layer consists of
|
|
# one node for each behavior provided by registered providers (by default
|
|
# these will be potion effects and a few other things). The connector
|
|
# layer merely serves to mix things up a little. The input layer is made
|
|
# up from nodes that can be triggered by the nanomachines. Each connector
|
|
# node has behavior nodes it outputs to, and gets signals from input nodes.
|
|
# Behavior nodes get signals from both the connector and the input layers.
|
|
# Reconfiguring builds up random connections. Some behaviors change what
|
|
# they do based on the number of active inputs (e.g. potion effects will
|
|
# increase their amplification value).
|
|
nanomachines {
|
|
|
|
# Time in seconds it takes for the nanomachines to process a command
|
|
# and send a response.
|
|
commandDelay=1
|
|
|
|
# The distance in blocks that nanomachines can communicate within. If
|
|
# a message comes from further away, it'll be ignored. When responding,
|
|
# the response will only be sent this far.
|
|
commandRange=2
|
|
|
|
# The relative number of connectors based on the number of available
|
|
# behaviors (see triggerQuota).
|
|
connectorQuota=0.2
|
|
|
|
# Radius in blocks of the disintegration behavior for each active input.
|
|
disintegrationRange=1
|
|
|
|
# How much damage the hungry behavior should deal to the player when the
|
|
# nanomachine controller runs out of energy.
|
|
hungryDamage=5
|
|
|
|
# How much energy the hungry behavior should restore when damaging the
|
|
# player.
|
|
hungryEnergyRestored=50
|
|
|
|
# Range of the item magnet behavior added for each active input.
|
|
magnetRange=8
|
|
|
|
# The maximum number of inputs for each node of the "neural network"
|
|
# nanomachines connect to. I.e. each behavior node and connector node
|
|
# may only have up to this many inputs.
|
|
maxInputs=2
|
|
|
|
# Hard maximum number of active inputs. This is mainly to avoid people
|
|
# bumping other nanomachines' inputs to max, killing them in a matter
|
|
# of (milli)seconds.
|
|
maxInputsActive=4
|
|
|
|
# The maximum number of outputs for each node (see maxInputs).
|
|
maxOutputs=2
|
|
|
|
# Whitelisted potions, i.e. potions that will be used for the potion
|
|
# behaviors nanomachines may trigger. This can contain strings or numbers.
|
|
# In the case of strings, it has to be the internal name of the potion,
|
|
# in case of a number it has to be the potion ID. Add any potion effects
|
|
# to make use of here, since they will all be disabled by default.
|
|
potionWhitelist=[
|
|
"potion.moveSpeed",
|
|
"potion.digSpeed",
|
|
"potion.damageBoost",
|
|
"potion.jump",
|
|
"potion.resistance",
|
|
"potion.fireResistance",
|
|
"potion.waterBreathing",
|
|
"potion.nightVision",
|
|
"potion.absorption",
|
|
"potion.blindness",
|
|
"potion.confusion",
|
|
"potion.digSlowDown",
|
|
"potion.harm",
|
|
"potion.hunger",
|
|
"potion.moveSlowdown",
|
|
"potion.poison",
|
|
"potion.weakness",
|
|
"potion.wither"
|
|
]
|
|
|
|
# How many input nodes may be active at the same time before negative
|
|
# effects are applied to the player.
|
|
safeInputsActive=2
|
|
|
|
# The relative amount of triggers available based on the number of
|
|
# available behaviors (such as different potion effects). For example,
|
|
# if there are a total of 10 behaviors available, 0.5 means there will
|
|
# be 5 trigger inputs, triggers being the inputs that can be activated
|
|
# via nanomachines.
|
|
triggerQuota=0.4
|
|
}
|
|
|
|
# Power settings, buffer sizes and power consumption.
|
|
power {
|
|
|
|
# The amount of energy the robot assembler can apply per tick. This
|
|
# controls the speed at which robots are assembled, basically.
|
|
assemblerTickAmount=50
|
|
|
|
# Default "buffer" sizes, i.e. how much energy certain blocks can store.
|
|
buffer {
|
|
|
|
# The amount of energy an access point can store.
|
|
accessPoint=600
|
|
|
|
# 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 single capacitor can store.
|
|
capacitor=1600
|
|
|
|
# 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 energy 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 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 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 of energy a drone can store in its internal buffer.
|
|
drone=5000
|
|
|
|
# The internal buffer size of the hover boots.
|
|
hoverBoots=15000
|
|
|
|
# The amount of energy a microcontroller can store in its internal
|
|
# buffer.
|
|
mcu=1000
|
|
|
|
# Amount of energy stored by nanomachines. Yeah, I also don't know
|
|
# where all that energy is stored. It's quite fascinating.
|
|
nanomachines=100000
|
|
|
|
# The amount of energy robots can store in their internal buffer.
|
|
robot=20000
|
|
|
|
# The amount a tablet can store in its internal buffer.
|
|
tablet=10000
|
|
}
|
|
|
|
# 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
|
|
|
|
# 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
|
|
|
|
# Default "costs", i.e. how much energy certain operations consume.
|
|
cost {
|
|
|
|
# The cost of a single packet sent via StargateTech 2's abstract bus.
|
|
abstractBusPacket=1
|
|
|
|
# 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 a computer consumes per tick when running.
|
|
computer=0.5
|
|
|
|
# Cost for asymmetric operations on the data card, such as ECDH and ECDSA
|
|
# Per-byte cost for ECDSA operation is controlled by `complex` value,
|
|
# because data is hashed with SHA256 before signing/verifying
|
|
dataCardAsymmetric=10
|
|
|
|
# Cost for complex operations on the data card, such as SHA256, inflate/deflate and SecureRandom.
|
|
dataCardComplex=6
|
|
|
|
# Per-byte cost for complex operations
|
|
dataCardComplexByte=0.1
|
|
|
|
# Cost for simple operations on the data card, such as MD5 or AES
|
|
dataCardSimple=1
|
|
|
|
# Per-byte cost for simple operations
|
|
dataCardSimpleByte=0.01
|
|
|
|
# Cost for trivial operations on the data card, such as CRC32 or Base64
|
|
dataCardTrivial=0.2
|
|
|
|
# Per-byte cost for trivial operations
|
|
dataCardTrivialByte=0.005
|
|
|
|
# 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 a drone consumes per tick when running.
|
|
drone=0.4
|
|
|
|
# The base energy cost for assembling a drone.
|
|
droneAssemblyBase=25000
|
|
|
|
# The additional amount of energy required to assemble a
|
|
# drone for each point of complexity.
|
|
droneAssemblyComplexity=15000
|
|
|
|
# Energy it costs to re-program an EEPROM. This is deliberately
|
|
# expensive, to discourage frequent re-writing of EEPROMs.
|
|
eepromWrite=50
|
|
|
|
# How much energy is consumed when the Geolyzer scans a block.
|
|
geolyzerScan=10
|
|
|
|
# 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
|
|
|
|
# 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
|
|
|
|
# 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 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
|
|
|
|
# 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
|
|
|
|
# The amount of energy consumed when the hover boots absorb some fall
|
|
# velocity (i.e. when falling from something higher than three blocks).
|
|
hoverBootAbsorb=10
|
|
|
|
# The amount of energy consumed when jumping with the hover boots. Only
|
|
# applies when the jump boost is applied, i.e. when not sneaking.
|
|
hoverBootJump=10
|
|
|
|
# The amount of energy consumed *per second* when moving around while
|
|
# wearing the hover boots. This is compensate for the step assist, which
|
|
# does not consume energy on a per-use basis. When standing still or
|
|
# moving very slowly this also does not trigger.
|
|
hoverBootMove=1
|
|
|
|
# Amount of energy a microcontroller consumes per tick while running.
|
|
microcontroller=0.1
|
|
|
|
# The base energy cost for assembling a microcontroller.
|
|
microcontrollerAssemblyBase=10000
|
|
|
|
# The additional amount of energy required to assemble a
|
|
# microcontroller for each point of complexity.
|
|
microcontrollerAssemblyComplexity=10000
|
|
|
|
# Energy consumed per tick per active input node by nanomachines.
|
|
nanomachineInput=0.5
|
|
|
|
# Energy consumed when reconfiguring nanomachines.
|
|
nanomachinesReconfigure=5000
|
|
|
|
# The amount of energy pushing blocks with the piston upgrade costs.
|
|
pistonPush=20
|
|
|
|
# How much energy is required for a single 3D print.
|
|
printerModel=100
|
|
|
|
# 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 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 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
|
|
|
|
# The amount of energy it takes a robot to perform a 90 degree turn.
|
|
robotTurn=2.5
|
|
|
|
# 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 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 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
|
|
|
|
# Energy required for one transposer operation (regardless of the number
|
|
# of items / fluid volume moved).
|
|
transposer=1
|
|
|
|
# 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 amount of energy the disassembler can apply per tick. This
|
|
# controls the speed at which items are disassembled, basically.
|
|
disassemblerTickAmount=25
|
|
|
|
# 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
|
|
|
|
# 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
|
|
|
|
# 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=[]
|
|
|
|
# The amount of energy the printer can apply per tick. This controls
|
|
# the speed at which prints are completed, basically.
|
|
printerTickAmount=1
|
|
|
|
# The rate at which different blocks accept external power. All of these
|
|
# values are in OC energy / tick.
|
|
rate {
|
|
accessPoint=10
|
|
assembler=100
|
|
case=[
|
|
5,
|
|
10,
|
|
20
|
|
]
|
|
charger=200
|
|
disassembler=50
|
|
powerConverter=500
|
|
serverRack=50
|
|
}
|
|
|
|
# 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
|
|
|
|
# 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 10 ticks,
|
|
# or in other words twice 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
|
|
|
|
# Power values for different power systems. For reference, the value of
|
|
# OC's internal energy type is 1000. I.e. the conversion ratios are the
|
|
# values here divided by 1000. This is mainly to avoid small floating
|
|
# point numbers in the config, due to potential loss of precision.
|
|
value {
|
|
AppliedEnergistics2=200
|
|
Factorization=13
|
|
Galacticraft=48
|
|
IndustrialCraft2=400
|
|
Mekanism=1333.33
|
|
RedstoneFlux=100
|
|
}
|
|
}
|
|
|
|
# 3D printer related stuff.
|
|
printer {
|
|
|
|
# Whether Chamelium is edible or not. When eaten, it gives a (short)
|
|
# invisibility buff, and (slightly longer) blindness debuff.
|
|
chameliumEdible=true
|
|
|
|
# The extra material cost involved for printing a model with a customized
|
|
# redstone output, i.e. something in [1, 14].
|
|
customRedstoneCost=300
|
|
|
|
# The amount by which a printers ink buffer gets filled for a single
|
|
# cartridge. Tweak this if you think printing is too cheap or expensive.
|
|
# Note: the amount a single dye adds is this divided by 10.
|
|
inkValue=50000
|
|
|
|
# The amount by which a printers material buffer gets filled for a single
|
|
# chamelium. Tweak this if you think printing is too cheap or expensive.
|
|
materialValue=2000
|
|
|
|
# The maximum light level a printed block can emit. This defaults to
|
|
# a value similar to that of a redstone torch, because by default the
|
|
# material prints are made of contains redstone, but no glowstone.
|
|
# Prints' light level can further be boosted by crafting them with
|
|
# glowstone dust. This is merely the maximum light level that can be
|
|
# achieved directly when printing them.
|
|
maxBaseLightLevel=8
|
|
|
|
# The maximum number of shape for a state of a 3D print allowed. This is
|
|
# for the individual states (off and on), so it is possible to have up to
|
|
# this many shapes *per state* (the reasoning being that only one state
|
|
# will ever be visible at a time).
|
|
maxShapes=24
|
|
|
|
# By what (linear) factor the cost of a print increases if one or both of
|
|
# its states are non-collidable (i.e. entities can move through them).
|
|
# This only influences the chamelium cost.
|
|
noclipMultiplier=2
|
|
|
|
# Whether to enable print opacity, i.e. make prints have shadows. If
|
|
# enabled, prints will have an opacity that is estimated from their
|
|
# sampled fill rate. This is disabled by default, because MC's lighting
|
|
# computation is apparently not very happy with multiple blocks with
|
|
# dynamic opacity sitting next to each other, and since all prints share
|
|
# the same block type, this can lead to weird shadows on prints. If you
|
|
# don't care about that and prefer them to be not totally shadowless,
|
|
# enable this.
|
|
printsHaveOpacity=false
|
|
|
|
# How much of the material used to print a model is refunded when using
|
|
# the model to refuel a printer. This the value the original material
|
|
# cost is multiplied with, so 1 is a full refund, 0 disables the
|
|
# functionality (won't be able to put prints into the material input).
|
|
recycleRate=0.75
|
|
}
|
|
|
|
# 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
|
|
|
|
# Allows fine-tuning of delays for robot actions.
|
|
delays {
|
|
|
|
# The time in seconds to pause execution after an item was
|
|
# successfully dropped from a robot's inventory.
|
|
drop=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
|
|
|
|
# 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
|
|
# placed an item from its inventory.
|
|
place=0.4
|
|
|
|
# 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
|
|
# 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 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 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 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
|
|
|
|
# Limit robot flight height, based on the following rules:
|
|
# - Robots may only move if the start or target position is valid (e.g.
|
|
# to allow building bridges).
|
|
# - The position below a robot is always valid (can always move down).
|
|
# - Positions up to <flightHeight> above a block are valid (limited
|
|
# flight capabilities).
|
|
# - Any position that has an adjacent block with a solid face towards the
|
|
# position is valid (robots can "climb").
|
|
# Set this to 256 to allow robots to fly whereever, as was the case
|
|
# before the 1.5 update. Consider using drones for cases where you need
|
|
# unlimited flight capabilities instead!
|
|
limitFlightHeight=8
|
|
|
|
# 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"
|
|
|
|
# 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 maximum flight height with upgrades, tier one and tier two of the
|
|
# hover upgrade, respectively.
|
|
upgradeFlightHeight=[
|
|
64,
|
|
256
|
|
]
|
|
|
|
# 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
|
|
|
|
# Controls the UUID robots are given. You can either specify a fixed UUID
|
|
# here or use the two provided variables:
|
|
# - $random$, which will assign each robot a random UUID.
|
|
# - $player$, which assigns to each placed robot the UUID of the player
|
|
# that placed it (note: if robots are placed by fake players, i.e.
|
|
# other mods' blocks, they will get that mods' fake player's profile!)
|
|
# Note that if no player UUID is available this will be the same as
|
|
# $random$.
|
|
uuidFormat="$player$"
|
|
|
|
# This controls how fast robots gain experience, and how that experience
|
|
# alters the stats.
|
|
xp {
|
|
|
|
# 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 required amount per level is computed like this:
|
|
# xp(level) = baseValue + (level * constantGrowth) ^ exponentialGrowth
|
|
baseValue=50
|
|
|
|
# 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 required amount per level is computed like this:
|
|
# xp(level) = baseValue + (level * constantGrowth) ^ exponentialGrowth
|
|
constantGrowth=8
|
|
|
|
# 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
|
|
|
|
# The required amount per level is computed like this:
|
|
# xp(level) = baseValue + (level * constantGrowth) ^ exponentialGrowth
|
|
exponentialGrowth=2
|
|
|
|
# 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
|
|
|
|
# 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
|
|
|
|
# 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
|
|
}
|
|
}
|
|
|
|
# Switch and access point network message forwarding logic related stuff.
|
|
switch {
|
|
|
|
# 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
|
|
|
|
# The base number of packets that get relayed in one 'cycle'. The
|
|
# cooldown between cycles is determined by the delay.
|
|
defaultRelayAmount=1
|
|
|
|
# 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
|
|
|
|
# This is the amount by which the queue size increases per tier of the
|
|
# hard drive installed in the switch.
|
|
queueSizeUpgrade=10
|
|
|
|
# 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
|
|
|
|
# The amount of ticks the delay is *reduced* by per tier of the CPU
|
|
# inserted into a switch.
|
|
relayDelayUpgrade=1
|
|
}
|
|
|
|
# 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="1.5.19.37"
|
|
|
|
}
|