fix: correct lazycopy dimensions and world usage

[dordsor21]

• fixes //lazycopy dimensiona too large #3472
• fixes LAZYCOPY will not copy clipboard source world #3496

[SirYwell]

Why not just use Long.MAX_VALUE? The specification of the method in the superclass should also cover which values are valid.

[dordsor21]

I wanted to convey actually unlimited rather than functionally unlimited. It should go into the javadoc though yeah

[SirYwell]

An instance method is somehow the wrong approach, mainly because it requires an escaping this in the constructor, and it also doesn't have any different use really. Maybe SimpleClipboard is generally a rather problematic abstraction?

[dordsor21]

It is, but altering the hierarchy is rather a v3 change and it would be nice to have this working a little sooner than that... We could always deprecate for removal upon implementation and put the change into V3 immediately.

Alternatively I suppose we could just reimplement in a different class entirely? Certainly the clipboard hierarchy could do with some cleanup at some point regardless

[Copilot]

Pull request overview

This PR addresses two //lazycopy regressions by allowing WorldCopyClipboard to represent extremely large selections without hitting the SimpleClipboard size guard, and by reducing the chance that the clipboard’s backing extent is reused/reinitialized in a way that changes the source world.

Changes:

• Add configurable “max volume” constructors to SimpleClipboard/ReadOnlyClipboard and use an “infinite” limit for WorldCopyClipboard.
• Update WorldCopyClipboard to construct its base clipboard with an unlimited max size and uncache the queue when a SingleThreadQueueExtent is detected.
• Refactor deprecated WorldCopyClipboard constructors to delegate through the new constructor path.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.

File	Description
worldedit-core/src/main/java/com/fastasyncworldedit/core/extent/clipboard/WorldCopyClipboard.java	Uses unlimited clipboard sizing for lazy copy and uncaches queue when a reusable single-thread queue extent is present.
worldedit-core/src/main/java/com/fastasyncworldedit/core/extent/clipboard/SimpleClipboard.java	Introduces max-size-aware constructors and changes the size guard to use that max.
worldedit-core/src/main/java/com/fastasyncworldedit/core/extent/clipboard/ReadOnlyClipboard.java	Exposes max-size-aware construction for read-only clipboards and defaults to the prior size limit behavior.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

worldedit-core/src/main/java/com/fastasyncworldedit/core/extent/clipboard/SimpleClipboard.java:63

• maxSize == -1 currently allows volumes larger than Integer.MAX_VALUE, but area and volume are still stored as int (this.area = getWidth() * getLength(); and this.volume = (int) longVolume;). For very large regions this will overflow and can turn negative; additionally the long multiplication can overflow for large-but-valid Minecraft coordinate ranges (e.g. ~60M x 4096 x ~60M). Consider using Math.multiplyExact to detect overflow and Ints.saturatedCast (or equivalent) so getArea()/getVolume() never return nonsensical negative values when large lazy clipboards are permitted.

        if (maxSize != -1 && longVolume > maxSize) {
            throw new IllegalArgumentException("Dimensions are too large for this clipboard format.");
        }
        this.area = getWidth() * getLength();
        this.volume = (int) longVolume;