Heightmap updates are not send properly

[LaurenceBarnes]

[REQUIRED] FastAsyncWorldEdit Configuration Files

/fawe debugpaste: (from 12:12 MET, after aurora asked me for it) https://athion.net/ISPaster/paste/view/d46e9190bdf04f0c86b273bb87ae13b2

(from about an hour and a half later, with an error after executing //fixlighting) https://athion.net/ISPaster/paste/view/cf8d81496713448da2d44438206a218a

Required Information

• FAWE Version Number (/version FastAsyncWorldEdit): 576
• Spigot/Paper Version Number (/version): 436
• Minecraft Version: 1.16.5

Describe the bug as the title says, there is something wrong with how minecraft deals with FAWE edits which then corrupts the vanilla maps. First of all, neither dynmap nor Maplands, both very similar plugins, have an issue with displaying the world correctly. Everything is perfectly accurate for them, but they have their own render methods that deal with the data differently/better. So in any way, even smaller pasted objects corrupt how the vanilla map looks like in close proximity. Areas that have never been edited at all are completely unaffected. This happens consistently in any region, and from my memory, we had this issue three months ago already, but didn't investigate since we were far away from opening up our server for survival again (where those maps are much appreciated of course). What seems to happen is that anything just over water level has many gray spots and non-existing flat gray areas, some spots are correct, most are not. The higher the terrain goes, the more corrupted it seems, as visible on the attached pictures. I first sent one example into the discord support channel, and was then told by aurora to send the debugpaste and then to try //fixlighting. Using the latter command caused the error at 13:24:43, visible in the second debugpaste. It also made the map even more corrupted, almost the half of it turned completely gray after executing it. I assume there is something that the game cannot deal with, but that the mapping plugins don't care about because of their own, more efficient code.

Screenshots:

Then a more sophisticated test: 1) Corrupted map, the chess board pattern exists, but is below that red sandstone construction:

2) How it actually looks like:

3) Map after doing //fixlighting (kinda fixed, but also not):

4) Error after doing that (the same as when I did //fixlighting before): https://pastebin.com/uxvuV1ek

5) How it looks like after that (lighting is not correct):

6) How it looks like after doing /cleanlight 20 then, map remained unchanged, like in 3) (LightCleaner Plugin):

Notable mention - at least one pattern on that corrupted map I actually recognize. The marked trench existed there previously, before that terrain was terraformed. It is similar for other spots, that it does not completely "forget" how the terrain was before:

Before terraforming:

After:

To Reproduce Steps to reproduce the behavior:

1. Edit a region, even smaller objects (let's say an area from 20x20 blocks to whatever you can paste in at maximum)
2. Use a minecraft map of that edited region (as in item "empty map", the zoom factor doesn't matter)
3. See how it is corrupted (see screenshots)

Plugins being used on the server 1L1D, BKCommonLib, BlockLocker, Core, CoreProtect, CustomCommands, DeadChest, dynmap, Enchantments_plus, Essentials, FastAsyncWorldEdit (WorldEdit), GSit, HolographicDisplays, ImageMaps, ItemJoin, ItemSlotMachine, LibsDisguises, LightCleaner, LuckPerms, Maplands, My_Worlds, MythicMobs, OpenInv, PlaceholderAPI, PlugMan, ProtocolLib, PsudoCommand, QuickShop, TAB, TCCoasters, TCPShield, TimeIsMoney*, Train_Carts, UniqueRewards, Vault, ViaBackwards, ViaVersion, Vivecraft-Spigot-Extensions, WorldEditSelectionVisualizer, WorldGuard

Checklist:

• [X] I included all information required in the sections above
• [X] I made sure there are no duplicates of this report (Use Search)
• [X] I made sure I am using an up-to-date version of FastAsyncWorldEdit for 1.16.5 the two newer versions should not make any difference
• [X] I made sure the bug/error is not caused by any other plugin - pretty sure it is not, since maps outside edited regions render normally

I hope that this long report is helpful. Of course if I can test/provide more information, don't hesitate to tell me, I am eager to help you solve this :D

[LaurenceBarnes]

wow that was a fast title edit, thanks xD

[NovaPixell]

I have this similar issue, are they working for a fix?

[LaurenceBarnes]

I hope so, from what I understood it is fixable, but the devs are working on other things currently :D

[LaurenceBarnes]

Updated/fixed Pastebin link (accidentally set to two weeks max)

[NovaPixell]

I have the same problem too

[NovaPixell]

Some news for a fix?

[LaurenceBarnes]

[LaurenceBarnes]

however, I noticed that the reliability increases when done with small selections, such as 6x6 chunks or roughly less than a 30k blocks selection. This applies for both the effect in #891 and this issue with the map updates. Of course that is not ideal, but could be a workaround if you just did small things.

PS.: It works like that on FAWE-598. I don't know whether some changes improved the heightmap updates, only the devs know.

[NovaPixell]

are developers aware of this serious bug? as far as I'm concerned the problem is very serious

[aurorasmiles]

Yes, we do read those issues

[LaurenceBarnes]

It's sometimes great to know that there is some attention to the issues, especially with those that took a lot effort for the testers as well :D However I agree that this is a serious issue impact-wise, of course not as critical as a crash, but still a malfunction. Crashes have been fixed as far as I am concerned, and I cannot repeat as often enough how good of a job you did with fixing those :D

I wrote in a comment under issue #770 where I asked for a seperate command to update heightmaps that people upvoted, is that enough or should I open another feature request issue for that?

[CatEricka]

It seems that after the modification of #941, command /fixlighting work better. When repairing chunks with damaged height maps due to fawe, no NPE (NullPointerException) has been found so far. Before this, trying to repair a large area will cause a NPE, and because the operation is interrupted will cause a larger area of ​​heightmap error.

But when selecting a large area (for example 7*10 chunks), /fixlighting still does not work well, no chunks are repaired.

[LaurenceBarnes]

yes, I can confirm this. With small area it works (was like that before) but now it does not throw errors anymore. slightly larger areas are a problem and are not being fixed.

[MattBDev]

@LaurenceBarnes Ever since #941 was merged into the plugin, has /fixlighting been working more to fix the maps?

[LaurenceBarnes]

@LaurenceBarnes Ever since #941 was merged into the plugin, has /fixlighting been working more to fix the maps?

@MattBDev as I wrote in the one comment above, it does not throw errors anymore and it works with VERY small selections not larger than four chunks, however large selections still will not be fixed by //fixlighting, so a fix is still required. Since it seems to affect many things as seen in some issues on the tracker, it would help a lot. For debug and general utility I wanted to open an issue to implement a seperate //fixheightmap command, didn't have the chance yet to write that sadly.

[MattBDev]

@LaurenceBarnes Thanks for the update.

[LaurenceBarnes]

@LaurenceBarnes Thanks for the update.

Thanks a lot for checking on it. I wish you really good luck with fixing it, it would be such an improvement and close at least three issues here at once lol

[VL4DST3R]

Can confirm what LauranceBarnes said, doing individual chunks seems to work, while larger selections pretty much never work.

[VL4DST3R]

Is there currently any way (external or otherwise) to fix this across an entire word? going at it chunk-by-chunk with //fixlighting is not really feasible.

[LaurenceBarnes]

The only current solution is to stop your server, replace FAWE with WE, make a platform of ideally solid material (such as stone) above the affected areas, remove it after. This is a bit laggy as you wanna make large platforms, but it fixes the heightmaps completely. Depending on the size of your corrupted area, you need to split it into smaller operations of course, since WE is quite restrictive when it comes to large operations. After that you can replace WE with FAWE again.

[VL4DST3R]

Thank you so much! A real shame too, but i figured something like this would be the only fix. I may have to drop FAWE for the time being while this bug is in effect, as it will only continue to reappear the next time an edit is made somewhere. I wonder if the (paid) AsyncWorldEdit plugin suffers from the same issues as FAWE when it comes to handling map changes?

[LaurenceBarnes]

First of all, no, AWE is not paid, second, it is not really good, which some more experienced people might be able to explain to you. I can just tell you that I had horrible experiences with it and it was so slow even for small edits. WE has issues with observers and rails for example. There is no perfection currently.

EDIT: Okay it is paid, somehow. You just have to build it yourself and get no support. I apologize, that was almost half a year ago.

[VL4DST3R]

This version here.

Offering no help with bugs or issues and forcing you to compile your own binaries while giving jack-shit information about how sounds about as paid (and scummy) as it gets with mc plugins. I'm gald the FAWE project exists.

[VL4DST3R]

What issues does WE have with observers and rails? I was not aware of this.

[LaurenceBarnes]

https://github.com/EngineHub/WorldEdit/issues/1416

From my checks on their changelogs I could not see it being fixed yet, but I might try it as well with their most recent update again.

[VL4DST3R]

Thanks for the heads up.