[MC-862] Spawn protection doesn't work for item frames, paintings and armor stands Created: 27/Oct/12  Updated: 10/Jul/22  Resolved: 13/Jan/20

Status: Resolved
Project: Minecraft: Java Edition
Component/s: None
Affects Version/s: Minecraft 1.4.2, Minecraft 1.4.7, Minecraft 1.5.1, Minecraft 1.5.2, Minecraft 1.6.1, Minecraft 1.6.2, Minecraft 1.6.4, Minecraft 13w39b, Minecraft 13w41a, Minecraft 13w41b, Minecraft 13w42a, Minecraft 13w42b, Minecraft 13w43a, Minecraft 1.7.1, Minecraft 1.7.2, Minecraft 1.7.3, Minecraft 1.7.4, Minecraft 14w02c, Minecraft 14w03a, Minecraft 14w03b, Minecraft 1.7.10, Minecraft 14w30c, Minecraft 14w31a, Minecraft 14w32a, Minecraft 14w33c, Minecraft 14w34d, Minecraft 1.8-pre1, Minecraft 1.8-pre3, Minecraft 1.8, Minecraft 15w39c, Minecraft 1.10.2, Minecraft 17w06a, Minecraft 1.12.1, Minecraft 1.12.2, Minecraft 18w16a, Minecraft 18w22c, Minecraft 1.13-pre2, Minecraft 1.13-pre3, Minecraft 1.13.2, Minecraft 18w48a, Minecraft 18w48b, Minecraft 18w49a, Minecraft 18w50a, Minecraft 19w12b, Minecraft 19w13b, Minecraft 19w14a, Minecraft 19w14b, 1.15.1
Fix Version/s: 1.15.2 Pre-Release 1

Type: Bug
Reporter: Stefan "Blixten" Karlsson Assignee: [Mojang] slicedlime
Resolution: Fixed Votes: 26
Labels: armorstand, item-frame, painting, spawn-protection

Issue Links:
Duplicate
is duplicated by MC-9659 Minecraft vanilla server software not... Resolved
is duplicated by MC-38834 Players Able to Break Item Frames & I... Resolved
is duplicated by MC-81325 Item Frame issue in spaw-protection area Resolved
is duplicated by MC-124531 Spawn Protection does not protect Arm... Resolved
Relates
relates to MC-170076 Non-op player in spawn protection can... Open
relates to MC-1673 Several mobs can pop off paintings, i... Resolved
relates to MC-38307 Lightning strike area-effect destroys... Resolved
relates to MC-579 Entities (paintings,item frames, mine... Resolved
CHK:
Confirmation Status: Confirmed
Game Mode: Survival
Category:
(Unassigned)

 Description   

The bug

The spawn protection (spawn-protection=16 in server.properties) will not work in all situations.

A non-op player can, by pressing the left mouse button on a item frame with, for example, a diamond sword. Both the frame and the sword will be dropped an can be picked up.

Also affects paintings.



 Comments   
Comment by Connor Steppie [ 13/Jan/20 ]

I assume this also affects leash knots?

Comment by Marcoonline [ 03/Jan/20 ]

Problem still exist in 1.15.1

Comment by Xavom [ 14/Dec/18 ]

Affects:

  • 1.13
  • 1.13.1
  • 1.13.2

 

Comment by [Helper] Lord_Quadrato [ 21/Jun/18 ]

Confirmed for 1.13-pre3

Comment by [Helper] Lord_Quadrato [ 16/Jun/18 ]

Confirmed for 1.13-pre2

Comment by [Helper] Lord_Quadrato [ 31/May/18 ]

Confirmed for 18w22c

Comment by [Mod] bemoty [ 12/Aug/17 ]

Can confirm for MC 1.12.1.

Comment by Mr. Piggens [ 13/Feb/17 ]

Yeah, it seems like it's an issue with item-frames and paintings being entities. A possible fix with be to add the

{Invulnerable:1}

NBT tag to all of those types of entities in a spawn-protected area. The only problem with this is that even players with Operator Permissions couldn't break them. Servers would have to turn off, disable spawn-protection, edit the map, turn spawn-protection on, and then turn the server back on. This isn't really a major setback, as most servers would edit the world spawn either when the server was offline or in a duplicate file anyway.

Comment by Marcono1234 [ 26/Sep/15 ]

Confirmed for

  • 15w39c for item frames and paintings
Comment by [Mod] Torabi [ 05/Aug/14 ]

Intention cannot be understood purely by looking at code. Otherwise, we could mark all issues as "Works As Intended", with no further thought, because the game is doing exactly what it's programmed to do. Software is typically an imperfect representation of the developer's intended behavior, whether due to typos, inaccurate logic, false knowledge about other code, or some other mental error. Or, in some cases, multiple components that are each working as the developer intends them to may produce unintended behavior when they interact, because the developer did not account for that interaction.


  • Spawn protection works for blocks, because when it was implemented, there were no entities such as paintings or item frames that the developers might have wanted it to protect. All entities were mobs, players, or dropped items.
  • Item frames are entities because it was the simplest way that occurred to the developers to implement them at the time. It would be possible to make a block with the desired functionality, and due to how the code has changed, and features that have been introduced, it would probably be easier to do now than it was when item frames were first implemented.

Mojang could change either of these things. They could make spawn protection apply to item frames, without affecting any other entities. They could apply the invulnerable tag to any item frame hung in the spawn area, or prevent non-creative players from hanging them in that area. They could make item frames into blocks, or even invent an entirely new type of object to handle them. They wrote the rules in the first place, they can change them or make exceptions to them.

There's reason to believe this might be an oversight, and we have explicit instructions not to mark tickets "Works As Intended" without evidence, such as a statement from Mojang. Thus, we've left it for them to make a decision on. Not only has it been on the tracker for a significant period of time, it's been brought to their attention. The behavior of item frames has changed over time, and things like the introduction of the invulnerable tag and the development on Adventure mode may allow them to make a decision on this. Developers don't always know exactly how they want things to work right from the beginning. Sometimes it takes some experimentation to see how the behavior feels to determine that.

Comment by Dlawso the Really Lucky Rabbit [ 05/Aug/14 ]

Eh, I think I'm done with this as well. Same thing as qmagnet. We'll just wait until Mojang decides if its a bug or if its meant to be this way.

Comment by qmagnet [ 05/Aug/14 ]

Fair enough. I guess to me it just seems to waste the devs time, instead of them spending the time to fix the mile long list of programming glitches.

Comment by [Mod] Ezekiel (ezfe) [ 05/Aug/14 ]

I don't understand what you meant by "This disproves intention of making it an entity, making it no longer a feature request".

I meant that by that last part you were basically saying that they would have made it a block if they could but blocks are technologically limited and can't do that part. Therefor its clear they intended to make a block, but were forced to use an item frame behind the scenes. Therefor this isn't a feature request because they intended it to behave like a block.

I'm personally done with this argument. I don't get why you are insistent that this isn't a real issue, it doesn't affect you. Do you not want this to work? You said you did, so why don't you just let this ticket stay open and stop saying its impossible. If its impossible Mojang just won't fix the issue, and nobody will be any worse off.

Comment by qmagnet [ 05/Aug/14 ]

All I'm saying is there are things I think would be great if it were possible. This I can't see being. The source of spawn-protection affecting blocks is proven by simply running a server and testing any entity inside the spawn radius. Can minecarts be broken? Can wolves be killed? Look at the world in MCEdit, it will clearly show you colours that represent entities.

I see no contradiction in my statement. I would love for it to BE possible. The user may perceive this as "my spawn is totally protected" but the coding has rules and from the little knowledge of programming I have, I can't see how this is possible to change.

I hope I'm wrong.

I don't understand what you meant by "This disproves intention of making it an entity, making it no longer a feature request".

Comment by [Mod] Ezekiel (ezfe) [ 05/Aug/14 ]

Mods, if you are keeping this bug report open just so a Mojangstah can take the blame for stamping a WAI resolution on it, I understand. But I really wish you guys would understand the difference between a block and an entity. Both Sonic and I aren't saying it's a bad idea. We are saying it's not a bug.

I don't know wether Mojang will mark it WAI or not. I don't have authorization to close it unless I'm 100% sure its WAI, which I'm not. This is because we have a fundamentally different definition of 'spawn protection'

Do I wish player's could protect anything they want on a server spawn? YES! Absolutely. And with a bit of NBT mapmaking knowledge, you basically can

Keep this statement in mind

But spawn-protection is just a term saying blocks within the radius can't be destroyed

Where do you learn this "definition". What is your source that spawn protection refers to blocks, and cannot refer to entities at the intention level (not the code level, disregard the code).

For item frames to be unbreakable, every entity inside that spawn radius has to be unbreakable

Remember that sentence earlier about NBT data? Doesn't that kinda contradict this? If I can, using a command block loop, make something happen, than so can Mojang, with code.

Note: I'm pretty certain the reason an Item Frame can act as an item placement is because it IS an entity. I don't think there is any way a block could do this.

This disproves intention of making it an entity, making it no longer a feature request

Now, lastly. I want to clarify that of course I understand the difference between an entity and a block. A block is a word applied to a integer coordinate. You can't have a block go from 75.0 to 76.0, left to right. It must go from 75.5 to 76.5, with no exceptions. Whereas an entity has a floating point coordinate, meaning it can move around freely. An entity also has NBT data, meaning it can store much more data about itself than a block. I completely understand this, and what I'm saying is that just because at the code level its an entity doesn't mean a user doesn't perceive it as a block. You need to stop thinking about how its implemented, and instead about how it acts.

Comment by qmagnet [ 05/Aug/14 ]

Mods, if you are keeping this bug report open just so a Mojangstah can take the blame for stamping a WAI resolution on it, I understand. But I really wish you guys would understand the difference between a block and an entity. Both Sonic and I aren't saying it's a bad idea. We are saying it's not a bug.

Do I wish player's could protect anything they want on a server spawn? YES! Absolutely. And with a bit of NBT mapmaking knowledge, you basically can. But spawn-protection is just a term saying blocks within the radius can't be destroyed. So unless Mojang adds a new item frame block type that people can use, it just can't happen. For item frames to be unbreakable, every entity inside that spawn radius has to be unbreakable. So is Mojang going change the spawn-protection property so that any stray creepers are invulnerable inside that radius? I'm not even sure that's possible.

Note: I'm pretty certain the reason an Item Frame can act as an item placement is because it IS an entity. I don't think there is any way a block could do this.

Comment by Galaxy_2Alex [ 04/Aug/14 ]

@Sonic:
Someone that just plays the game doesn't care how it is in the code. He sees the Item Frame as something that he can build with and that should stay in place when it's protected by spawn protection. And it not as hard as you describe it to solve this issue. Oh well, we poked DB about it, we'll see what he thinks about it.

Comment by [Mod] Ezekiel (ezfe) [ 04/Aug/14 ]

an entity itself can't be a block or even behave like one as it violates the dynamic object coding in computer games and game engines.

How does this relate to spawn protection on item frames?

An entity is basically a dynamic object such as a non-playable character or an item.

A player is an entity...

The spawn protection in the server.properties only applies to blocks.

Source?

An item frame is not a block, but an entity. An item frame is not meant to be a block and therefore doesn't count as such.

Just because they implemented it as an entity (because it needs features a block can't provide), doesn't mean it shouldn't behave like a block. After all, it takes up a 1x1x1 space, it doesn't move, and it can't occupy the space of another block.

Comment by Dlawso the Really Lucky Rabbit [ 04/Aug/14 ]

qmagnet's right.

To add on to what he's saying, an entity itself can't be a block or even behave like one as it violates the dynamic object coding in computer games and game engines.

An entity is basically a dynamic object such as a non-playable character or an item.

The spawn protection in the server.properties only applies to blocks. An item frame is not a block, but an entity. An item frame is not meant to be a block and therefore doesn't count as such.

Why would people want to classify them as blocks when they literally aren't?

In laymen's terms, "this is a feature request and not a bug." - qmagnet

Comment by Galaxy_2Alex [ 03/Aug/14 ]

The people don't care how it's coded, and if we close this, they'll report it again/complain why we closed it since it is a bug from their point of view. Keep in mind that you are not the only person, and that other people have their own views as well.

Comment by qmagnet [ 03/Aug/14 ]

You have to look at them as coded items. It doesn't matter what they are used for, if the code doesn't allow for it, you can't claim it's a bug.

Comment by Galaxy_2Alex [ 03/Aug/14 ]

Item Frames can be part of a building, a spawn building if you will. The builder decides that it would look nice to have some of them hanging around with some items in it to give the place a better atmosphere. The builder does not want it to be destroyed or anything like that. Well, sadly, there is that bug with the item frames.

Item Frames are technically seen entities, correct. But just technically, if you look at them from another perspective, they are building material, and the spawn protection exists so that random people cannot just destroy your builds.

Comment by qmagnet [ 03/Aug/14 ]

They are treated exactly the way any mobs are treated. They are spawned using summon and destroyed using kill. I don't understand why people seems to want to class them as blocks. There are too many reports like this where people don't understand how the components of Minecraft actually work. Saying this is a bug, means Mojang has missed something in the code, or has added something new that has negatively affected or unintentionally affected something that previously worked properly. Neither of these is the case in this. This is a feature request, not a bug.

Comment by [Mod] Ezekiel (ezfe) [ 03/Aug/14 ]

qmagnet, just because they are in the code, entities, doesn't mean they're treated like, say, a creeper is treated. They behave like a block.

Also the wiki is *not* a reliable source of information determining the intention of the developers.

Comment by qmagnet [ 03/Aug/14 ]

It has to be intended based on Item Frames being entities. http://minecraft.gamepedia.com/Server.properties specifically explains that spawn-protection applies to blocks. Because Item Frames are not at all blocks and should not be identified as such. Essentially, it's equivalent to expecting for Creepers to be indestructible on spawn. The spawn-protection applies to blocks alone.

Comment by Anon Ymus [ 03/Aug/14 ]

We understand why this issue exists. That doesn't mean it is intended.

Comment by qmagnet [ 03/Aug/14 ]

Item frames are not blocks, they are entities and so share the same properties as mobs which can be killed at spawn.

Comment by Stefan "Blixten" Karlsson [ 01/Aug/14 ]

The problem is still there, unfortunately. Affected versions has been updated.

Comment by TGS [ 07/Dec/13 ]

Confirmed

Comment by [Mod] Ezekiel (ezfe) [ 19/Oct/13 ]

This ticket contains two different bugs so therefor I am removing the signs part and adding that to a new ticket: MC-36093

Comment by Tavis [ 22/Dec/12 ]

It works fine for chests.

Signs and chests are tile entities. The difference between tile entites (chests, signs, etc.) and entities (paintings, item frames, chickens, etc.) is whether they require a block to exist. Tile entities cannot move around freely or exist in the same space as another block, while entities can exist practically anywhere.

Stairs, cakes, anvils, torches, water, and portals are neither tile entities nor entites, even though they are not cubes.

It is possible for blocks to look a lot like entities, and entities to look and behave a lot like blocks. The minecraft wiki is a pretty good place to look if you're not sure what something is.

Comment by Anon Ymus [ 11/Dec/12 ]

Signs are blocks. An entity is something that can move/change. Item frames are actually entities.

Comment by Nerdyboy6057 [ 11/Dec/12 ]

Technically signs are definitively entities as they do not conform to the cube-shaped base of Minecraft, however the game seems not to treat them the same way.

Comment by Anon Ymus [ 11/Dec/12 ]

No, signs are not entities. When they are destroyed, they reappear but without text.

Comment by Nerdyboy6057 [ 11/Dec/12 ]

Spawn protection is not available for signs and item frames, just like animals and mobs. This is because as they do not fit into the cube alignment of the game, they are classed as 'entities'.

This is a known bug and can only be resolved through 'spawn protection' where entities (i.e. pigs) cannot be killed: This is an almost impossible task.

Comment by Anon Ymus [ 11/Dec/12 ]

I can confirm.

Comment by Michal Manowski [ 08/Dec/12 ]

If you relog the text on a sign should be back. (past experience)

Comment by Michael [ 01/Nov/12 ]

Confirmed, the text reappears on relog, but not with the item frame.

Generated at Sun Jan 12 11:52:29 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.