This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
FAWE works well out of the box, but configuration settings in the Limits and Queue Operation sections may be used to fine–tune FAWE for your server operation. Refer to the following discussions as well as the comments in the Default Configuration file shown below.
If you make setting changes and encounter problems with edit operations, return to the default setting values before additional fine–tuning attempts. To reset the config.yml file, delete it and re–start the server or reload FAWE using the /fawe command.
Asynchronous Operation
WorldEdit by itself tries to finish each edit operation completely in memory before placing any blocks. WorldEdit also stores undo (history) blocks in memory, which increases memory requirements and with large edits, can cause the server to run out of memory and crash, or cause the edit to fail.
FAWE provides most of its speed improvements by running each edit operation in a separate asynchronous thread. And it starts placing blocks in the world as soon as they are available rather than waiting for the operation to complete. This lets the overall edit finish much faster. Also, since blocks are placed when available, they don’t fill up memory.
FAWE may also be configured to store Undo (History) blocks on disk, which when used with the other improvements, enables FAWE to make nearly unlimited sized edits with minimal impact.
Limits Settings
These settings enable you to control the maximum WorldEdit block edit sizes for various groups of users. The “default” section applies to non–admin users who do not have limit bypass enabled. See fawe.bypass and fawe.admin permissions for more info.
You can also define limits for specific groups and enable them using a permission node. See comments in the default config file listing below.
Queue Settings
Settings in this section enable you to fine tune the asynchronous queue operation to affect memory use and editing speed.
Local Queues
FAWE runs each Edit command in a separate asynchronous thread from the main server thread, and queues blocks processed by the edit to a per player local queue.
Inside the queue, the blocks are ordered by chunks, which enables FAWE to use more efficient chunk optimized algorithms to finally place (dispatch) the blocks into the world. For example, WorldEdit used by itself, performs lighting and physics, and sends packets, for each block being changed. FAWE on the other hand, using its queue of blocks grouped by chunks, can use more efficient chunk algorithms to place the blocks in the world.
Local queues begin in the incomplete state when an edit starts. When simple //set or //copy type commands queue blocks, the blocks are ready to be placed. When other commands (e.g. //smooth and //deform) edit blocks, the blocks changed depend on the position of other blocks in the world, and related blocks may be changed multiple times. (Typically all localized changes are complete within 64 chunks worth of block changes.)
When the edit has completely finished, the local queue changes to the Complete state.
Global Queues
FAWE uses a global queue to actually place blocks from all active local queue edits. The global queue prioritizes on insertion order, so older local queues have their blocks placed first. Blocks on the global queue are placed in the world on the main server thread.
FAWE always places blocks from the Completed local queues first. AND, the list of completed local queues MUST be empty before blocks are placed from incomplete local queues.
The global queue links to local queues for edits in progress. (Internally this is implemented as two queues – one for the local queues that are completed, the other for local queues that are incomplete.)
Efficiency Improvements
FAWE also tries to improve efficiency by placing blocks from Incomplete queues when there are no completed queues ready.
- target–size
FAWE uses target–size to regulate placing blocks from incomplete queues and also to ensure that there is a reasonable likelihood that the blocks to be placed are stable and not likely to be changed again.
Some commands such as //smooth and //deform may not smooth or deform properly if they are dispatched while the command is still processing (though these usually don’t modify anywhere near 64 chunks). The blocks changed depend on the position of other blocks in the world, and related blocks may be changed multiple times. In this case, the likelihood that any particular block will be re–modified falls off after around 64 chunks worth of blocks have been queued. This is not an issue with simple operations like //copy and //set, since those blocks are not changed multiple times.
The global queue will start processing available blocks from still in–process edits if there are no completed local queues waiting to be placed AND there are target–size or more in–process edit chunks queued.
This setting ensures that blocks from commands like //smooth and //deform are stable, and it also contributes to making sure that the global queue keeps placing available blocks rather than staying idle.
The default target–size value is 64.
Without target–size, running a huge edit with /fastmode would normally cause the incomplete queue to fill up faster than the max–wait–ms setting could empty it.
Reducing target–size may reduce performance for operations like //smooth and //deform, since time may be wasted re–changing blocks that have already been placed. Also, since these commands depend on the position of other blocks, if the target–size is not large enough and blocks from incomplete queues are placed but may be changed later, the final result of blocks placed might be different than if the processing completed before any changes are placed. This would result in the commands not performing properly. So having a large enough target–size will avoid this problem.
Increasing target–size is probably not helpful since most related changes occur in less than 64 chunks processing time. ALSO if set very large, it would reduce FAWE’s ability to recover from very large edits that would potentially run the server out of memory.
- max–wait–ms
FAWE is most efficient when placing blocks from edits that have finished processing. However, waiting till completion wastes time and fills memory, therefore, this setting is used to try to keep dispatching blocks from the global queue rather than letting it sit idle while edits haven’t finished but blocks are available to place.
The global queue will start placing blocks from still-processing edits if there are no blocks from completed local queues waiting to be placed AND the global queue remains idle for max–wait–ms milliseconds or more.
The max–wait–ms setting also serves as a time–out for chunk load problems. Chunks normally load in much less than a second, so the default max–wait–ms value of 1000 ms avoids having edits freeze on chunk load errors.
Increase it if chunks fail to load in time.
Default Configuration File
The default configuration file is shown below. Note that the initial config file is created without the comments.
# These first 6 aren't configurable
issues: "https://github.com/boy0001/FastAsyncWorldedit/issues"
wiki: "https://github.com/boy0001/FastAsyncWorldedit/wiki/"
date: "24 Jun 2018 22:00:00 GMT"
build: "https://ci.athion.net/job/FastAsyncWorldEdit/1138"
commit: "https://github.com/boy0001/FastAsyncWorldedit/commit/4049014"
platform: "bukkit"
# Options: de, ru, tr
# Create a PR to contribute a translation: https://github.com/boy0001/FastAsyncWorldedit/new/master/core/src/main/resources
language: ''
# Enable or disable automatic updates
# - true = update automatically in the background
# - confirm = prompt an admin to confirm each update
# - false = do not update the plugin
update: "confirm"
# Send anonymous usage statistics
metrics: true
# Set true to enable WorldEdit restrictions per region (e.g. PlotSquared or WorldGuard).
# To be allowed to WorldEdit in a region, users need the appropriate
# fawe.<plugin> permission. See the Permissions page for supported region plugins.
region-restrictions: true
# FAWE will skip chunks when there's not enough memory available
prevent-crashes: false
# FAWE will cancel non admin edits when memory consumption exceeds this %
# - Bypass with `/wea` or `//fast` or `fawe.bypass`
# - Disable with 100 or -1.
max-memory-percent: 95
clipboard:
# Store the clipboard on disk instead of memory
# - Will be slightly slower
# - Uses 2 bytes per block
use-disk: true
# Compress the clipboard to reduce the size:
# - TODO: Buffered random access with compression is not implemented on disk yet
# - 0 = No compression
# - 1 = Fast compression
# - 2-17 = Slower compression
compression-level: 1
# Number of days to keep history on disk before deleting it
delete-after-days: 1
lighting:
# If packet sending should be delayed until relight is finished
delay-packet-sending: true
async: true
# The relighting mode to use:
# - 0 = None (Do no relighting)
# - 1 = Optimal (Relight changed light sources and changed blocks)
# - 2 = All (Slowly relight every blocks)
mode: 1
# If existing lighting should be removed before relighting
remove-first: false
# Generic tick limiter (not necessarily WorldEdit related, but useful to stop abuse)
tick-limiter:
# Enable the limiter
enabled: true
# The interval in ticks
interval: 20
# Max falling blocks per interval (per chunk)
falling: 64
# Max physics per interval (excluding redstone)
physics-ms: 10
# Max item spawns per interval (per chunk)
items: 256
# Whether fireworks can load chunks
# - Fireworks usually travel vertically so do not load any chunks
# - Horizontal fireworks can be hacked in to crash a server
fireworks-load-chunks: false
web:
# Should download urls be shortened?
# - Links are less secure as they could be brute forced
shorten-urls: false
# The web interface for clipboards
# - All schematics are anonymous and private
# - Downloads can be deleted by the user
# - Supports clipboard uploads, downloads and saves
url: "https://empcraft.com/fawe/"
# The web interface for assets
# - All schematics are organized and public
# - Assets can be searched, selected and downloaded
assets: "https://empcraft.com/assetpack/"
extent:
# Don't bug console when these plugins slow down WorldEdit operations
# - You'll see a message in console if you need to change this option
allowed-plugins: []
# Should debug messages be sent when third party extents are used?
debug: true
# Experimental options, use at your own risk
# - UNSAFE = Can cause permanent damage to the server
# - SAFE = Can be buggy but unlikely to cause any damage
experimental:
# [UNSAFE] Directly modify the region files. (OBSOLETE - USE ANVIL COMMANDS)
# - IMPROPER USE CAN CAUSE WORLD CORRUPTION!
anvil-queue-mode: false
# [SAFE] Dynamically increase the number of chunks rendered
# - Requires Paper: ci.destroystokyo.com/job/PaperSpigot/
# - Set your server view distance to 1 (spigot.yml, server.properties)
# - Based on tps and player movement
# - Please provide feedback
dynamic-chunk-rendering: -1
# [SAFE] Allows brushes to be persistent
persistent-brushes: false
# [SAFE] Enable CUI without needing the mod installed (Requires ProtocolLib)
vanilla-cui: false
# Disable using native libraries
disable-natives: false
# [SAFE] Keep entities that are positioned in non-air blocks when editing an area
# Might cause client-side FPS lagg in some situations
keep-entities-in-blocks: false
# This relates to how FAWE places chunks
queue:
# This should equal the number of processors you have
# - Set this to 1 if you need reliable `/timings`
parallel-threads: 8
progress:
# Display constant titles about the progress of a user's edit
# - false = disabled
# - title = Display progress titles
# - chat = Display progress in chat
display: "false"
# How often edit progress is displayed
interval: 1
# Delay sending progress in milliseconds (so quick edits don't spam)
delay: 5000
# When doing edits that effect more than this many chunks:
# - FAWE will start placing before all calculations are finished
# - A larger value will use slightly less CPU time
# - A smaller value will reduce memory usage
# - A value too small may break some operations (deform?)
target-size: 64
# Force FAWE to start placing chunks regardless of whether an edit is finished processing
# - A larger value will use slightly less CPU time
# - A smaller value will reduce memory usage
# - A value too small may break some operations (deform?)
max-wait-ms: 1000
# Increase or decrease queue intensity (ms) [-50,50]:
# 0 = balance of performance / stability
# -10 = Allocate 10ms less for chunk placement
# Too high will can cause lag spikes (you might be okay with this)
# Too low will result in slow edits
extra-time-ms: 0
# Loading the right amount of chunks beforehand can speed up operations
# - Low values may result in FAWE waiting on requests to the main thread
# - Higher values use more memory and isn't noticeably faster
preload-chunks: 32
# Discard edits which have been idle for a certain amount of time (ms)
# - E.g. A plugin creates an EditSession but never does anything with it
# - This only applies to plugins improperly using WorldEdit's legacy API
discard-after-ms: 60000
history:
# Should history be saved on disk:
# - Frees up a lot of memory
# - Persists restarts
# - Unlimited undo
# - Does not affect edit performance if `combine-stages`
use-disk: true
# Use a database to store disk storage summaries:
# - Enables inspection and rollback
# - Does not impact performance
use-database: true
# Record history with dispatching:
# - Much faster as it avoids duplicate block checks
# - Slightly worse compression since dispatch order is different
combine-stages: true
# Higher compression reduces the size of history at the expense of CPU
# 0 = Uncompressed byte array (fastest)
# 1 = 1 pass fast compressor (default)
# 2 = 2 x fast
# 3 = 3 x fast
# 4 = 1 x medium, 1 x fast
# 5 = 1 x medium, 2 x fast
# 6 = 1 x medium, 3 x fast
# 7 = 1 x high, 1 x medium, 1 x fast
# 8 = 1 x high, 1 x medium, 2 x fast
# 9 = 1 x high, 1 x medium, 3 x fast (best compression)
# NOTE: If using disk, do some compression (3+) as smaller files save faster
compression-level: 3
# The buffer size for compression:
# - Larger = better ratio but uses more upfront memory
# - Must be in the range [64, 33554432]
buffer-size: 531441
# The maximum time in milliseconds to wait for a chunk to load for an edit.
# (50ms = 1 server tick, 0 = Fastest).
# The default value of 100 should be safe for most cases.
#
# Actions which require loaded chunks (e.g. copy) which do not load in time
# will use the last chunk as filler, which may appear as bands of duplicated blocks.
# Actions usually wait about 25-50ms for the chunk to load, more if the server is lagging.
# A value of 100ms does not force it to wait 100ms if the chunk loads in 10ms.
#
# This value is a timeout in case a chunk is never going to load (for whatever odd reason).
# If the action times out, the operation continues by using the previous chunk as filler,
# and displaying an error message. In this case, either copy a smaller section,
# or increase chunk-wait-ms.
# A value of 0 is faster simply because it doesn't bother loading the chunks or waiting.
chunk-wait-ms: 1000
# Delete history on disk after a number of days
delete-after-days: 7
# Delete history in memory on logout (does not effect disk)
delete-on-logout: true
# If history should be enabled by default for plugins using WorldEdit:
# - It is faster to have disabled
# - Use of the FAWE API will not be effected
enable-for-console: true
# Should redo information be stored:
# - History is about 20% larger
# - Enables use of /redo
store-redo: true
# Assumes all edits are smaller than 4096x256x4096:
# - Reduces history size by ~10%
small-edits: false
# Paths for various directories
paths:
tokens: "tokens"
# Put any minecraft or mod jars for FAWE to be aware of block textures
textures: "textures"
heightmap: "heightmap"
history: "history"
# Multiple servers can use the same clipboards
# - Use a shared directory or NFS/Samba
clipboard: "clipboard"
# Each player has their own sub directory for schematics
per-player-schematics: true
# The "default" limit group affects those without a specific limit permission.
# To grant someone different limits, copy the default limits group
# and give it a different name (e.g. newbie). Then give the user the limit
# permission node with that limit name (e.g. fawe.limit.newbie )
limits:
default:
# Max actions that can be run concurrently (i.e. commands)
max-actions: 1
# Max number of block changes (e.g. by `//set stone`).
max-changes: 50000000
# Max number of blocks checked (e.g. `//count stone` which doesn't change blocks)
max-checks: 50000000
# Number of times a change can fail (e.g. if the player can't access that region)
max-fails: 50000000
# Allowed brush iterations (e.g. `//brush smooth`)
max-iterations: 1000
# Max allowed entities (e.g. cows)
max-entities: 1337
# Blockstates include Banner, Beacon, BrewingStand, Chest, CommandBlock,
# CreatureSpawner, Dispenser, Dropper, EndGateway, Furnace, Hopper, Jukebox,
# NoteBlock, Sign, Skull, Structure
max-blockstates: 1337
# Maximum size of the player's history in Megabytes:
# - History on disk or memory will be deleted
max-history-mb: -1
# Maximum time in milliseconds //calc can execute
max-expression-ms: 50
# Cinematic block placement:
# - Adds a delay to block placement (ms/block)
# - Having an artificial delay will use more CPU/Memory
speed-reduction: 0
# Place chunks instead of individual blocks:
# - Disabling this will negatively impact performance
# - Only disable this for compatibility or cinematic placement
fast-placement: true
# Should WorldEdit use inventory?
# 0 = No inventory usage (creative)
# 1 = Inventory for removing and placing (freebuild)
# 2 = Inventory for placing (survival)
inventory-mode: 0
# Should large edits require confirmation (>16384 chunks)
confirm-large: true
This Wiki is for Legacy Versions (1.8 - 1.12.2). Check here for 1.13+ versions: https://github.com/IntellectualSites/FastAsyncWorldEdit-Documentation/