Manipulating region spawns duplicate items/blocks

[Bloodlex]

WorldEdit Version

7.2.7

Platform Version

Purpur 1.17.1-R0.1-SNAPSHOT

Confirmations

• [X] I am using the most recent Minecraft release.
• [X] I am using a version of WorldEdit compatible with my Minecraft version.
• [X] I am using the latest or recommended version of my platform software.
• [X] I am NOT using a hybrid server, e.g. a server that combines Bukkit and Forge. Examples include Arclight, Mohist, and Cardboard.
• [X] I am NOT using a fork of WorldEdit, such as FastAsyncWorldEdit (FAWE) or AsyncWorldEdit (AWE)

Bug Description

When copying and pasting selection or moving and doing other region manipulations, some duplicate blocks are dropped like lanterns, doors, torches, signs and others.

Expected Behavior

Nothing should be dropped.

Reproduction Steps

1. Select a region with lanterns, torches, signs.
2. Copy this region and paste somewhere, move or do anything that moves a region.
3. Duplicate items are dropped like lanterns, signs and so on.

Anything Else?

No response

[me4502]

Test without Purpur, WorldEdit does not do this

[wizjany]

can't repro (on paper).

[Bloodlex]

@wizjany Does -e flag change anything on that?

[wizjany]

Not sure why it would, torches/lanterns/etc aren't entities.

[octylFractal]

I tested on latest Paper for fun, and indeed the signs do not drop with -e. If you can reproduce on Paper, please show the exact region you're using, perhaps there's an edge-case that we aren't able to see.

[octylFractal]

Okay, this issue had murky reproduction steps, but I think I found the issue. //move or perhaps //cut, but not a copy, will sometimes cause item drops where blocks were removed. This can be avoided by using //perf neighbors off, but realistically should be handled better. Likely also fixed in 7.3 due to //reorder fast now being the default, which also delays these updates until after the edit is fully complete. Perhaps we should consider changing it in 7.2.x, if possible.

[Bloodlex]

Okay, this issue had murky reproduction steps, but I think I found the issue. //move or perhaps //cut, but not a copy, will sometimes cause item drops where blocks were removed. This can be avoided by using //perf neighbors off, but realistically should be handled better. Likely also fixed in 7.3 due to //reorder fast now being the default, which also delays these updates until after the edit is fully complete. Perhaps we should consider changing it in 7.2.x, if possible.

Yes, sorry I haven't described it better. I'd really like to see it fixed, because this can happen sometimes to drop of many, really many items being dropped on the ground with large cuts and pastes. I'm not sure which other operations are affected, I thought it may be also //stack and similar.

Thanks very much.

[Bloodlex]

Okay, this issue had murky reproduction steps, but I think I found the issue. //move or perhaps //cut, but not a copy, will sometimes cause item drops where blocks were removed. This can be avoided by using //perf neighbors off, but realistically should be handled better. Likely also fixed in 7.3 due to //reorder fast now being the default, which also delays these updates until after the edit is fully complete. Perhaps we should consider changing it in 7.2.x, if possible.

When using //perf neighbors off, for instance lanterns are not pasted after cutting no matter if -e is used or not 🙁 .

[octylFractal]

I cannot reproduce that. Are you testing on Paper?

[Bloodlex]

I cannot reproduce that. Are you testing on Paper?

Right now I've tested that on Purpur. What actually this option //perf neighbors off should do?

[octylFractal]

It simply stops firing the neighbors updates when setting blocks. It shouldn't affect what WorldEdit copies or pastes, that sounds like a problem with Purpur.