WORLDEDIT-2913 - Reported by Alex.Ford

Often times I'll select a cuboid area, fill it with blocks of some type, then chisel away until I have my masterpiece the way I want it. Then after that I often //cut, //rotate, and //paste somewhere else now that it's finished. It is often cumbersome to then select the new area where I pasted so as to protect the region.

My new masterpiece is almost never a cuboid anymore so I usually have to build a frame of sorts so that I can select a new cuboid around my masterpiece. If //paste had a -s option that would select the new area that would be so helpful. I'm very glad //move has a -s option (though I wish -s was the default for //move).

I have two ideas to implement this:

1. I imagine this was not done already because of the issue that cut and paste are two actions and the current selection could be changed between the usage of both commands. My first idea is that you save the selection area to the clipboard as well as the blocks when the user cuts or copies. If the user does //rotate at all after copying then the saved selection should be manipulated in the same way to match the blocks. This saved selection would be happening behind the scenes and should not be confused with the user's current active selection.

When the user executes "//paste -s" it should paste the blocks as normal but it should also paste the saved selection here and make it the user's active selection; we know this saved selection will fit the pasted blocks because it was the same selection when they cut/copied them. So if I //cut and then make a bunch of selections before pasting it wouldn't affect "//paste -s" because that selection will still be the one from when I //cut and it will now override my current active selection.

2. My second idea solves this problem and another problem at the same time. I propose 2 new commands called //cutpaste and //copypaste. Since first using worldedit I've sort of felt like //rotate was superfluous. I mean, the //paste command already does work relative to your position, why can't it also paste relative to the direction I'm looking? //stack, //expand, and //move already do work based on the direction I'm looking so why not //paste?

//cutpaste and //copypaste would cut/copy the current selection and immediately paste it where you are standing. It would be pasted relative to your position and the direction you're looking, which would eliminate the need for //rotate (it would be even more awesome if I could look up or down to rotate on the X axis instead of just the Y axis). Supplying "-s" to these commands would do the same thing as in my first suggestion and move the selection. This argument being easier to implement because there is no need to save the selection to the clipboard. //cutpaste and //copypaste would eliminate all the clipboard work because they would be single actions instead of two (three if you count //rotate).

Hopefully you can see where I'm going with this idea. You guys may even have a better option to implement similar behavior. I really just want to eliminate the work of moving my selection after a paste. Eliminating the need for //rotate and granting the ability to rotate along the x-axis would be bonuses that would be great :)

Comment by wizjany

Eh, i think cutpaste and copypaste are just redundant. If you're too lazy you can get something like commandhelper and make simpler macros.
Selection thing makes sense though. although it will have a few bumps regarding non-cuboid clipboards and non-worldedit schematics, it could still work fine.

Comment by Alex.Ford

Cool. What about rotating on x-axis? Is that something you guys have considered? Even without the new commands or x-axis rotation it would still be cool if we could eliminate //rotate by making it paste relative to position AND look direction.

Comment by wizjany

{{//deform}} can already rotate selection along axes that blocks themselves can't be rotated about. although it can't be used on clipboards yet.

Comment by Alex.Ford

Interesting, I was only vaguely aware of //deform. I will check into that.