Command Block commands do not rotate with structure block rotation

This should be fixable, keeping it open.

What about coordinate in NBTtags？in selectors？
do they need to be rotated？

Fixing this might break a lot of structure/command creations. I think that this should be marked as "Won't Fix", because technically, it can be fixed, but it shouldn't be fixed because it would make things harder for mapmakers and command block modders.

For example: let's say you have a 3x3x3 structure with a command block in the center. This command block needs to summon an entity at the lower northwest corner of the structure, regardless of the structure's rotation. If this issue were fixed, this would be very hard to do, as it would require the command block to summon another command block on top of the structure, then have that command block summon the entity at the lower northwest corner of the build, then have an external command block execute a command via the entity to delete the command block on top of the structure. Fixing this issue would be like fixing all the piston bugs, which would break all the slime block engines, and the bud detectors, and the Jeb doors, and many other creations, including redstone computers that use bud switches to store memory.

That's not really related here, if you rotate a structure you expect it to rotate the according commands too.

About the pistons, that's a completely different subject, and it's been proben that you can make everything without quazi conectivity too, buds were never intended either, and a propper block (observer) already exists in pe to replace their behaviour.

With fixing this you open more possibilities then you block, as, what you said, mojang can leave the nested command blocks alone, making everything that is possible now, still possible and add more possibilities.

Yes, the recursion should only be within the Structure Blocks included command blocks NBT tags.

First, I consider a structure block to be a component based design.
Rotation is block dependent and yes, it should handle nested blocks and entities within the structure that meet a recognizable pattern. If I specified northwest in relative "~" coordinates, the code would work correctly. If I specified absolute coordinates, then I designed the command for an absolute location, so the structure should not be placed in a rotation other than zero or the user intends that the absolute location be rotated, because the world orientation of where a user intends to place the structure is rotated.

Further this leaves command_blocks as working different than other 1.11 blocks with NBT tags, e.g. a torch facing north changes to south (facing=south) when the structure is rotated 180 degrees. All other NBT tags change.

You do fix more problems. Assume I have a citygate structure and I have a command_block that opens the gates. Assume I have a front gate and a back gate (rotated 180 degrees). Should the placed back gate open the front gate, when the command_block gets triggered? Probably not. Should I be unable to reuse the rotated citygate because I have a rotated command block? No.

>> Off topic: Sebastian raises a design possibility alternative as a :

1)structure_block being an entity selectable by tags (e.g. @sb[name=citygate,x,y,z... etc]), and that one can then retrieve rotation, and relative coordinates of the 0,0,0 of the structure.

2)Assuming execute, setblock and fill can be rotation setting (e.g execute @sb ~ ~ ~ %45), where %r (%45) is a rotation then my issue is moot. I considered a mod of a executerotate command at one time.

Then commands can be written to be rotation aware of the structure_block inside the command_block. Then command_block NBTTags are an exception to rotation as a workaround would exist. I digress. <<

Would a partial RotateNBTCompoundTag java class (forge) for detecting and handling pre and post 1.11 rotation help?

Thanks

It could/would help, yes.

Will do in 2-3 weeks.

I've run across an issue, both data values and NBT can be specified for setblock in 1.11.x (16w32b). 1) Which has priority in specifying the blockstate, or are data values going away? 2) Which has/or should have priority if they clash?

Still working it.

e.g.
/setblock ~4 ~4 ~4 minecraft:torch 1 facing=west

both data values and NBT can be specified for setblock in 1.11.x

They already can in 1.10, I think you mean data values and block states.
Data values are being stepped away from, use block states instead.

Which has/or should have priority if they clash?
e.g.
/setblock ~4 ~4 ~4 minecraft:torch 1 facing=west

In this example facing=west does nothing, as the syntax is

/setblock <x> <y> <z> <block> [data values/block states] [replace method] [{NBT}]