Add rotateZ for all rotations

[Argmaster]

This pull request adds functions for rotating block data around Z axis.

[IntegratedQuantum]

I wonder if it might be best to just restrict the rotations to only the z axis, then we could focus on optimizing these cases (to just one function call, instead of calling rotateZ 3 times in the worst case), without having to worry about any other rotation axis.

@ikabod-kee maybe you have an opinion about this? Are there many cases where you may really want to rotate a structure in any other direction? If so, would be fine about manually rotation things in that case?

[Argmaster]

I don't see how having all 3 axis available stops you from having bigger rotation tables, since every rotation is applied separately and simply there is no way to create rotation table for combination of rotations in different axis due to how API is designed.

I don't agree with removing rotations around X and Y, these have valid use cases of creating eg. XYZ junctions and in general anything that is symmetrical around X or Y axis. If you don't have X and Z rotations you can't use commands to create builds that are symmetrical around X or Y since even if you build it symmetrical along Z axis there is no tool to rotate it to horizontal position. This applies for example to tunnels.

[ikabod-kee]

@ikabod-kee maybe you have an opinion about this? Are there many cases where you may really want to rotate a structure in any other direction? If so, would be fine about manually rotation things in that case?

Unless you can defy gravity, there isn't much reason to turn a structure on its side.

[ikabod-kee]

Though it's still probably good to have that option, just in case.

[Argmaster]

What about spikes, stalagmites and stalactites, reusing branches as flipped top-down, having leaves spawn child nodes point up and down? We will manually create exactly same model twice because we can't rotate it around X and Y?

And since allegedly we don't use it, why worry about its performance?

[IntegratedQuantum]

I don't see how having all 3 axis available stops you from having bigger rotation tables, since every rotation is applied separately and simply there is no way to create rotation table for combination of rotations in different axis due to how API is designed.

I mean that in the sense of focusing our efforts on making one thing faster, rather than having to work on 3 different things (6 including flips).

What about spikes, stalagmites and stalactites, reusing branches as flipped top-down, having leaves spawn child nodes point up and down? We will manually create exactly same model twice because we can't rotate it around X and Y?

Well, that is an argument for implementing flipping, not for implementing X or Y rotations (which require significantly more complicated code). Like Ikabod said, there rarely is a reason to turn something on its side.

[Argmaster]

Well then you can keep implementation of XY rotations suboptimal but present instead of removing it at all.

[IntegratedQuantum]

Well then you can keep implementation of XY rotations suboptimal but present instead of removing it at all.

Well, it's not just about this code here, but also about the future rotation code. And you can't deny that it would make the structure rotation simpler too to restrict it on flipping and z rotations.
And of course it's just simply more code, and any code has to be maintained.

[Argmaster]

So for ship wrecks you will also have separate model laying on side? No complicated fallen tree models either, unless you build separate set of assets for them. I am fairly certain that this will come back as a request. Things that were build vertical will stay vertical then.

[IntegratedQuantum]

I'm sure that both shipwrecks and fallen trees are better to built them sideways to begin with.
For shipwrecks especially, since you'd probably want to build a mast out of fences, which is impossible when it lies on the side.
Generally I think there are also just too many rotation modes that cannot be equivalently displayed sidewards (e.g. fences, torches, mushrooms).

Finally if we limit outselves to just z rotations it could make your idea

Then rotation of actual blueprint could be done by changing iteration order.

more viable, since then you could achieve cache locality by iterating the columns (and for flips we could precompute just one separate model)

[Argmaster]

Seems to be working more or less

[IntegratedQuantum]

looks good to me.