Server Implementation

Paper

Server Version

1.18.2

Describe the bug

When setting a vertical column of blocks to be stone, going from y=-62 to y=62, with the small-edit=true config option, the console is spammed with hundreds of lines of errors. These errors are all identical to the attached paste.

To Reproduce

1. Go to negative y coordinate
2. Select any arbitrary positions
3. //set stone
4. Operation completes successfully, however for each block set, it generates the above error message

Expected behaviour

No errors in console.

Screenshots / Videos

No response

Error log (if applicable)

https://paste.gg/p/anonymous/77a90ac2dbd14b809b1ca948f6415b73

Fawe Debugpaste

https://athion.net/ISPaster/paste/view/75b66fa790de404d9f35020e90cb93f3

Fawe Version

FastAsyncWorldEdit version 2.4.7-SNAPSHOT-281;10b852d

Checklist

• I have included a Fawe debugpaste.
• I am using the newest build from https://ci.athion.net/job/FastAsyncWorldEdit/ and the issue still persists.

Anything else?

Because the log specifically mentions "small-edit=true" I am assuming this error is purely caused by that option being enabled. I searched existing open/ closed issues and couldn't find anything talking about this. If I must reattempt the bug without any other plugins enabled then I can do so.

Due to the way small-edit=true stores the block data, only numbers from 0-255 are supported (as there isn't enough space byte-wise to store higher or negative coordinates)
I wouldn't say this is a bug, as the error message was introduced when implementing extended world heights (1d9b1a3) - But I'd wait for another opinion on that

It definitely shouldn't throw the same exception over and over again. Instead, the user should be notified that their action couldn't be executed because of that configuration.

I looked at the commit mentioned by @PierreSchwang, 1d9b1a3 and found that this error message was deliberately programmed, https://github.com/IntellectualSites/FastAsyncWorldEdit/blob/main/worldedit-core/src/main/java/com/fastasyncworldedit/core/history/changeset/FaweStreamChangeSet.java#L148

Without looking further into the implementation, my initial suggestion, assuming this simply cannot be supported, is the calling code should immediately stop attempting to call this method when this error occurs. Additionally, the error message should be changed to specify that if small-edits is enabled, then history will simply not function outside these edit ranges, and suggest that the option be disabled if that is required.

Otherwise, update the method to support this new range. I'm surprised there's not even a //TODO comment in the code here, at the very least I think there should be documentation around the option that says "Does not support 1.17+"

Edit: About the way the data is stored not supporting y values outside 0-255, the documentation says that "Assumes all edits are smaller than 4096x256x4096," assuming that this is just because that's the biggest number that fits into 4-bytes, surely it can be modified to include the new world height at the expense of the x/z dimensions? Giving 9 bits to the height value leaves 23 remaining, 22 can go to storing 2048x2048 area, and the last bit can be a version flag (if that's where it would be stored). Granted it would waste like 128 values on the y-level, but this is just a starting point. Perhaps with a better algorithm that wasted space can be recovered and allow a slight larger x/z/y range of 3348x383, which is theoretically the maximum that could be achieved. I'm not a bit pro though... (most realistically, this could be modified to give the proper full 12 bits to the height, and 10 bits each to the x/z, providing a "minecraft original" 1024x4096x1024 size, which from the little reading I did 4096 is the true minecraft supported height range.)