☑ FastAsyncWorldEdit

Yeah some advice, When getting generic problems like this, start off with posting your Sponge version, WorldEdit version, and Fast Async WE versions installed on the server.

At the moment we have even less information then you to solve the problem with, we need something to work with.

Also if any errors are posted in console on startup, or when running the commands, that’s important too.

I’m experiencing an issue with this plugin.

Minecraft 1.10.2
SpongeForge 1.10.2-2098-5.0.0-BETA-1798 running on Forge verison 12.18.2.2099
The worldedit Jar is named “worldedit-forge-mc1.10.2-6.1.4-SNAPSHOT” - MultiMC also has “3622-ddff8ec” in the version field.
FAWE version is forge110-16.10.03-135d936-343-9.7.4

The plugin seems to load and run mostly fine. Using the wooden axe to select positions works fine, but when I go to //set I see a message in chat that there has been an error:
java.lang.ClassCastException: com.boydti.fawe.wrappers.WorldWrapper cannot be cast to com.sk89q.worldedit.forge.ForgeWorld
The full stacktrace: http://pastebin.com/KNLqysU0

I’m very new to Sponge so it may very well be that I didn’t install something right… I just have the WorldEdit forge Jar and the FAWE Forge jar… do I need anything else?

Any help would be greatly appreciated.

Does this work with SpongeAPI worldedit?

You shouldn’t use FAWE due to it’s dangerous behavior, and frankly the speed claims here are ridiculous. Just use WorldEdit.

2 Likes

I’ve been using it for months. What’s dangerous about it?

1 Like

This improves performance and allows the pasting of immense schematics.

Perhaps you’re just unable to work out how to configure it correctly? :slight_smile:

FAWE likes to disable safety checks and work around the API in ways which can result in world corruption.

1 Like

I performed the test a while ago to forge WorldEdit (1.8). I have no idea if it’s still valid (probably not). In my test FAWE could change 50,000,000 blocks in 0.36s, whilst WorldEdit had huge performance issues from Sponge’s cause tracking and took 10s for a single chunk.

The only reason I did the test was because someone questioned my significantly less lucrative performance estimates (based on forge without sponge’s cause tracking overhead). If it makes you happy I’ll remove that stat, despite it being correct at the time.

It was the effective bytes/block, not total bytes.

WorldEdit stores blocks as two arrays of block change objects (forwards and backwards) Each change has the previous and next block state as well as the position. This works out to be about 256 bytes per block, most of which is just overhead. FAWE can encode a block as 5-9 bytes (depending on the edit/configuration). After this, FAWE uses the LZ4 compression algorithm (among other things) to further reduce the bytes.

The compression works best when there are a lot of blocks (e.g. tens of millions of blocks with the highest compression could be 500,000x smaller than default WorldEdit). With something like //set stone, a compression algorithm can have a really good ratio since all the blocks are the same. Think of it like this, you have a bunch of numbers which are all the same, a simple compression algorithm might store the number and how many times it occurs.

1.) You can configure whether it will use Disk or RAM in the config.
2.) After compression, it’s really not saving all that much data, so RAM vs Disk isn’t that important.
3.) It flushes to disk separate to the actual operation, so it really doesn’t matter which is slower. It’s usually done by the time the next command is run.
4.) Having it on disk means it’s persistent and you can use FAWE’s logging/rollback. This is really useful.

Yes.

Your assumption of how it works is incorrect. In an async thread, FAWE groups the block changes into their respective chunks (so that it can be efficiently swapped out later). On the main thread, required chunks are being loaded and data passed off to the async thread. Then in parallel while the main thread is locked, FAWE will swap out the bytes for the chunks. The blocks are not being changed async.

I appreciate your skepticism but I must decline. Aside from taking a lot of time, you’ve said every one of my statements is a lie, so how would more tests convince you that it’s safe or faster?

  • WorldEdit is notorious for using gigantic amounts of memory and crashing the server
  • There are servers (300+ players) where they get access to WorldEdit. By default 15 items of history are stored per player, this adds up, even with a tall ceiling.
  • The majority of servers do not fit in your category of “real servers” according to the metrics.
  • The premise of memory vs disk being a bottleneck is false (as outlined above)

As mentioned, FAWE does not change blocks async, it merely uses it to perform the bulk of calculations off the main thread.

Also, if you had spent the time I have modifying WorldEdit code you would have slightly less respect for it. Sure, the API is designed well, but there are a lot of huge performance concerns.

An easy way to see the difference in just design is to disable FAWE’s NMS placer on spigot so that it’s just using the API to perform changes. Yes, the same API WorldEdit uses to change the blocks, and none of that “unsafe” code you seem to have a problem with. Hint: It’s faster than AsyncWorldEdit’s NMS placer.

You know what can cause world corruption? WorldEdit crashing the server because you ran out of memory or did an operation that took too long. Have any proof that FAWE causes world corruption?

Which of the FAWE versions would I use for the spongeAPI version? I have a small spongevanilla hub server that I want to make some big changes to, and I can’t find the proper version for sponge, which you say this plugin supports.

The “WorldEdit for SpongeAPI” uses NMS and would break if SpongeVanilla didn’t happen to use the same minecraft server internally as Forge. You can see it depending on Forge mappings in the build script.

There’s no real benefit of using SpongeVanilla over SpongeForge. It’s less stable as WorldEdit-SpongeAPI breaks for NMS updates AND Sponge updates (in the past sponge has had a lot more breaking changes than NMS). The Sponge WorldEdit also lacks some functionality (regen, block bag etc.)

Anywho, that’s just my excuse for being lazy and not updating this in a while. Here’s FAWE for SpongeVanilla 1.11: http://empcraft.com/fawe/latest.php?sponge

Your statement regarding WorldEdit for Sponge using NMS is mostly invalid as a comparison to FAWE, as you do the same.

1 Like

Oh, it was mostly intended as a complaint against SpongeVanilla. I think basing it on glowstone or some other clean room implementation would be more ideal. Right now it’s basically a handicapped SpongeForge which kinda makes maintaining another version for it feel pointless.

Anywho, I’m sorry that it sounded like a comparison between FAWE and WorldEdit.

Getting a crash on latest build.
worldedit-sponge-mc1.10.2-6.1.5-SNAPSHOT-dist.jar
spongeforge-1.10.2-2221-5.1.0-BETA-2185.jar
FastAsyncWorldEdit-sponge-17.02.20-b16276e-530-10.8.30.jar

https://hastebin.com/befiwewegi.rb

It says there is a duplicate, but I dont see one at all.

Sponge doesn’t allow plugins to control their load order AFAIK. FAWE needs to load before WorldEdit to function correctly. This has always been the case, however because of this FAWE would stop working for some people.

You now need to either delete WorldEdit-Sponge (keep FAWE-Sponge), or switch to FAWE-Forge + WorldEdit-Forge.

Quote from the docs:

Lifecycle events are given to plugins in this order. For example, plugin A containing “[required-]after:B” will get each event after plugin B has completed work for the given state.

https://docs.spongepowered.org/stable/en/plugin/lifecycle.html

I’d say it’s possible to load plugin A before/after plugin B.

1 Like

FAWE needs to load before WorldEdit (where it replaces its classes). Sponge allows adding a plugin dependency, however that would ensure it loads after another plugin, not before. The lifecycle events that you linked isn’t what I need since the classes are already loaded by then.

1 Like

Hey there, I have been experiencing some problems
Every time I click with a brush, it executes it twice
If you could help me out than that would very much be appriciated :slight_smile:

Best Regards

  • Decorated

I’m having a couple strange issues with FAWE.

1.)
When I use FAWE Sponge I can’t use WorldEdit with it as it says I have a duplicate mod (FAWE is counting itself as Worldedit)

So in order to use FAWE-Sponge I have to remove worldedit, everything appears to work. Whats the benefit of running FAWE alongside WE and downside of just running FAWE?

2.)
When I run //undo it does what its supposed to, except in a few random chunks it just completely ignores. Example: http://imgur.com/qhsZx9r

In those chunks I also can’t run //cut in those affected chunks and the only worldedit command that seems to work is //replace and //regen

Also while writing this I noticed the console is putting out an error:

Things to note:
I have tried Forge & sponge FAWE, both have this issue. Simply using WE this issue does not persist.

I am running SpongeForge 1.10.2-2281-5.2.0-BETA-2274 and FAWE 17.4.20-1ed9b3b-656

I am trying to paste a Schematic and //undo to re-position it however it doesnt remove the whole paste.

Sorry if theres a lot of information, I tried to cover everything.

1 Like

having the same issue, but we cant even run FAWE without worldedit, it gives an error when we try to use the axe.

Been having lots of issues with FAWE. Hope this is still being maintained.