NBT data messing up due to an older vertion of worldedit

This is a well known bug with coreprotect, not worldedit

It’s being worked on and should be fixed within a few weeks.

@oflag#11211 Can you tell me how to replicate this issue? Pasting, rolling back etc.

When I have more information, I will raise a ticket on Jira.

@Fleek#11219 Pasting doesn't seem to be the problem, however for rolling back it's been an issue for a while. If a block with NBT data such as stairs, fences, walls etc. are rolled back via /co rb, instead of being reset to the orientation they were last placed in.. they get reset to the natural orientation of non-NBT blocks, as if you were using /fill without an NBT tag (north I believe)

@Shdwo#11220 In that case, we already have raised a ticket for it (FS-76)

@Fleek#11221 A worthy note to add as well is that bending appears to do the same thing.

@Shdwo#11222 What do you mean?

@Fleek#11223 For example, if someone used any of the bending elements that are able to manipulate blocks (primarily earth bending) via ProjectKorra. Once the bending gets undone by Korra's rollback (or by /b reload) the blocks that are put back into place face the same issue as CoreProtect (They get reset without NBT data or orientation)

@Shdwo#11224 Sounds like a plugin interference - most likely VulnerabilityPatcher

CoreProtect seems to hold NBT data whenever a build I've made has signs and stairs, but with schematics it doesn't seem to work well.

I don't know why it works for me but hope this helps Fleek

FS-154 has already been raised to make sure AWE, WorldEdit and Blockshub is up to date. I think there is a permission node that would usually be required by WorldEdit in order to allow you to paste with NBT which OP's are not granted which is intentional.