Incompatibility with CraftBook gate mechanic.

[mibby]

Paper dev 525 (Spigot 1.13.2) FAWE 1.13 compiled as of commit https://github.com/IntellectualSites/FastAsyncWorldEdit-1.13/commit/24fbc86cdd79b8ce13359342bc422ce1fb25a0d2 CraftBook dev 4484

CraftBook gate mechanic does not work with FAWE. The gate refuses to find/set the blocks to toggle. Downgrading to vanilla worldedit, CraftBook mechanics work fine again.

[AeSix]

Does adding CraftBook to the "allowed-plugins" section in the FAWE config.yml result in any changes to this?

[mibby]

Doesn't allowed-plugins only make it so notifications of slowdown caused by that plugin never gets a message sent to console?

CraftBook works fine with FAWE 1.12 and vanilla WorldEdit 1.13, so I assume it is something in FAWE 1.13 causing the breakage.

[IronApollo]

Iirc adding a plugin to the allowed-plugins list suppresses extent creation warnings from wrapping extents created by the plugin in question. That would not have any effect on the issue described.

Can you describe what exactly the gate mechanic is? I have no experienced with that plugin.

[mibby]

http://wiki.sk89q.com/wiki/CraftBook/Gates

[mibby]

Gate mechanic is still broken with FAWE as of commit https://github.com/IntellectualSites/FastAsyncWorldEdit-1.13/commit/85bfd16d7c16613e79f49d3acaa17007c09baa3e (3/25 compile). CraftBook dev 4491

[mibby]

Weekly re-test. Still broke as of commit https://github.com/IntellectualSites/FastAsyncWorldEdit-1.13/commit/8afd96f03b3ea797208a681672d620eb62e1b9b7.

[AeSix]

The devs will post an update when they attempt to resolve this issue. Empire is back working on FAWE, and there may be some work towards this in the near future. It may also be resolved once FAWE is API compatible with WorldEdit 7. As far as my understanding, they're going targeting WE7 beta 5 right now until beta 6 is out. It's not easy for them to keep targeting snapshots.

FAWE is not production ready, and you should use WorldEdit 7 until FAWE is ready.

[mibby]

@boy0001 For reference, getting this error now at startup with FastAsyncWorldEdit-Breaking dev 2.

[00:34:13] [Server thread/WARN]: [CraftBook] Failed to load mechanic: Gate
java.lang.NoClassDefFoundError: com/sk89q/worldedit/world/block/FuzzyBlockState
    at java.lang.Class.getDeclaredConstructors0(Native Method) ~[?:?]
    at java.lang.Class.privateGetDeclaredConstructors(Class.java:3138) ~[?:?]
    at java.lang.Class.getConstructor0(Class.java:3343) ~[?:?]
    at java.lang.Class.newInstance(Class.java:556) ~[?:?]
    at com.sk89q.craftbook.bukkit.CraftBookPlugin.setupCraftBook(CraftBookPlugin.java:563) ~[?:?]
    at com.sk89q.craftbook.bukkit.CraftBookPlugin.onEnable(CraftBookPlugin.java:451) ~[?:?]
    at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:265) ~[patched_1.13.2.jar:git-Paper-603]
    at org.bukkit.plugin.java.JavaPluginLoader.enablePlugin(JavaPluginLoader.java:334) ~[patched_1.13.2.jar:git-Paper-603]
    at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManager.java:412) ~[patched_1.13.2.jar:git-Paper-603]
    at org.bukkit.craftbukkit.v1_13_R2.CraftServer.enablePlugin(CraftServer.java:443) ~[patched_1.13.2.jar:git-Paper-603]
    at org.bukkit.craftbukkit.v1_13_R2.CraftServer.enablePlugins(CraftServer.java:357) ~[patched_1.13.2.jar:git-Paper-603]
    at net.minecraft.server.v1_13_R2.MinecraftServer.l(MinecraftServer.java:608) ~[patched_1.13.2.jar:git-Paper-603]
    at net.minecraft.server.v1_13_R2.MinecraftServer.a(MinecraftServer.java:570) ~[patched_1.13.2.jar:git-Paper-603]
    at net.minecraft.server.v1_13_R2.MinecraftServer.a(MinecraftServer.java:431) ~[patched_1.13.2.jar:git-Paper-603]
    at net.minecraft.server.v1_13_R2.DedicatedServer.init(DedicatedServer.java:316) ~[patched_1.13.2.jar:git-Paper-603]
    at net.minecraft.server.v1_13_R2.MinecraftServer.run(MinecraftServer.java:787) ~[patched_1.13.2.jar:git-Paper-603]
    at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: java.lang.ClassNotFoundException: com.sk89q.worldedit.world.block.FuzzyBlockState
    at java.net.URLClassLoader.findClass(URLClassLoader.java:471) ~[?:?]
    at org.bukkit.plugin.java.PluginClassLoader.findClass(PluginClassLoader.java:140) ~[patched_1.13.2.jar:git-Paper-603]
    at org.bukkit.plugin.java.PluginClassLoader.findClass(PluginClassLoader.java:86) ~[patched_1.13.2.jar:git-Paper-603]
    at java.lang.ClassLoader.loadClass(ClassLoader.java:588) ~[?:?]
    at java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[?:?]
    ... 17 more

[boy0001]

Ah, it uses fuzzy blocks.

[Tsoccerguy3]

Just tested all our Gates on our server , they are all not working and same error , as of the latest commit today

[Tsoccerguy3]

Is there a fix that anyone has found ?

[AeSix]

according to bstats, less than 10% of FAWE installations are using CraftBook. That's assuming ALL craftbook installs are also using FAWE. Taking a guess at only half of the CraftBook installs are using FAWE, that's roughly 330 servers minimum utilizing both. At most, there's 678 utilizing both. In comparison to the nearly 8700 installs of FAWE.

My point, is that yes, there's a lot of CraftBook servers out there, but it's a small percentage of issues when compared to all of the other things which still need to be resolved. The devs still have plenty to do with base Minecraft mechanics before worrying about a somewhat niche plugin.

I am sure that the devs will eventually fix the issues, if possible. But please understand that CraftBook compatibility is a pretty low priority in comparison to all of the other issues they're facing. And please remember that none of the devs are full time paid employees focusing solely on FAWE - they are all volunteers writing and fixing as they have time and interest.

I'm also certain that the devs will note in the changelogs, or close the ticket once there is an update worth your time to test.

Additionally, perhaps this is not actually an issue which FAWE must resolve, but should be resolved with CraftBook fixes. Maybe politely ask @me4502 if he is aware of the issue, and could possibly take a look at it, as he knows the CraftBook code. If nothing else, he may be able to work with the FAWE devs, or even supply a PR to FAWE which can be used to correct the issue.

If you wish to continue to test CB/FAWE builds and update those test results, it would be very helpful to all to know some basic information: Server implimentation: Server build/version: FAWE build: CraftBook build: And if you are running other plugins or not.

I suggest testing with Spigot (and Paper as well if you wish) with as close to default configs as you can use with your setup, using the last build available for 1.13.2 (I wouldn't even touch 1.14 any time soon for testing) And making sure you're using the release builds and dev builds of the plugins. This should be done with every new build (release or dev/breaking/experimental) build of FAWE and CB. Or wait until the devs say they've attempted to resolve the issue and use builds containing that fix.

At least then bumps to this issue will have useful, relevant data.

[me4502]

Do note that CraftBook’s bStats setup was broken for a large amount of time, so there’s only like 5 builds where it counts.

If it works with WorldEdit, but not FAWE, it’s 100% a FAWE issue and should be fixed in FAWE.

[Tsoccerguy3]

Do note that CraftBook’s bStats setup was broken for a large amount of time, so there’s only like 5 builds where it counts.

If it works with WorldEdit, but not FAWE, it’s 100% a FAWE issue and should be fixed in FAWE.

I see that its a fuzzy blocks issue in FAWE , Do you have a fix that you can push to FAWE ? Thanks for taking the time to look at this .

[Tofuus]

Jesse removed it in this commit 33f5322fda3afd3c9a3ca07028511a3772093db6. Presumably to replace it with his own solution.

[me4502]

That's considered an issue with FAWE then. If they're breaking the API contracts of the WorldEdit API, then it's not filling the dependency requirement of WorldEdit.

If it's not going to implement the API, it should stop pretending to be WorldEdit. This is 99% of the reason I preferred it using patching.

[AeSix]

@me4502 I appologize if I sounded like I was blaming you or CraftBook. I don't know the code of any of the projects and was merely stating that it was a possibility. I didn't realized CraftBook had an issue with bstats either. However, my main object was to get @Tsoccerguy3 to understand that there is a lot at play here, a lot of issues in FAWE, a lot of code to check/write/fix... and not a lot of time for the devs to focus on what (at least at the time) seemed to be a niche combination of plugins, and that they would more than likely address the issue in time.

Thank you for replying and setting things straight. I also agree that FAWE seems to have strayed considerably far from WorldEdit, but I know that the devs want to maintain drop-in replacement with WorldEdit. With the devs being more or less unfamiliar with the code, Jesse's absence and the massive amounts of changes, I think it's a bit premature to drop the idea of FAWE being a drop-in replacement. Though, I've not be involved as heavily lately, I still believe this all to be accurate.

@Tsoccerguy3 is there a build including the changes from https://github.com/IntellectualSites/FastAsyncWorldEdit-1.13/commit/33f5322fda3afd3c9a3ca07028511a3772093db6 for which you can test with CraftBook? It would help to know if it fixes the issue. I would test it myself, however I have never once used CraftBook, and would take a week to learn enough to test it properly.

[Tsoccerguy3]

That's considered an issue with FAWE then. If they're breaking the API contracts of the WorldEdit API, then it's not filling the dependency requirement of WorldEdit.

If it's not going to implement the API, it should stop pretending to be WorldEdit. This is 99% of the reason I preferred it using patching.

Hi Matt , Just to clarify , the last version that Craftbook [Gates] was working , was a snapshot I compiled for 1.12.2 . It worked with World Edit and FAWE in Spigot 1.12.2 .

Currently there has never been a Craftbook build that [Gate] has worked in 1.13.2 using World Edit or FAWE . The ID's are messed up and incomplete .

Testing , If you test to see if [Gate] works , you will find that it does not . Try the final build of Spigot 1.13.2 with the latest compile of World Edit 7 and the latest compile of Craftbook . You will see that the various materials can not be identified ; example ... , a fence has 2 states a}. a Post and b}. a Fence .

I have tried loading the sign with various materials , selecting and pasting materials into the [Gate] frame and manually placing materials in to the frame . None work .

The config file is out of date with new 1.13.2 names , not really a problem if the names were internally corrected to be in sync with the names in the config .

Thanks for helping out I am currently updating Craftbook Mechanics for , The Golden City Map on Sanacraft https://www.planetminecraft.com/server/sanacraft/

https://www.artstation.com/artwork/baD5or

[Tsoccerguy3]

Trying the various ways to add the material to the [Gate] frame . The closest i came to a working gate , was setting material by //set oak_fence , using the latest compile of World Edit 7 and Craftbook . It worked 1 time and then it failed to find the gate

[me4502]

Gates work perfectly fine with WorldEdit, as does the rest of CraftBook. If it’s not for you, you’re either not using the latest versions or you’ve change the configuration and broken it.

[Tsoccerguy3]

Another Gate anomaly , because the gate frame has a decorative edge on the outside , the gate gets made from intersecting fence state . This is from todays compile of worldedit and craftbook.

[Gate] is still not working with FastAsyncWorldEdit-bukkit-1.13.10

[Tsoccerguy3]

Ah, it uses fuzzy blocks.

When you do fininish updating the issue with fuzzy blocks , as you can see there is also a problem with the different states of Fence , glass panes and iron bars. the gates worked ok in 1.12.2

[AeSix]

@Tsoccerguy3 I just built a server to test this; I installed: WorldEdit 7 build 4238 CraftBook 3 build 4492 Both plugins have default configurations, with the exception of adding "- Gate" to the enabled mechanics list in CraftBook's config.

I then went and learned how to make a gate because I have never used CraftBook before.

I successfully built and operated a basic gate. There is no issues with the fence state, there is no issue with the operation, it just worked like I expect a gate to work. All but the top row of fence disappear upon "opening" the gate (as is explained as proper behavior), and are recreated upon "closing" the gate.

The ONLY exception to the above is when using a decorative edging on the sides/top of the gate as in your last example. Yes, the fences have dangling connectors. This is because of the overlapping stone at the top of the gate, which the top row of fence are connected to. I assume CraftBook simply stacks the top most row of fence down when "closing", and thus duplicating the gate's state exactly as it is in the top remaining row. This can be overcome by setting the gate material, by hand with WorldEdit to oak_fence, or by allowing for either an air block on both face sides of the gate's top row, or using blocks which fence cannot connect to.

I personally like the spiked gate feeling this "bug" gives, and as it is using standard WE mechanics to duplicate the fence downward, it's not something I see needs to be resolved within WorldEdit, but possibly withing CraftBook as a "ensure smooth gates" config option which would then toggle code that would go through and verify each fence section and correct it's state upon "closing" - which will slow down the gate closing. IF it's even considered a bug, but FAWE is not the place to determine that.

I have also confirmed that no recent build of FAWE works with the gates, including 105, which was built very recently, and at this time is the newest build for 1.13.

To summaraize: CraftBook with WE7 works with expected behavior. CraftBook with FAWE does NOT work, and says so very clearly in the console. The devs are well aware of the issue. I am sure when one of them finally tackles fuzzyblocks and is confident in the code's functional operation towards this end, he will make it known.
Additionally, I have asked if anyone is currently working on fuzzyblock code for FAWE. ~I will update this post with the response when I receive one.~ UPDATE: NMF seems to believe this should be working. Update 2: IronApollo is leaving the decisions to Empire, and thus this issue will be resolved when/if/how Empire sees fit. This is due to the changes needed to code are in core classes which will affect other major areas of FAWE.

In the mean time, there is no point in testing every new build if there is no mention of fuzzyblocks / craftbook / gates / fences.

If you ABSOLUTELY MUST have functioning CraftBook, use WorldEdit 7 beta5, or one of the dev builds, specifically 4238 as it is known to work.

[Tsoccerguy3]

Gates work perfectly fine with WorldEdit, as does the rest of CraftBook. If it’s not for you, you’re either not using the latest versions or you’ve change the configuration and broken it.

I tested your latest Craftbook build 4500 with Fawe 's breaking build (the fuzzy block commit ) , I can now get the [Gate] working 1 time by setting , //set 85 or 101, the old ID's for Oak Fence and Iron Fence , but that just sets the post variation of the fence or glass pane. The [Gate] will open 1 time up and 1 time down The material is now conected to each other but not to the [Gate] frame as in the pictures above. On subsequent toggles , it can not find gate . Setting the material Manually and Toggle gate , it says the [Gate] is toggled , but it is not Stocking the sign shows an increase in material loaded to the sign , but does nothing else selecting area and //set NEW NAMES for material , the sign says that it found the material in the [Gate] frame with a count 0 . Toggle [Gate] says gate not found

These are my findings ,

[AeSix]

Excellent! Not that it's still not working, but good descriptions for Jesse to be able to figure it out better.

Are there any errors in the console/log? Those would help as well!

[Tsoccerguy3]

Output From Console , no errors , just WARN [CraftBook] Enabling CraftBook v3.10-SNAPSHOT;4500-4cecc6e [15:58:44] [Server thread/INFO]: [CraftBook] Loading persistent data from YAML! [15:58:44] [Server thread/INFO]: [CraftBook] Successfully added 1 CommandItems! [15:58:44] [Server thread/INFO]: [CraftBook] Registered 3 custom recipes! [15:58:44] [Server thread/INFO]: [CraftBook] 1 cauldron recipe(s) loaded [15:58:44] [Server thread/INFO]: [CraftBook] Enumerating chunks for self-triggered components... [15:58:44] [Server thread/INFO]: [CraftBook] 1875 chunk(s) for 3 world(s) processed (37ms elapsed) [15:58:44] [Server thread/WARN]: [CraftBook] ==================================================== [15:58:44] [Server thread/WARN]: [CraftBook] CraftBook works better if you use Paper [15:58:44] [Server thread/WARN]: [CraftBook] as your server software.

[15:58:44] [Server thread/WARN]: [CraftBook] Paper offers significant performance improvements, [15:58:44] [Server thread/WARN]: [CraftBook] bug fixes, security enhancements and optional [15:58:44] [Server thread/WARN]: [CraftBook] features for server owners to enhance their server.

[15:58:44] [Server thread/WARN]: [CraftBook] Paper includes Timings v2, which is significantly [15:58:44] [Server thread/WARN]: [CraftBook] better at diagnosing lag problems over v1.

[15:58:44] [Server thread/WARN]: [CraftBook] All of your plugins should still work, and the [15:58:44] [Server thread/WARN]: [CraftBook] Paper community will gladly help you fix any issues.

[15:58:44] [Server thread/WARN]: [CraftBook] Join the Paper Community @ https://papermc.io [15:58:44] [Server thread/WARN]: [CraftBook] ====================================================

[Tsoccerguy3]

Tried with Paper624 . No Errors or Warnings on anything .To get the Gate to recognize all the different variations of the blocks in the gate , is i guess , what the issue is at this point

[AeSix]

does "or anything" mean "or working gates" or does it mean that it's working properly with that combination?

[Tsoccerguy3]

does "or anything" mean "or working gates" or does it mean that it's working properly with that combination? I was surprised after updating all plugins to the latest available , the console was quiet of errors and warnings , plugins preferring Paper over Spigot .

I mean , the console error is gone . I guess the final issue is with the gate recognizing the new names and the states . The gate works 1 time and the material changes . I think the problem is very close to being resolved at this point .

[Tsoccerguy3]

As a control , I tested

WorldEdit build 4253 Craftbook build 4500

Gates are working ,

[Tsoccerguy3]

I have found the reason why the [Gate] will only work 1 time up and 1 time down .

https://minecraft.gamepedia.com/Block_states , look under Fence

oak fence , old ID = 85 or new ID , mincraft:oak_fence is just the unconnected oak post . player is unable to place this fence state manually because you will always get a connected fence state . When you set the [Gate] material as in //set minecraft:oakfence you will get a [Gate] made up of just oak fence posts as in the picture above . This will satisfy the declared material in the mechanisms.yml config file , so the [Gate] will work 1 time up and 1 time down . When the fence is down the connected state of the fence is no longer minecraft:oak_fence , but is in another state such as example , minecraft:oak_fence[north=true] .

Since the gates work in all Worldedit versions with craftbook , the fix may be to just look to see how Worldedit handles the different states of fences etc... vs. FAWE

Only minecraft:oak_fence or other material declared in Craftbooks mechanisms.yml , with a data value of false will work So in conclusion , if minecraft:oak_fence , or any other declared material has a data value of true , then the [Gate] will not work

A [Gate] frame of 5 x 7 with a single oak_fence post down the center has no issues and works continuously ,

[Tsoccerguy3]

Constructing a [Gate] with spaces between the posts , works perfectly opening and closing .

[Tsoccerguy3]

constructing a [Gate] with connected fence , fails to find gate or operate at all

[Tsoccerguy3]

Hi Matt , had a question about what to put in the mechanisms.yml to create this intersect Fence state on purpose ? , player's really like the 3D effect that the [Gate] has .

Gate: allow-redstone: true limit-columns: true max-columns: 14 blocks:

• minecraft:acacia_fence
• minecraft:birch_fence
• minecraft:jungle_fence
• minecraft:oak_fence
• minecraft:spruce_fence
• minecraft:dark_oak_fence
• minecraft:nether_brick_fence
• minecraft:iron_bars
• minecraft:glass_pane enforce-type: true max-column-height: 20 gate-search-radius: 7

see the picture at this link https://github.com/IntellectualSites/FastAsyncWorldEdit-1.13/issues/51#issuecomment-488523650

[AeSix]

@Tsoccerguy3 what happens if you replace "minecraft:oak_fence" with "oak_fence"? Is there any changes?

[Tsoccerguy3]

@Tsoccerguy3 what happens if you replace "minecraft:oak_fence" with "oak_fence"? Is there any changes?

it makes no difference , failed to find gate

[Tsoccerguy3]

That's considered an issue with FAWE then. If they're breaking the API contracts of the WorldEdit API, then it's not filling the dependency requirement of WorldEdit.

If it's not going to implement the API, it should stop pretending to be WorldEdit. This is 99% of the reason I preferred it using patching.

So if FAWE updates from WorldEdit Beta 5 dependencies , to the Release candidate 1 this will fix the block names issues , ? this seems to be the issue now

[me4502]

Nothing related to block names has changed in a very long time, it’s not a matter of FAWE not being updated. It’s just broken parts of the API, specifically fuzzy matching.

[Tsoccerguy3]

Nothing related to block names has changed in a very long time, it’s not a matter of FAWE not being updated. It’s just broken parts of the API, specifically fuzzy matching.

So a fuzzy state refers to , example: when a fence post can have a connector in each of the directions and at all 4 sides ?

When this is fixed in FAWE how can I set a fence state in the config file .

See https://github.com/IntellectualSites/FastAsyncWorldEdit-1.13/issues/51#issuecomment-491283055

[bloggy]

I have the same issue. Does anybody know when and if this can be fixed?

[Tsoccerguy3]

I have the same issue. Does anybody know when and if this can be fixed?

The problem is fuzzy blocks and it is partially implemented . It is still being worked on in breaking dev. some blocks like fence change there state depending on the block next to them . there is no time to say when it will be fixed in FAWE . It does work with Worldedit 7 RC2

[dartzdeRS]

dev fix this plz?

[Tsoccerguy3]

Nothing related to block names has changed in a very long time, it’s not a matter of FAWE not being updated. It’s just broken parts of the API, specifically fuzzy matching.

Matt , could you help Jesse by patching the broken parts of fuzzy matching . ? Maybe its time to update the World Edit API from Beta 5 to the RC 2 or is it better to wait for a final ? It may also fix a issue with version 1.12.2 schematics are pasted into 1.13.2 and some fence , stairs , redstone , are not connected together or in the wrong state

Also if you could enhance the Gate material configuration to allow on purpose , the new fence states like the 4 sided fence to be used .

[bloggy]

Do they even read the github issues ? :D

[me4502]

The gate config allows specifying anything.

And I don't have time to fix plugins that break WorldEdit.

[MattBDev]

I'm doing the best I can in my limited time to keep up on the issues. The other Matt (me4502) doesn't have to do anything for this project if he doesn't want to. I am actively reading this thread. My priority was on bringing FAWE up to speed on the text component changes. I'll reevaluate what needs to be done first.

[TheoRetisch1]

Confirmed for the latest version. The gates can be registered, but when the gates are triggered the error "Failed to find a gate" appears! No error in the console.

FAWE: 1.13-113 craftbook: 3.10-SNAPSHOT;4500-4cecc6e

[Tsoccerguy3]

As of today FAWE only recognizes fuzzy blocks default names . when the new names and their states are defined , it will fix this issue and a lot more issues mentioned in other posts

[TheoRetisch1]

@Tsoccerguy3 could you please tell me with which craftbook and FAWE version it works for you? I am now on FAWE 1.13-117 and have reinstalled everything. The problem with the Craftbook Gates still exists.

[Tsoccerguy3]

@Tsoccerguy3 could you please tell me with which craftbook and FAWE version it works for you? I am now on FAWE 1.13-117 and have reinstalled everything. The problem with the Craftbook Gates still exists.

At this time only this configuration works , there has to be a air space between the base material to maintain default state of example minecraft:oak_fence,[false] . or by old naming standard ID 85 which is a oak post not connected to anything. Name matching does not work because the code from Worldedit is missing from FAWE

https://user-images.githubusercontent.com/22108822/57500280-e0a17900-72b0-11e9-953b-51f87d997430.png