Agree this is something that should have a gamerule associated with it. This would both help adventure maps where we only want to use item frames as clues or indicators as well as allowing a game mechanic where item frames can be made droppable (and the embedded item therefore available) when a user solves a puzzle and activates a command block to toggle the gamerule.
As Robert says, it is now possible to place in invulnerable item frame/painting on a block using the "summon" command in vanilla MC. However it's pretty inpractical from what I can see.
As has been noted before, the whole issue is that item frames and paintings are entities so you need to think of them as if they were mobs that are glued in place rather than part of the world. This also means that the new clone command will not clone item frames and paintings just as it won't clone mobs that happen to be moving through your cloned area at the time you use the clone command.
What you are doing is summoning an ItemFrame entity into the world at the first set of co-ordinates (which can be relative using ~). The data tag in curly braces then tells the item frame entity to "attach itself" to a particular location specified in the TileX, TileY, TileZ co-ordinates (which cannot be relative to the player/command-block where the command is invoked ) facing in the direction specified and making it invulnerable.
The co-ordinates to which you summon the item frame (the first set of co-ordinates) don't need to be the location the item frame will end up - it just needs to be the co-ordinates of an empty block (this kind of makes sense - you're "summoning" an entity into the world after all, so it needs an unoccupied space to be summoned into). If you summon the item frame into co-ordinates which contain a block, then even after the item frame is subsequently "attached", after a few moments it will "pop off", i.e. be dropped as an item.
The TileX,TileY,TileZ co-ordinates are the co-ordinates of the block which you want the item frame to OCCUPY (NOT the co-ordinates of the block to which it is visually "attached"). Think of the item frame as attaching to the "inside" of that "air" block rather than the outside of the adjacent block. However, there must BE an block adjacent to the item frame otherwise once again the frame will drop as an item after a few moments.
The main problem here is really that TileX, TileY and TileZ have to be absolute co-ordinates in the world, so if you need to place a lot of item frames in various places, it is VERY tedious.
What would be really useful is an enhancement to the ~ relative co-ordinate system so that we have variables, @x, @y, @z for example that evaluate at invocation time to the co-ordinates of the command-block or the player issuing the / command. Combined with simple algebraic evaluation (e.g. @x+4) we could do a lot of cool stuff!
Testing again in the latest build, the behaviour of TileX, TileY and TileZ appear to be different????
Still seems to be the case that the item frame has to be summoned to an empty block's location (otherwise the item frame drops after a few seconds), but now TileX, TileY and TileZ seem to need to be the block to which the frame is attached. Go figure!
Hmmm. Another change in 14w07a. If an item frame is set to invulnerable, seems you can no longer rotate the item in the frame, nor can you place an item in an empty invulnerable frame in creative mode. You'd have to create the item in the frame in the /summon command (Item:
{id:<Whatever>}
) and set the rotation also.
This feels like a step backwards in functionality for adventure maps etc.
For me, this issue needed to be configurable by the map maker rather than being one way or the other. Originally there was a suggestion for a gamerule to toggle the behaviour globally, but once the Invulnerable NBT tag became available along with the ability to use /summon, the focus for me changed to the quirks in the way the /summon command had to be used.
Now, as far as I can see in the current snapshot (14w31a), /summon ItemFrame ~ ~1 ~
in the chat box places an invulnerable frame in the block your head is occupying - you just need to specify the appropriate direction and there must be a block in that direction for the itemframe to "stick" to, otherwise it drops as an item. This definitely did not used to be the case. It used to be that the co-ordinates to which the itemframe was summoned (the first set) had to be an "air" block, but not necessarily the place where the itemframe was ultimately going to appear and the TileX, TileY, TileZ then specified the block in which the itemframe should "attach" itself, but these could not be relative co-ordinates, which meant having to work out the co-ordinates of the block and specify it each time...painful.
In fact, after a bit more testing in 14w31a, as far as I can see, the TileX,TileY and TileZ parameters don't seem to be relevant any more (whether they support relative co-ordinates now is, I guess, moot as a result). I can put any numbers I like in there or even leave out those parameters and just do '/summon ItemFrame ~ ~1 ~
{Direction:0,Invulnerable:1}
', and I seem to get an itemframe that works as expected. Furthermore, the co-ordinates to which the itemframe is summoned (the first set) determine where the item frame ends up - this also was not the case before. It looks as if the first set of co-ordinates also determine the TileX, TileY, TileZ NBT parameter when an itemframe is summoned and override what is supplied in the tag. That's what it looks like to me anyway.
The same seems to apply to paintings, though they are a bit more painful as they attach to the specified block rather than "within" the specified block, so you need relative co-ordinates for the block you want to attach to (therefore dependent on the direction you're facing). But again, this seems to work without specifying TileX, TileY and TileZ in the summon command.
So as far as I can see, the operation of the /summon command has silently changed at some point in the last few months and now makes creating invulnerable itemframes (and other similar entities) pretty straightforward.
Can others confirm the above behaviour, just in case I'm hallucinating or going mad?
I have some sympathy with Brad's point about paintings in terms of ease-of-use. Usually paintings are purely decorative whereas item frames may be decorative, part of the mechanics of the map or used to drop an item.
There are situations where you may want paintings to be destroyable, for example how about a map where "clues" are hidden behind paintings (easily done by attaching a painting to a barrier block so when the painting is destroyed, you can see a clue or something through the barrier), but 99% of the time I agree you probably don't want paintings to be destroyable in adventure mode (whereas item frames it's a lot less clear cut). I think the flexibility is the key rather than it being hard-coded one way or the other.
It's now even easier in the latest snapshot with the new /entitydata command. You can do, for example, /entitydata @e[type=ItemFrame]
{Invulnerable:1}
to set all item frames to invulnerable. You can also use this programatically to change an existing item frame's invulnerability (or indeed any other property) via a command block in adventure mode. I'm definitely for closing this bug as resolved now as the complaints about the difficulty of creating invulnerable item frames/pictures etc. is to my mind resolved by the addition of the /entitydata command.
MC-48524
Agree this is something that should have a gamerule associated with it. This would both help adventure maps where we only want to use item frames as clues or indicators as well as allowing a game mechanic where item frames can be made droppable (and the embedded item therefore available) when a user solves a puzzle and activates a command block to toggle the gamerule.
As Robert says, it is now possible to place in invulnerable item frame/painting on a block using the "summon" command in vanilla MC. However it's pretty inpractical from what I can see.
As has been noted before, the whole issue is that item frames and paintings are entities so you need to think of them as if they were mobs that are glued in place rather than part of the world. This also means that the new clone command will not clone item frames and paintings just as it won't clone mobs that happen to be moving through your cloned area at the time you use the clone command.
So you can do:
/summon ItemFrame -259 5 -86
{Direction:1,Invulnerable:1,TileX:-259,TileY:5,TileZ:-86}What you are doing is summoning an ItemFrame entity into the world at the first set of co-ordinates (which can be relative using ~). The data tag in curly braces then tells the item frame entity to "attach itself" to a particular location specified in the TileX, TileY, TileZ co-ordinates (which cannot be relative to the player/command-block where the command is invoked
) facing in the direction specified and making it invulnerable.
The co-ordinates to which you summon the item frame (the first set of co-ordinates) don't need to be the location the item frame will end up - it just needs to be the co-ordinates of an empty block (this kind of makes sense - you're "summoning" an entity into the world after all, so it needs an unoccupied space to be summoned into). If you summon the item frame into co-ordinates which contain a block, then even after the item frame is subsequently "attached", after a few moments it will "pop off", i.e. be dropped as an item.
The TileX,TileY,TileZ co-ordinates are the co-ordinates of the block which you want the item frame to OCCUPY (NOT the co-ordinates of the block to which it is visually "attached"). Think of the item frame as attaching to the "inside" of that "air" block rather than the outside of the adjacent block. However, there must BE an block adjacent to the item frame otherwise once again the frame will drop as an item after a few moments.
The main problem here is really that TileX, TileY and TileZ have to be absolute co-ordinates in the world, so if you need to place a lot of item frames in various places, it is VERY tedious.
What would be really useful is an enhancement to the ~ relative co-ordinate system so that we have variables, @x, @y, @z for example that evaluate at invocation time to the co-ordinates of the command-block or the player issuing the / command. Combined with simple algebraic evaluation (e.g. @x+4) we could do a lot of cool stuff!
Testing again in the latest build, the behaviour of TileX, TileY and TileZ appear to be different????
Still seems to be the case that the item frame has to be summoned to an empty block's location (otherwise the item frame drops after a few seconds), but now TileX, TileY and TileZ seem to need to be the block to which the frame is attached. Go figure!
Hmmm. Another change in 14w07a. If an item frame is set to invulnerable, seems you can no longer rotate the item in the frame, nor can you place an item in an empty invulnerable frame in creative mode. You'd have to create the item in the frame in the /summon command (Item:
{id:<Whatever>}) and set the rotation also.
This feels like a step backwards in functionality for adventure maps etc.
For me, this issue needed to be configurable by the map maker rather than being one way or the other. Originally there was a suggestion for a gamerule to toggle the behaviour globally, but once the Invulnerable NBT tag became available along with the ability to use /summon, the focus for me changed to the quirks in the way the /summon command had to be used.
Now, as far as I can see in the current snapshot (14w31a), /summon ItemFrame ~ ~1 ~
{TileX:~,TileY:~1,TileZ:~,Direction:0,Invulnerable:1}in the chat box places an invulnerable frame in the block your head is occupying - you just need to specify the appropriate direction and there must be a block in that direction for the itemframe to "stick" to, otherwise it drops as an item. This definitely did not used to be the case. It used to be that the co-ordinates to which the itemframe was summoned (the first set) had to be an "air" block, but not necessarily the place where the itemframe was ultimately going to appear and the TileX, TileY, TileZ then specified the block in which the itemframe should "attach" itself, but these could not be relative co-ordinates, which meant having to work out the co-ordinates of the block and specify it each time...painful.
In fact, after a bit more testing in 14w31a, as far as I can see, the TileX,TileY and TileZ parameters don't seem to be relevant any more (whether they support relative co-ordinates now is, I guess, moot as a result). I can put any numbers I like in there or even leave out those parameters and just do '/summon ItemFrame ~ ~1 ~
{Direction:0,Invulnerable:1}', and I seem to get an itemframe that works as expected. Furthermore, the co-ordinates to which the itemframe is summoned (the first set) determine where the item frame ends up - this also was not the case before. It looks as if the first set of co-ordinates also determine the TileX, TileY, TileZ NBT parameter when an itemframe is summoned and override what is supplied in the tag. That's what it looks like to me anyway.
The same seems to apply to paintings, though they are a bit more painful as they attach to the specified block rather than "within" the specified block, so you need relative co-ordinates for the block you want to attach to (therefore dependent on the direction you're facing). But again, this seems to work without specifying TileX, TileY and TileZ in the summon command.
So as far as I can see, the operation of the /summon command has silently changed at some point in the last few months and now makes creating invulnerable itemframes (and other similar entities) pretty straightforward.
Can others confirm the above behaviour, just in case I'm hallucinating or going mad?
Invulnerability applies in adventure and survival. It used to also apply in creative which was a nightmare for map makers!
I have some sympathy with Brad's point about paintings in terms of ease-of-use. Usually paintings are purely decorative whereas item frames may be decorative, part of the mechanics of the map or used to drop an item.
There are situations where you may want paintings to be destroyable, for example how about a map where "clues" are hidden behind paintings (easily done by attaching a painting to a barrier block so when the painting is destroyed, you can see a clue or something through the barrier), but 99% of the time I agree you probably don't want paintings to be destroyable in adventure mode (whereas item frames it's a lot less clear cut). I think the flexibility is the key rather than it being hard-coded one way or the other.
It's now even easier in the latest snapshot with the new /entitydata command. You can do, for example, /entitydata @e[type=ItemFrame]
{Invulnerable:1}to set all item frames to invulnerable. You can also use this programatically to change an existing item frame's invulnerability (or indeed any other property) via a command block in adventure mode. I'm definitely for closing this bug as resolved now as the complaints about the difficulty of creating invulnerable item frames/pictures etc. is to my mind resolved by the addition of the /entitydata command.
Confirm this happens with all types of stair blocks in new and saved worlds.