From d7f8b3dc3bd97ec91b03f382ce9eafea63311cf4 Mon Sep 17 00:00:00 2001 From: Jesse Boyd Date: Sat, 2 Apr 2016 02:36:35 +1100 Subject: [PATCH] fixing formatting --- src/main/java/com/boydti/fawe/Fawe.java | 73 +++++++++++++------------ 1 file changed, 37 insertions(+), 36 deletions(-) diff --git a/src/main/java/com/boydti/fawe/Fawe.java b/src/main/java/com/boydti/fawe/Fawe.java index 9be6a33a..e818a3a6 100644 --- a/src/main/java/com/boydti/fawe/Fawe.java +++ b/src/main/java/com/boydti/fawe/Fawe.java @@ -42,42 +42,43 @@ import com.sk89q.worldedit.function.visitor.RecursiveVisitor; import com.sk89q.worldedit.function.visitor.RegionVisitor; import com.sk89q.worldedit.history.change.EntityCreate; import com.sk89q.worldedit.history.change.EntityRemove; - [ WorldEdit action] - * | - * \|/ - * [ EditSession ] - The change is processed (area restrictions, change limit, block type) - * | - * \|/ - * [Block change] - A block change from some location - * | - * \|/ - * [ Set Queue ] - The SetQueue manages the implementation specific queue - * | - * \|/ - * [ Fawe Queue] - A queue of chunks - check if the queue has the chunk for a change - * | - * \|/ - * [ Fawe Chunk Implementation ] - Otherwise create a new FaweChunk object which is a wrapper around the Chunk object - * | - * \|/ - * [ Execution ] - When done, the queue then sets the blocks for the chunk, performs lighting updates and sends the chunk packet to the clients - * - * Why it's faster: - * - The chunk is modified directly rather than through the API - * \ Removes some overhead, and means some processing can be done async - * - Lighting updates are performed on the chunk level rather than for every block - * \ e.g. A blob of stone: only the visible blocks need to have the lighting calculated - * - Block changes are sent with a chunk packet - * \ A chunk packet is generally quicker to create and smaller for large world edits - * - No physics updates - * \ Physics updates are slow, and are usually performed on each block - * - Block data shortcuts - * \ Some known blocks don't need to have the data set or accessed (e.g. air is never going to have data) - * - Remove redundant extents - * \ Up to 11 layers of extents can be removed - * - History bypassing - * \ FastMode bypasses history and means blocks in the world don't need to be checked and recorded - */ + +/**[ WorldEdit action] +* | +* \|/ +* [ EditSession ] - The change is processed (area restrictions, change limit, block type) +* | +* \|/ +* [Block change] - A block change from some location +* | +* \|/ +* [ Set Queue ] - The SetQueue manages the implementation specific queue +* | +* \|/ +* [ Fawe Queue] - A queue of chunks - check if the queue has the chunk for a change +* | +* \|/ +* [ Fawe Chunk Implementation ] - Otherwise create a new FaweChunk object which is a wrapper around the Chunk object +* | +* \|/ +* [ Execution ] - When done, the queue then sets the blocks for the chunk, performs lighting updates and sends the chunk packet to the clients +* +* Why it's faster: +* - The chunk is modified directly rather than through the API +* \ Removes some overhead, and means some processing can be done async +* - Lighting updates are performed on the chunk level rather than for every block +* \ e.g. A blob of stone: only the visible blocks need to have the lighting calculated +* - Block changes are sent with a chunk packet +* \ A chunk packet is generally quicker to create and smaller for large world edits +* - No physics updates +* \ Physics updates are slow, and are usually performed on each block +* - Block data shortcuts +* \ Some known blocks don't need to have the data set or accessed (e.g. air is never going to have data) +* - Remove redundant extents +* \ Up to 11 layers of extents can be removed +* - History bypassing +* \ FastMode bypasses history and means blocks in the world don't need to be checked and recorded +*/ public class Fawe { /** * The FAWE instance;