Entities (paintings,item frames, minecarts) are breakable in adventure mode
I'm currently building a custom map and tried whether I was able to break item frames or not. After switching to adventure mode and hitting the frame, the frame and the item dropped. This works for paintings as well, making players able to cheat.
I know that this is not really a bug but it is really annoying.
There are also a few things like rotating an item frame or opening a dispenser that shouldn't be possible in adventure mode, however, making the players unable to destroy the item frames is the most important thing in my opinion.
Environment
Operating system: Windows 7, 64-bit
Java 7 Update 9 (latest)
LWJGL 2.4.8 (latest)
Linked Issues
is duplicated by16
MC-13195Mining Fatigue does not affect Paintings and Item Frames in survival/adventureDuplicateMC-32630Item Frames Breakable in AdventureDuplicateMC-44396Adventure ModeDuplicateMC-46388[14w04b] Item frames and items contained in them are still breakable in Adventure ModeDuplicateMC-46611Item Frames still destroyable in Adventure ModeDuplicateMC-47558Painting/Item frames can be broken in adventure modeDuplicateMC-48066You can destroy Item Frames in adventure mode.DuplicateMC-48860Paintings and itemframes can be broken in adventure modeDuplicateMC-49410In adventure mode you can still punch out item frames and wooden buttonsDuplicateMC-60468You can break frames in gamemode adventureDuplicateMC-73196Players in adventure mode can take items out of item framesDuplicateMC-198857Paintings can be broken in Adventure modeDuplicateMC-210918Paintings can be broken in adventure modeDuplicateMC-2760Adventure Mode Player can Break MinecartsDuplicateMC-2978Minecarts in adventure mode.DuplicateMC-4508Paintings Destroyed + AdventureDuplicate
MCPE-22181
Created Issue:
Entities like paintings or item frames are breakable in adventure mode
I'm currently building a custom map and tried whether I was able to break item frames or not. After switching to adventure mode and hitting the frame, the frame and the item dropped. This works for paintings as well, making players able to cheat.
I know that this is not really a bug but it is really annoying.
There are also a few things like rotating an item frame or opening a dispenser that shouldn't be possible in adventure mode, however, making the players unable to destroy the item frames is the most important thing in my opinion.Environment
Operating system: Windows 7, 64-bit
Java 7 Update 9 (latest)
LWJGL 2.4.8 (latest)
- Unresolved
- Open
- Public
- Unconfirmed
- adventure_mode annoying break descriptions drop entity gamemode gameplay item
- 1.4.2
Entitieslikepaintingsoritem frames are breakable in adventure modeEntities (paintings,item frames, minecarts) are breakable in adventure mode
is duplicated by
is duplicated by
relates to
is duplicated by
is duplicated by
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
is duplicated by
relates to
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
is duplicated by
is duplicated by
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
[Mojang] Searge (Michael Stoyke)is duplicated by
![[Mojang] Mega_Spud (Jay Wells)](../../../data/avatars/users/92696.png){kind=small}
relates to
is duplicated by
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
is duplicated by
![[Bot] Piston](../../../data/avatars/users/31202.png){kind=small}
A very simple solution would be to add two types of entities: mobs, and another one for minecarts, etc, and allow hitting the other one in gamemode 1 and 2.
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
is duplicated by
MC-119841
Related to MC-579. This happens because Minecarts are entities, not blocks, and thus still breakable by definition.
Duplicate of MC-579 , please use the search function to see if your bug has already been submitted. Currently over 30% of tickets are being closed as duplicate.
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
Duplicate of MC-579.
Duplicate of Unresolved
MC-579
If you have not, please use the search function in the future, to see if your bug has already been submitted. If you could not find the original report, please comment with the keywords you searched for.
Duplicate of MC-579 - If you have not, please use the search function in the future, to see if your bug has already been submitted. If you could not find the original report, please comment with the keywords you searched for.
Duplicate of MC-579 - If you have not, please use the search function in the future, to see if your bug has already been submitted. If you could not find the original report, please comment with the keywords you searched for.
These are entities, not blocks. Plus, why have you created two identical reports? Duplicate of MC-579.
Duplicate of MC-579 - If you have not, please use the search function in the future, to see if your bug has already been submitted. If you could not find the original report, please comment with the keywords you searched for.
It's possible it could be changed, but I'm saying that's why it doesn't work.
Again, going back to MC-579, Creepers will destroy entities unless an Invulnerable NBT tag is attached to them.
Sorry, I didn't come across MCPE-22181 in my original search for some reason. I found MC-579 which was resolved with /entitydata...
which isn't allowed in MCPE. Thanks for the update.
![[Mod] Chandler](../../../data/assets/gravatar/triwonder81.png){kind=small}
Thank you for your report!
We're tracking this issue as MC-579, so this ticket is being resolved and linked as a duplicate.
That ticket has already been resolved as working as intended, which means this is not considered a bug and won't be fixed. Please do not leave a comment on the linked ticket.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Mojang Support – ✍️ Feedback and Suggestions – 📖 Game Wiki
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
Hi there!
This looks like a duplicate of MC-579, which works as intended.
You could use the command
/data modify entity <uuid> Invulnerable set value 1b
, replace the <uuid> with the UUID of the item frame/painting (should automatically fill when you delete the placeholder), and then it should not be breakable in Adventure Mode anymore.
You can suggest a change to this feature at https://feedback.minecraft.net/hc/en-us.
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
This appears to be a duplicate of MC-579, which was later resolved as Works As Intended. This "issue" you are experiencing is working how it was intended to function. See the parent ticket for more details.
Thank you for your report!
We're tracking this issue in MC-579, so this ticket is being resolved and linked as a duplicate.
That ticket has already been resolved as working as intended, which means this is not considered a bug and won't be fixed. Please do not leave a comment on the linked ticket.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
![[Mod] OcelotOnesie](../../../data/avatars/users/43220.png){kind=small}
This is working as intended, see MCPE-22181 / MC-579.
This bug is not about adventure mode. This is for visitors who lack the ability to destroy blocks or attack mobs. There is no reason to believe breaking paintings is WAI given MCPE-22181 & MC-579 as both are adventure mode-specific.
You could also use the item frames to give players items/maps in adventure mode, so it has its uses. Perhaps a gamerule could be made to toggle this?
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.
Yes, a gamerule would definitely be awesome.
I use the breakable frames to give players items and like the other posters above, I think a gamerule would be nice to toggle it.
I have this same problem, its annoying because i want them to press a button to get the items shown and for it to be reusable.
To prevent them from getting items from a dispenser I "hide" the item frames behind glass/window blocks. They seem be be unbreakable even if you use different tools in adventure mode and prevents them from hitting the frame to get the displayed item.
Still, it's adventure mode. You shouldn't be able to break or place blocks, so technically it's a bug.
Changing into adventure mode.
Me punching the picture frame in Adventure Mode.
After punching in Adventure Mode, the item frame pops off.
I think there should be a gamerule called: frameInteract So, if its set to true, anyone can break, rotate, or place items in frames or paintings. If false, no interaction can be made with paintings or frames.
I don't think you can expect a new gamerule, but I think standard they shouldn't be droppable. Since a lot of people consider it as a block, even though it's an entity.
they dont always break for me.
but sometimes they do.
@luke
They don't break in creative...
Adventure mode only not let you break blocks when not using the correct tool, but paintings and items frames(and minecarts) are entities. It's is not bug. howeher a new gamerule will me be good.
glass, tripwire and buttons are breakable since 1.4.4 (I believe) too, but that's another bug I think
Another idea would be to add an NBT tag to the item frames to specify whether or not they are unbreakable. Unbreakable frames can only be destroyed by breaking the block behind them (so they can't be broken in adventure mode)
Probably a bit harder for mapmakers but much easier to code (I think)
Edit: Oops, didn't mean to comment your post, sorry about that.
There is an entity tag for invincible entities. http://youtu.be/kLe5Hbfm68A shows how to do it with an mcedit filter. This is no longer then an issue. I wouldn't consider this a bug anymore but a wanted feature.
Confirmed in 1.5.1.
MOD PLEASE UPDATE STILL AN ISSUE IN 1.6.2
If you want to fix this as a map maker, use an NBTeditor (I prefer the nbtedit mod) and set invulnerable to 1
Probably intended, as you can only break certain blocks without a tool.
Still an issue in 14w03b.
Can be fixed by setting Invulnerable: 1
Possibly intended, still really annoying though.
Hey guys, I was hoping for this to be fixed with 1.8 and the new adventure mode mechanics, but nothing happened, so I created a reddit post for this, but the problem was that I created an account just for that and posted it directly afterwards, without noticing that you need at least 10 comment karma for a post to be shown on the new feed (and anywhere else but yourself). So as soon as I got 10 comment karma it was shown, but with the time since I created the post, so it was on the very, very bottom of the page and therefor remained unseen :/
Here is the link still, if you want to have it:
http://redd.it/1v47u3
Anyways, I, as a mapmaker, would REALLY love this to be fixed/changed.
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!
Now, with the redstone abilities of item frames, it is crucial that item frames can not be removed, as they can not be replaced in adventure mode.
Wether items in item frames should be removeable is debateable, as they can be replaced into the item frame.
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.
Confirmed and hoping so that Mojang add a patch of this on 1.8 snapshots to complete the adventure mode addition.
Confirmed for 1.7.9 and 14w17a
Confirmed for 14w28b
It's intended! In adventure mode in 1.8 you can't break blocks but item frames and paintings are not blocks but entities! Like you can kill a cow, you can "kill" a painting and an item frame! Like said before you can summon it as invulnerable which means you can't destroy it unless you're in creative mode...
{Invulnerable:1,Direction:number}"/summon ItemFrame x y z
"
{Invulnerable:1,Direction:number}"/summon Painting x y z
"
So you can change that to "work as intended"...
Paintings and Item Frames are entities that are used to represent a block, so they should never be breakable in Adventure Mode.
Still in 30c.
Quoted "Paintings and Item Frames are entities that are used to represent a block, so they should never be breakable in Adventure Mode." by [Mod] Anon Ymus
Well, they are.. in the latest snapshot.
We realize that it's still an issue, which is why we haven't resolved it. I was only saying what the behavior would ideally be, not what it is currently.
Mods, an Invulnerable NBT tag can be added to paintings, item frames and minecarts to make them unbreakable in Adventure Mode. They are entities and share the same properties as other entities such as mobs. So making these 3 objects by default unbreakable, would do the same to mobs. Also, if these specific entities are made to be unbreakable, this will effectively ruin certain custom maps as they may rely on these items being broken.
It's time to resolve this bug since there's a way to properly make these objects breakable or unbreakable, depending on the choice of the mapmaker.
Unbreakable Minecart
/summon Minecart ~ ~ ~ {Invulnerable:1}Unbreakable Item Frame (Face North and place in Command Block)
/summon ItemFrame ~ ~ ~1 {Item:{id:red_flower,Count:1},TileX:~,TileY:~,TileZ:~1,Direction:0,Invulnerable:1}Unbreakable Painting (Face North and place in Command Block)
/summon Painting ~ ~1 ~1 {Motive:"Kebab",TileX:~,TileY:~,TileZ:~1,Direction:0,Invulnerable:1}Please resolve this.
"Paintings and Item Frames are entities that are used to represent a block, so they should never be breakable in Adventure Mode."
@Anon, as a mapmaker, I can personally say this statement is not correct. Remember, Adventure Mode was made for mapmakers. Those outside this community do not fully understand the purpose of how Adventure Mode was changed for 1.8. It is not simply "everything in Adventure is unbreakable". The mode was changed to prevent cheating and assist mapmakers in their projects. I can think of plenty of instances where item frames, paintings and especially minecarts should be completely breakable. So please understand that when you say "they should never be breakable in Adventure Mode", it does not comply with what the mapmaking community is trying to do.
@qmagnet
As a mapmaker, I understand what you are talking about, BUT what we need is an easier way to make them unbreakable or a better way to prevent people from removing items. Because, for instance, if one was making an arena and wanted an item frame by each class with an item to represent each class, placing every item frame with a command block should not be necessary. We just need an easier way to make them untouchable.
@Cullen Carns, No need for a command block. Just type it in the chat box.
@Cullen, the problem is that people here are asking for a feature. The fact is that this is not a bug. Since Item Frames are entities, they do not apply to the same rule of unbreakable blocks. If people want the ability remove items from item frames without breaking the item frame, then its a feature request and would involve more coding. Its already been suggested on reddit http://www.reddit.com/r/minecraftsuggestions/comments/1ishom/ability_to_remove_an_item_from_an_item_frame/
http://www.reddit.com/r/minecraftsuggestions/comments/1v47u3/item_frames_should_be_made_unbreakable_with_18/
Dinnerbone confirms that hitting an empty Item Frame is intended to pop off.
https://twitter.com/Dinnerbone/status/373390930461884416
There is absolutely no reason to have this report open.
Agreeing with qmagnet here.
To make then unbreakable, use the "Invulnerable" NBT tag.
I feel like there needs to be an easier way to make decorative blocks like paintings, item frames, etc. Without having to write a command block every single time I want to make one.
Are you able to give yourself an item that has this tag in creative then use it multiple times? Currently the only way I have been able to do it is by using a command block for each one individually, which seems pretty crazy.
Well you can create a command with relative coordinates and ctrl-pick block the comands, bringing the command block around with you.
/summon ItemFrame ~ ~2 ~1 {TileX:~,TileY:~2,TileZ:~1,Direction:0}40 people vote for this issue - works as intended
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?
So invulnerable tag only effects people in adventure mode, not people in creative or survival?
-Brad
I am still not on board with idea adventure mode players being able to break DECORATIVE blocks like paintings is working as intended.
Invulnerability applies in adventure and survival. It used to also apply in creative which was a nightmare for map makers!
So why is everyone saying that is the correct workaround and proper method? I am confused.
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.
@Brad, they are not decorative blocks. They are entities. They share the same properties as entities. If you want them an item frame that has block properties, Mojang has to create a new item, but I'm sure it's not possible given the way you can place an item on the face of an item frame. Codewise, they perform exactly like mobs or items. They are summoned and killed. They have no block ID. And you wouldn't want them unbreakable by default, otherwise you'd never be able to take them down and move them.
There is nothing wrong with what you guys want, it's just not possible. This is not a bug because Mojang made the item frame an entity. Essentially it's the same as asking cows you tame to be invulnerable and wild cows to be able to be killed. Entities die.
I don't think it should matter what they are technically in the code. A cow is not a decoration, a sheep is not a decoration, a painting is a decoration. This obviously creates a development challenge for Mojang no one is disputing that. Thus the reason a bug exists. If they can make bunnies they can fix this.
I quote:
"[Mod] Anon Ymus added a comment - 14/Jul/14 7:09 PM
Paintings and Item Frames are entities that are used to represent a block, so they should never be breakable in Adventure Mode."
Case and Point.
I am not asking for it to be harder for people that want it to be breakable in adventure mode. I just want it to be a LOT easier to make it unbreakable for those of us who are using these entities ( that act as blocks ) for decorations for people in adventure mode. If it was unbreakable by default and you guys had to use summon commands to make breakable ones that would still be a shitty solution imo, I am sure Mojang will find a better way.
There's no point in quoting Anon here. I can quote Searge back.
The reason paintings and items frame have the properties they do is because they are entities. Think about it. Is there any actual block that can take up the same visual space or act with the same properties as the item frame or painting? If they had block properties, meaning if they were "unbreakable" in Adventure Mode, then they could take up a 1x1x1 hitbox and you would not be able to place any items as decoration on top of them.
The only way I see this changing to make it easier for you, is to make item frames and paintings unbreakable by default, but then how would you normally take them down and move them around? This would be very hectic for the regular survival world - never being able to move any item frame or painting once it's placed.
Again, I think it's a great idea. I myself would prefer the ability to make items inside item frame and item frames themselves have separate invulnerability tags. But there is no bug here.
to be clear what I want is a solution not a workaround. I am not asking to make entities that are decorative, into blocks. You can agree with Searge if you like but I can also agree with Anon. Are banners and skulls blocks? Do you think they should be breakable too?
Currently the "workaround" technically works but is not ideal for these reasons.
1. Makes entity unbreakable for everyone not limited to Adventure mode players.
2. To summon these items that are decorations takes a lengthy command or command block. For artists or creative players this is a huge headache. One example is lets say I want to create a visual display of a few game recipes using a 3x3 grid of item frames, wow that will take a while, or make a town and put paintings in all the buildings.
3. Can you give someone an item with the ability to break an invulnerable entity? like you can give them the a shovel with the ability to only dig up dirt?
Invulnerable makes total sense and should stay in the game, and works great for entities that are animals and npcs and such, makes less sense for entities that are decorations, and technically is a WORKAROUND, but I think its not a solve.
I am not sure why your so passionate about keeping it harder for people who already have it hard. I am beginning to think you either don't understand what I am saying, or your just trolling. Hopefully this clears it up, if not ... well played troll.
I think he understands what you're saying and he's not trolling (he's a famous map maker) but I think you don't understand what he's saying...
I agree with most of the stuff you said but what you're doing us asking for a feature to make it easier! It's not a bug! It's supposed to work like that... If you don't like how it works you can suggest a feature or a change to make it easier but here it's not a place to that because, again, it's not a bug!
I hope you understand...
Banners and skulls are blocks. All blocks can be placed with setblock. Entities must use summon.
You may be able to use an MCEdit filter to replace every item frame with unbreakable item frames. In fact, I know some MCEdit filter makers. I could request one if you like.
I'm not passionate about keeping it harder. I think it's a pain in the butt having to place all those item frames in my map. I thought I said this before. I want you what you want to a certain extent. It's just not possible. Coding was created to establish the rules of what an entity is, the programming doesn't allow the rules to be broken. The only way to allow for this is to create a completely new block variation.
I'm not sure how else I can explain this. It may "bug" you, but there's nothing broken about the program.
I guess if everyone is happy with decorative entities being breakable by default then your correct its a feature request.
It wouldn't be a very good choice in survival.
I think the ideal solution would be for the invulnerable tag to be copied from the item to the entity when it is placed. That way, a builder would only need to /give themselves one item with the invulnerable tag set, and all the entities placed using it would inherit the tag. This would preserve flexibility (both the breakable and unbreakable versions of these items have uses in an Adventure world) while reducing the difficulty of making use of that flexibility. However, they need to be breakable by default for the sake of survival mode.
If anyone wants an easy way to make item frames unbreakable without having to use a separate command block for each one, check out the filter Ani's Invulnerability Filter by texelelf — http://elemanser.com/filters.html Just place them normally and run the filter through MCEdit. Simple.
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.
Interestingly, this works differently for armor stands (
MC-71557).If armor stand is unbreakable in Adventure, you should also do it to Item Frames. Reopen.