Spawn protection doesn't work for item frames, paintings and armor stands

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.

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

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.

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

Confirmed

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

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

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

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.

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.

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.

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.

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.

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.

@unknown'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

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.

@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.

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.

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.

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".

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.

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.

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.

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.

Confirmed for

• 15w39c for item frames and paintings

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.

Can confirm for MC 1.12.1.

Confirmed for 18w22c