Converted configuration docs from asciidoc to markdown (#38)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

fastasyncworldedit/configuration/configuration.md

@@ -0,0 +1,75 @@
+# Configuration
+
+## Introduction
+
+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 finetuning attempts.  To reset the config.yml file, delete it and restart 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 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 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 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 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 from 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 not helpful since most related changes occur in less than 64 chunks processing time. ALSO if set exceptionally large, it would reduce FAWE's ability to recover from exceptionally 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.

fastasyncworldedit/configuration/permissions.md

@@ -0,0 +1,38 @@
+# Permissions
+
+> **Info:** For command related permissions, see [here](../basic-commands/main-commands-and-permissions.md).
+
+## Admin permissions
+
+- `fawe.admin` (allow bypassing through `/wea` command)
+- `fawe.bypass` (automatically bypass worldedit restrictions)
+- `worldedit.anyblock` (bypass worldedit's `disallowed-blocks`)
+- `worldedit.inventory.unrestricted` (bypass inventory restrictions if those are enabled)
+
+## User permissions
+
+- `fawe.limit.<limitgroup>` (Grants the user the specific group of limits.)
+- [`fawe.permpack.basic`](https://github.com/IntellectualSites/FastAsyncWorldEdit/blob/main/worldedit-bukkit/src/main/resources/plugin.yml#L31) (A bunch of worldedit perms which are okay to use on a creative server)
+- `worldedit.navigation.jumpto.tool` (Access to the jumpto wand)
+- `worldedit.navigation.thru.tool` (Access to the thru wand)
+
+## Region permissions
+
+FAWE by default is restricted to regions, this is useful for servers wanting to give ordinary players access to WorldEdit.  To enable region restrictions, set config setting `region-restrictions` true, and give players the appropriate region permission.  If you want an admin to be able to WorldEdit anywhere using `//wea` command, give them the `fawe.admin` permission.
+
+- `fawe.plotsquared` - Allow PlotSquared owners (`+/plot setowner ...+`) and trusted (`+/plot trust ...+`) to use WorldEdit. NOTE: This permission is activated by default in the [plugin.yml](https://github.com/IntellectualSites/FastAsyncWorldEdit/blob/e40a657faf993536133b2e1bbe771a5c96619bd7/worldedit-bukkit/src/main/resources/plugin.yml#L14-L17) ! For a permission override it is advised to use this permission instead of the child `fawe.plotsquared.trusted` because of a higher prioritization.
+- `fawe.plotsquared.member` - Allows PlotSquared members (`+/plot add ...+`) to use WorldEdit.
+- `fawe.plotsquared.admin` - Allows WorldEdit in any PlotSquared plots (but not on roads).
+- `fawe.griefprevention`
+- `fawe.plotme`
+- `fawe.towny`
+- `fawe.towny.member`
+- `fawe.towny.*`
+- `fawe.worldguard` - Allow WorldGuard region owners (`+/rg addowner ...+`) to use WorldEdit.
+- `fawe.worldguard.member` - Allow WorldGuard region members (`+/rg addmember ...+`) to use WorldEdit.
+- `fawe.worldguardextraflags` - If you've installed WorldGuard Extra Flags this permission is also used.
+
+## Extended WorldEdit permissions
+
+- `worldedit.schematic.load.other` (allow loading of schematics in the main schematics folder via `../` when per-player-schematics are enabled)
+- `worldedit.schematic.save.other` (allow saving of schematics in the main schematics folder via `../` when per-player-schematics are enabled)