/summon and /setblock cannot specify chests, furnaces, dispensers, rails and droppers orientation
Using the /summon or /setblock command to spawn a dropper or a dispenser works but data tags cannot be used to specify the orientation.
To replicate:
Create a command block containing any of the following commands:
setblock ~2 ~ ~ minecraft:dropper 1 replace
summon FallingSand ~2 ~ ~ {Time:1,TileID:158,Data:1}
Both will spawn a dropper facing in the default direction of South, regardless of the value of Data (if placed against a wall the dropper will adjust to face away from the wall). Applying the data for repeaters, hoppers and comparators work fine.
Environment
Windows 7 Home Premium
Java Version: 7.0.150.3
Linked Issues
is duplicated by10
Created Issue:
/summon and /setblock cannot specify dispenser/dropper orientation
Using the /summon or /setblock command to spawn a dropper or a dispenser works but data tags cannot be used to specify the orientation.
To replicate:
Create a command block containing any of the following commands:setblock ~1 ~ ~ minecraft:dropper 1 replace
summon FallingSand ~1 ~ ~
{Time:1,TileID:158,Data:1}Both will spawn a dropper facing in the default direction of East, regardless of the value of Data. Applying the data for repeaters, hoppers and comparators work fine.
Environment
Windows 7 Home Premium
Java Version: 7.0.150.3
Using the /summon or /setblock command to spawn a dropper or a dispenser works but data tags cannot be used to specify the orientation.
To replicate:
Create a command block containing any of the following commands:setblock ~1 ~ ~ minecraft:dropper 1 replace
summon FallingSand ~1 ~ ~
{Time:1,TileID:158,Data:1}Both will spawn a dropper facing in the default direction of East, regardless of the value of Data. Applying the data for repeaters, hoppers and comparators work fine.
Using the /summon or /setblock command to spawn a dropper or a dispenser works but data tags cannot be used to specify the orientation.
To replicate:
Create a command block containing any of the following commands:setblock ~1 ~ ~ minecraft:dropper 1 replacesummon FallingSand ~1 ~ ~ {Time:1,TileID:158,Data:1}Both will spawn a dropper facing in the default direction of East, regardless of the value of Data. Applying the data for repeaters, hoppers and comparators work fine.
/summon and /setblock cannot specify dispenser/dropper orientation/summon and /setblock cannot specify chests, furnaces, dispensers, and droppers orientation
is duplicated by
relates to
Using the /summon or /setblock command to spawn a dropper or a dispenser works but data tags cannot be used to specify the orientation.
To replicate:
Create a command block containing any of the following commands:setblock ~1~ ~ minecraft:dropper 1 replacesummon FallingSand ~1~ ~ {Time:1,TileID:158,Data:1}Both will spawn a dropper facing in the default direction of
East, regardless of the value of Data. Applying the data for repeaters, hoppers and comparators work fine.Using the /summon or /setblock command to spawn a dropper or a dispenser works but data tags cannot be used to specify the orientation.
To replicate:
Create a command block containing any of the following commands:setblock ~2 ~ ~ minecraft:dropper 1 replacesummon FallingSand ~2 ~ ~ {Time:1,TileID:158,Data:1}Both will spawn a dropper facing in the default direction of South, regardless of the value of Data (if placed against a wall the dropper will adjust to face away from the wall). Applying the data for repeaters, hoppers and comparators work fine.
is duplicated by
is duplicated by
is duplicated by
/summon and /setblock cannot specify chests, furnaces, dispensers, rails and droppers orientation
is duplicated by
is duplicated by
is duplicated by
is duplicated by
relates to
is duplicated by
is duplicated by
is duplicated by
relates to
relates to
relates to
This ticket has been marked as a duplicate of MC-31365, in favor of the more general or better information provided.
I want to have the >possibility< to choose if players are able to break it. Should be disabled as default but you should be able to enable it with the CanDestroy command.
I would want this because I am a redstone and cmd block contraption inventor. This would open so many possibilities, like for example custom ores or lucky blocks without a plugin. You just make random cmd blocks spawn in the world and since players can't change the code inside them anyway, you could make a compressed command (activator rail, minecartCommandBlocks) to do random stuff and destroy the block with setblock air afterwards. It would be nice if players could pick up these lucky blocks again (of course also in the first place) if someone places them infront of their house, so they do not have to trust in their luck and activate it (by putting a button to the side and pressing it) to get rid of it (because they are lucky blocks, they could also spawn 10 creepers).
It is just depressing that you are limited every now and then (MC-53347 , MC-52819 , MC-52958 , MC-31365 , MC-9661 , MC-53928 , MC-54716) in this beatiful sandbox game and it seems mods have too much to do to look into the problems longer than 10 seconds (or not even that) and just go for the easy option "works as intended".
I am a commited player and reported a lot of bugs (like the ones above) to help mojang make a better game and none was solved or some not even viewed.
Just my opinion.
Greetings, Escore.
Dupe of MC-31365
Searge stated that it was fixed, but not for the rails due to limitations.
Cannot reproduce in 1.8.2-pre6, resolving to MC-31365.
Confirmed
I can confirm this as well and would really like this to be fixed. Very frustrating.
Confirmed for 13w41a.
Bug still persists in 13w43a
Confirmed for 1.7.
Confirmed in 1.7.1.
Still present in 1.7.2
Confirmed for snapshots 13w47a/b/c.
Duplicate of https://mojang.atlassian.net/browse/MC-12437
Hey took nearly 20k tickets for it to get run into and reported again. I feel proud about that! This was happening back with redstone-activated spawners, pretty crazy that it affects /summon and /setblock too. Glad it's finally getting some more attention. I really hate this bug
I would say leave this open until it's possible to transfer the 11 votes plus Confirmation status over. This ticket's significantly more active/progressed.
hey guys, vote for this issue and it will get more attention from mojang!
Confirmed for 1.7.4.
yes, also confirmed 1.7.4
Confirmed for 14w02c
Confirmed for 14w02c
Confirmed for 14w04b
Confirmed for 14w04a
Confirmed for 14w05a
Confirmed for 14w05b
As per
MC-42375, this also appears to affect rails.Confirmed for 14w06a
Confirmed for 14w06b as well.
Confirmed for 14w07a.
Confirmed for 14w08a.
Confirmed for Minecraft 1.7.5.
The problem shows still in 14w10c.
Used command:
setblock 11 45 87 chest 2 replace {Items:[{Slot:0b,id:torch}]}And its' facing is 3 instead of 2. (It's 3 everytime).
It's still in the 14w11b snapshot as well. It makes it impossible to place single standing dispensers in the correct orientation.
I'd recommend using /clone as a temporary measure til this gets fixed. It seems to use the right direction.
That would probably work for now. Thank you for the tip No Way.
Confirmed 14w11b
Still present in 14w17a.
Clone does not respect orientation with rails. There seems to be 2 separate issues here, one where the setblock command doesn't respect orientation of some blocks, and one where rail's default behavior is overriding the behavior of the setblock and clone commands.
Confirmed for 14w18b.
confirmed for 14w19a
Still present in 14w26b.
Fixed for all but the rails.