Blocks don't retain their names, enchantments, or attributes after being placed and picked up again

This has seriously been marked as "Works as Intended"?

Surely the solution is to prevent blocks being named using the anvil.

Why would you prevent it? This makes the assumption that all blocks will eventually be placed. You may as well prevent renaming food, under the assumption that it will eventually be eaten. I personally like how it is right now, where any item can be renamed.

Those situations are not comparable. There is no expectation for an items's name to persist after it has been eaten. There is an expectation for a item to retain it's name after it has been placed.

People would have spend their hard earned experience on renaming it and they would have no reason to guess won't be maintained. IMO, Allowing placeable blocks to be named in the first place was a mistake.

Renaming blocks could be well used for some adventure maps. For example renaming levers/torches (which can be placed like blocks) to for example "magic key" to open a gate with them. Obviously this could be also used for full blocks like "Place that magic stone [=gold block] at a specific spot to complete the puzzle".

I agree that renaming block is survival is quite useless, but that's not a good reason to disable it. You can do other useless things like throwing your diamond pickaxe into lava and there is no need to prevent that.

I never said it should be disabled because it's useless. I said it should be disabled because the behaviour is non-obvious.

If you throw a pickaxe in to lava, you expect to lose it. You do not expect a named block to lose it's name when placed. (Unless, perhaps you are familiar with Minecraft's internal workings.)

OK, well, you could display a warning in the anvil gui that placing the block will make it lose it's enchantments. Or you could enable naming blocks and other items that could possibly easily lose the name only in creative mode.

But why would you want to name a block and then place it (apart from the obvious puzzle elements)? Even if it did retain the name, you wouldn't be able to see it when it's placed.

As for why someone would want to place a named block: I am not sure. But I have seen the complaint that you can't a lot, so people are for some reason.

I still don't see why you should remove block renamability just because the behavior isn't obvious. Perhaps a warning in the GUI may be good.

There is no way to keep a block's name after it is placed, but as I said, removing the feature simply on that pretense implies that the user is eventually going to place their renamed block. Do you expect your names/enchantments to vanish when you repair tools without an anvil? No, but at the very least there is a preview that this will happen. If the user were aware that a block's name is lost upon placement, then this issue would be resolved just as easily as removing block renaming would - with the added benefit that a fun feature does not get removed.

MC-3053 I renamed a jack-o-lantern Wilson and planned on taking him with me to various areas in survival. This issue is an immersion issue. If I can rename things, I have a natural expectation that the name will follow. I still call my jack-o-lantern Wilson, but it's not reflected in the game, and I've still spent the experience I cannot get back.

Renaming an object goes beyond the utilitarian aspect of identification.

Joseph is trying to communicate a very simple point, the item should retain it's name throughout the entire lifetime of the item, or else be blocked from being renamed. Placing then mining a block is the extension of the lifetime of that item (even if the item is technically not the same), that said the item should be blocked from rename in survival mode for the simple point that it costs XP and they are essentially totally wasting their XP if they expect the item to retain it's name after being placed.

The simple work around to the problem of adventure maps is to allow blocks to be renamed in creative mode (like unorthodox enchantments can be added to items in creative mode).

I'm not sure what's with this trend of people wanting to remove features from the game just because they aren't perfect. As I said above, just give the player a warning such as "Warning: this block will lose its custom name if it is placed on the ground."

It's an even greater waste of experience to learn that your level 30 diamond sword has lost all of its enchantments because you repaired it on a crafting table instead of an anvil. This behavior is also not immediately obvious if you don't already know anvils exist or don't know their purpose. However, the loss is mitigated by the fact that you can actually see the enchantment will disappear, if you look at the crafting table's output.

Thus, a if a warning is sufficient for a potential 30 level loss, it should be equally sufficient for a potential 5 level loss. I like being able to name blocks in survival for various reasons; I don't see why there needs to be the automatic assumption that I will someday place that block and despair that my block has lost its name. I'll be careful with my blocks, just as I am careful with my enchanted items.

EDIT: An alternative may be to have a warning pop up (similar to the 'Are you sure you want to navigate to this link?' warning), so if a player attempts to place a renamed (and, for adventure maps, enchanted) block, it will warn them that the special properties will be lost. This warning would also have a "Never show this warning again" button, just like the link navigation warning. Such a warning would be better-placed, as it's possible to obtain a renamed block without renaming it yourself.

The game intuitively warns you about crafting table repairs though, because the end result item is exactly what you're getting, and it does not have enchantments.

Anyway, the feature isn't being removed (it was rather melodramatic for you to suggest I was asking to remove the feature), it's being modified so it makes sense from an intuition standpoint. The alternative is to allow every block to store meta-data when placed, which would be infeasible given the nature of things. Implementing a warning is also bad game design, if you have to warn the player about the code discrepancy between items and blocks when it comes to enchantments, the system is obviously not working in an intuitive fashion.

Bombarding your players with dialogue boxes and warnings is poor game design; ask any game designer worth his weight and they'll agree with you, you only ever use warnings when there isn't a more intuitive option available. Sometimes you have to sacrifice a little bit of freedom (and this is really a tiny bit of freedom) for a more streamlined and intuitive user experience.

In the scheme of renaming items, the freedom lost isn't that tiny. It would exclude renaming of any item which can be placed, including buckets, redstone, levers, saplings, etc. This is roughly 178 of the 304 items and blocks with unique IDs - in other words, a very clear majority. The feature being removed is the ability to rename placeable items (and, simultaneously, the fact that you have the ability to rename any item in the first place).

If you really want to avoid any form of warning whatsoever, it could also be possible to simply prevent the placement of a renamed block. Of course, this would clash with potential uses for renamed blocks in adventure maps.

There are many things about this game which are not immediately intuitive - for example, that gold is terrible for armor and tools in terms of its durability, despite likely being the next best material you acquire after iron. Sure, you can apply real-world logic and say "gold is soft", but by that measure you wouldn't have needed a stronger pickaxe to mine it in the first place. The fact that ore blocks do not drop experience is also not immediately intuitive to players - and yet, it is necessary thanks to the player being able to place and re-harvest said blocks. Many quirky mechanics, such as pistons being incapable of pushing tileEntities and water interacting oddly with various blocks, are also not quite intuitive and owe their existence to the game's implementation.

Why am I bringing all that up? I've seen players wonder why their gold sword isn't doing much damage - why they can't get experience from iron - why they can't push note blocks with pistons and now have to rethink their design. Players will learn from mistakes all the same. If you're convinced that such a minority of players want to rename blocks in the first place, then that means only a small amount of players has to learn a non-intuitive lesson - and I'm certain a decent percent would rather learn blocks don't retain their names when placed, than learn blocks can't be renamed at all.

Also, of course, it's not literally infeasible to make it possible for items to retain names when placed. A generic tileEntity could be created for the purpose, and assigned to any named block when placed. This would not add the generic tileEntity to any other blocks - only the renamed instance - and it could thus be recovered with its data intact. Existing tileEntities could also be expanded to allow for the same 'tag' compound, so your chests, etc. can retain their names too. And to top it off as a feature rather than a bugfix, renamed blocks could have their name rendered above them, in a manner similar to players. Inb4 somebody complains that they can't use pistons to make Wilson drop as an item 😛

Of course, all of that is perhaps too mod-esque and Grum has already stated that this will never happen. Never happen != completely infeasible.

EDIT: You know what? How's this for a friendly solution: if a renamed block is placed, it will drop the experience which renaming it cost. Now, the experience cost would vary, so a new tag such as 'storedExperience' would have to be added to ensure a player doesn't get five levels per block when they renamed 64 of a block for 39 levels. This has some powerful added benefits: aside from compensating the player's loss, it could be used as a practical means of safely storing and/or sharing experience, and in adventure maps can give the player a very special bonus. Even though it may not be very intuitive that placing a renamed item sheds its name (and enchantments, for that matter... Battlesigns, anybody?) and drops that magic as experience, it's still arguably better than players finding their experience wasted.

1. Certain items that are placed could retain their meta-data such as water buckets, because the item changes type but is not destroyed, meaning meta-data can be retained.

2. That would be less intuitive than my suggestion because you're changing the function of a renamed item without any indication that the function would be changed at all. This presents a significant problem when people go and rename expensive blocks like jukeboxes and enchanting tables. I would rather have the warning than this.

3a. I think we should avoid the discussion of gold being terrible because it's a special case of conditioning where video-game logic doesn't align to real-world logic. I'm not avoiding the subject; it's just that the discussion is a dead-end one that I don't want to waste time on.

3b. I will concede that the special case for TileEntities is unintuitive, but I did cover this: where there is no intuitive option, then you may proceed to use other methods to compensate. In this particular case, there is a technical limitation with the game that prevents the use of intuitive methods - so the fall back is to block moving TileEntities.

4. I find your logic to be very flawed, I'll simply say; you can't miss what you didn't have. A player who learns blocks can't be renamed may be disappointed, but the rule will be consistent: all blocks can't be renamed. Whereas the current rule is: everything can be renamed, but blocks can't retain their name in certain circumstances.

5. This would create endless technical problems regarding corner cases for blocks which are both regular Tiles, but in certain circumstances are TileEntities, not to mention that TileEntities are significantly less efficient than Tiles because they have unique properties which can't be dealt with using Tiles - those unique properties are also more processor intensive and that is why their usage is limited to a small selection of blocks which couldn't function without this unique code. You would understand why this is how it is if aren't a programmer. To try to put it simply, if TileEntities were more flexible than Tiles, yet equally as efficient, wouldn't you just make everything a TileEntity?

6. Your final solution is probably your best one and is definitely within the realms of technical feasibility. I would be happy with that implementation.

I agree removing the ability to place named blocks is pretty terrible (to me, not as bad as not being able to name them at all, but that's a matter of opinion), though I suppose the player could spend another 5 levels (7, actually, since the rename cost gets bumped up) to change it back to the original name, which the game could detect as 'not renamed' and allow placement of. Though, it's still an idea I'd never root for - I'd also prefer a warning to it.

"You can't miss what you didn't have" only applies to players who learn about item renaming after the change. There are hundreds of thousands of premium MC players right now who probably know about it, so they would likely miss renaming placeable items. In addition, it's not exactly intuitive that you wouldn't be able to name, say, a piece of string, even after reading on the wiki that placeable items cannot be renamed. I could easily see a player deciding they wish to rename a given item, spending a bit of time to get 5 levels, and then realizing they can't rename said item. Thus, it is still possible to be disappointed in learning you can't rename an item, especially given that roughly half of the game's items will be renameable and roughly half won't. It might not be readily apparent to the player that all items in the latter group are placeable, and that placeability is somehow what's preventing these items from being renamed - there may even be erroneous bug reports regarding these misunderstandings.

And I am a programmer, and I am aware that TileEntities are not efficient for use in situations when they can be avoided (in fact, I'm a bit worried about the upcoming modding API's recommendation to use TileEntities for blocks that need extra data in lieu of Tile metadata (which is being removed), unless of course the performance of TileEntities is somehow improved before then). This is why I said the solution is rather mod-esque: it's a hack, and would not bode well in cases such as players renaming entire stacks of items to build with (or worse, server admins deciding to get cute and sell loads of renamed building materials - lag city, anyone?), and I can see reasons against implementing it. It's not implementation feasibility that's the issue, however, it's the performance of the implementation (there is, of course, no feasible implementation without these issues). I'd just like to make that clear, since it's often that somebody will make a mod and say "see? Mojang said it would be too hard to add - but there, I did it!" - and even if the modder themself does not have such an attitude, the users of their mod will, and those players will badger Mojang to incorporate an inefficient mod which they never will (colored lighting and other mods come to mind).

Anyways, I'm glad you agree with my last idea (it really was a last-minute thing after I wrote all that - had I come up with it sooner, I'd have written significantly less). It's definitely better than any of my other ideas, and would be pretty fun too. It's also good because the solution is not divorced from the problem: placing named items is the issue, not naming placeable items.

The NBT data isn't stored when placing the block. However, if you name a Spawn Egg, it'll say The Guy was slain by Mob X

They could just added custom name tag just like in tile entities.

The problem is, most blocks don't have tile entities. You'd have to create a generic tile entity for blocks that don't, and tile entities don't exactly have the best performance. It would be a bad idea to use Tile Entities for something like this.

Grum said in the API plans that there will be some sort of block metadata, similar to NBT, which wouldn't do all the things that make tile entities slow. It seems that this would be a better way to implement the name data, as it in no way effects the block's rendering, nor does it require regular Tile Entity Updates. Of course, this concept of non-TileEntity block NBT metadata has yet to be implemented.

Solution to ALL of this:
With the new internal block states, and not using numerical metadata internally, look in middle/top right of F3 screen in latest snapshots, you see stuff like this:

minecraft:dirt
variant: podzol
snowy: false

would it be so hard to add an extra 'name' and 'enchantments' property to blockstates?

I know this may be considered an old topic, but is there any way to store data into a block that does not hold block data (Like when I use the blockdata command on a block that has nothing to query.... Like lets say a stone_slab) then use a query on that block after attaching some data to the block. (Since the item name is not stored into a block that has been placed I could just store some value into a block I set, query that value, then replace the inventory with said custom item with custom name... with of course a lot more machine behind this...)?

I was working on an adventure map to have an in depth crafting system with custom blocks that have been named, and obviously I ran into this issue here. I understand that block will never = an item, but for consistency with building using custom items I believe that this would be a nice feature to add to the game if it has not already been.

Sorry for a perhaps terrible explanation/question with the mis-use of any terminology!

Thank you for your time (I know this is not really a Q and A section, but I thought this might have been a bug to then reach this page.... didn't really know what else to do)

I created a new ticket for player heads, since those are not regular blocks but already have the ability to store data: MC-174496

I can confirm this for 20w14a. Can I request ownership? Tuna YASA did not do anything since 25.10.2012

Can confirm for 20w16a

It would be pretty cool possible side effect of fixing this if blocks with enchantments had the enchantment glint when they are placed.

Can confirm in 20w48a.

Can confirm in 20w49a.

This would also give problems with blocks dropping other blocks when they're mined

Can confirm in 20w51a.

to be honest, I think it is working as intended ... 

blocks aren't supposed to keep the name tag (or enchants)

As early on as anvil mechanism came in I had tried placing poppies named "rose" but they drop poppies

I don't think so because it has Mojang Priority and it was Working As Intended until April, when it was reopened. I think it's less likely to be WAI again if it was long time WAI and it was reopened.

Also, where is the proof that blocks can't keep enchants? You need a source. Also, it must be something that is not outdated (April or later).

Current enchantments only make sense on weapons/tools/armor. You can't enchant blocks in survival mode using an anvil. The ability to do so in creative mode is a result of being able to enchant any item. Being able to name any item has multiple uses, but in relation to blocks it allows containers' GUIs to show custom titles, so in this case it makes sense to save the name in the already-present tile entity data.

From a more technical standpoint, storing names and enchantments in placed blocks would require tile entities or something similar, which with current game mechanics would make the block unmovable by pistons even if it's normally movable (imagine unmovable dirt). The only way to fix this would be to fix MC-164, which is currently still marked as WAI.

I'm very interested to see what direction Mojang go with this given that difficulty.

While acknowledging the technical limitations that currently exist, it is interesting to note that Player Heads have default NBT data that is retained upon placement in the world and when broken and dropped as an item. Any custom data, like remaining or value placed on them, is currently lost.

Player Heads are broken when moved by a piston.

So, my understanding is that Player Head is a block that by default contains 1 NBT data tag that [should not be removed] when placed in the world and or broken and dropped as an item. Seems like a reasonable compromise to me; instead of being immovable just have customized blocks break when pushed as a trade-off for retaining custom data.

There is an open ticket MC-174496 to address the issue of Player Heads losing custom data.

As a server admin I have wanted to build special features in my world with blocks that have the "Enchanted" glow effect on them. This issue prevents us from doing that.

Can confirm in 21w03a.

Can confirm in 21w05a.

Can confirm in 21w05b.

Can confirm in 21w06a.

Attached an updated video as the previous one is heavily outdated.

Can confirm in 21w08b.

Relates to MC-91007, MC-91006, and MC-1981.

Can confirm in 21w14a.

Can confirm in 21w15a.

Can confirm in 21w17a.

Can confirm in 1.17.

What about servers

why do chests keep there nbt data?

Because chests are block entities.

This will probably never be fixed because it would require a massive change in the way blocks are stored and will cause lag because every block would need to be a block entity

If that was true, Mojang would resolve this as "Won't Fix."

Requesting this report to be split up in 3 reports:
1. Carved pumpkins, heads and skulls donvt keep curse of binding when placed (They can get it applied in survival)
2. Most blocks don't keep custom name when placed (Again, can be done in survival)
3. Enchanted blocks don't keep enchantments when placed. (Aside from the carved pumpkin, heads and skulls, this is only possible in creative mode, thus deserves to be treated separately)

Affects 1.18.1

Can confirm in 1.18.2.

Can confirm in 1.19.

Can confirm in 22w24a.

the enchanted block/pumpkin thing is very interesting. maby this is caused by enchanted blocks not being implemented properly because only 1 block being enchantable with 1 enchantment (without commands) and the developers not caring when this was added back then 

Can confirm in 1.19.1.

Can confirm in 1.19.2.

Can confirm in 23w03a

Can confirm in 23w04a

Can confirm in 23w06a

Can confirm in 23w07a.

Affects 1.20.1.

Can confirm in 23w32a