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?
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
MC-106143![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
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
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