[MC-209] Blocks don't retain their names, enchantments, or attributes after being placed and picked up again Created: 24/Oct/12  Updated: 07/Dec/24

Status: Reopened
Project: Minecraft: Java Edition
Component/s: None
Affects Version/s: Minecraft 1.4.2, 1.15.2, 20w13b, 20w14a, 20w15a, 20w16a, 20w17a, 20w18a, 20w19a, 20w20a, 20w20b, 20w21a, 20w22a, 1.16 Pre-release 2, 1.16 Pre-release 3, 1.16 Pre-release 5, 1.16 Pre-release 6, 1.16 Pre-release 7, 1.16 Release Candidate 1, 1.16, 1.16.1, 20w27a, 20w28a, 1.16.2 Pre-release 1, 1.16.2 Pre-release 2, 1.16.2 Release Candidate 1, 1.16.2 Release Candidate 2, 1.16.2, 1.16.3 Release Candidate 1, 1.16.3, 1.16.4 Pre-release 2, 1.16.4 Release Candidate 1, 1.16.4, 20w45a, 20w46a, 20w48a, 20w49a, 20w51a, 21w03a, 1.16.5, 21w05a, 21w05b, 21w06a, 21w07a, 21w08a, 21w08b, 21w10a, 21w11a, 21w13a, 21w14a, 21w15a, 21w17a, 21w18a, 1.17 Pre-release 1, 1.17 Pre-release 2, 1.17 Pre-release 5, 1.17, 1.17.1 Release Candidate 1, 1.17.1, 21w39a, 21w42a, 1.18, 1.18.1, 1.18.2, 1.19, 22w24a, 1.19.1, 1.19.2, 1.19.3, 23w03a, 23w04a, 23w07a, 1.19.4, 23w14a, 1.20.1, 23w31a, 1.20.2, 1.20.4, 24w10a, 24w11a, 1.20.5, 1.20.6, 1.21 Pre-Release 2, 1.21 Pre-Release 3, 1.21, 1.21.1, 24w36a, 1.21.2 Pre-Release 3, 1.21.3, 1.21.4
Fix Version/s: None

Type: Bug
Reporter: [Mod] Avoma Assignee: Unassigned
Resolution: Unresolved Votes: 74
Labels: None

Attachments: PNG File 2021-05-12_14.40.46.png     PNG File 2021-05-12_14.40.51.png     PNG File 2021-05-12_14.40.59.png     File MC-209.mp4     File clip0027.avi    
Issue Links:
Duplicate
is duplicated by MC-7730 Renaming, Placing, Removing, and pick... Resolved
is duplicated by MC-8219 Named items don't stay named... Resolved
is duplicated by MC-12616 Torch bug Resolved
is duplicated by MC-17574 Flower losing enchantment Resolved
is duplicated by MC-18383 Renaming Player Head Problem Resolved
is duplicated by MC-21522 Name Bug Resolved
is duplicated by MC-22106 NBT tags are not saved between placem... Resolved
is duplicated by MC-28455 Named blocks dont keep name after pla... Resolved
is duplicated by MC-38764 Named Blocks are Normal when Dropped Resolved
is duplicated by MC-46821 Renaming, placing, picking back up, a... Resolved
is duplicated by MC-48346 Placing a block with NBT tags causes ... Resolved
is duplicated by MC-49119 Named signs losing names when placed Resolved
is duplicated by MC-51483 Renamed blocks Resolved
is duplicated by MC-64795 Banners loosing their names. Resolved
is duplicated by MC-67203 Names on Banners are eliminated once ... Resolved
is duplicated by MC-68199 Banners named with anvil loose name w... Resolved
is duplicated by MC-71276 A named block losses it's name when p... Resolved
is duplicated by MC-77294 Banner name Bug Resolved
is duplicated by MC-79700 Named plants lose their names when pl... Resolved
is duplicated by MC-79878 Player Skulls do not save their name ... Resolved
is duplicated by MC-96928 Chest names lost when you pick them b... Resolved
is duplicated by MC-107462 shulker box loses enchantments after ... Resolved
is duplicated by MC-141118 When a plant is placed in a flower po... Resolved
is duplicated by MC-142354 All non-solid blocks lose their name ... Resolved
is duplicated by MC-147525 Renamed items drop with their origina... Resolved
is duplicated by MC-153577 Naming flowers Resolved
is duplicated by MC-157559 Flowers lose name when removed from f... Resolved
is duplicated by MC-162978 custom named placeable items revertin... Resolved
is duplicated by MC-171395 Putting a Renamed Flower into Flower ... Resolved
is duplicated by MC-176582 Not all items retain their name when ... Resolved
is duplicated by MC-177730 Item name gets removed Resolved
is duplicated by MC-183315 Redstone Torch Resolved
is duplicated by MC-188910 Entity names Resolved
is duplicated by MC-198799 Player Head NBT data and name lost fr... Resolved
is duplicated by MC-202636 Potted items don't retain anvil name ... Resolved
is duplicated by MC-202784 Named items stopped being named after... Resolved
is duplicated by MC-209265 When you change name in anvil and des... Resolved
is duplicated by MC-212824 Player Heads do not retain the name t... Resolved
is duplicated by MC-226554 Flowers do not save their NBT when pl... Resolved
is duplicated by MC-231330 Renamed candles reset their name when... Resolved
is duplicated by MC-231692 Renamed stone button reverts to origi... Resolved
is duplicated by MC-233442 Blocks don't keep custom names Resolved
is duplicated by MC-235270 Enchanted carved pumpkin will drop un... Resolved
is duplicated by MC-239704 The name of the item does not remain ... Resolved
is duplicated by MC-272956 When renaming a block and installing ... Resolved
is duplicated by MC-44 When one names a block type using the... Resolved
is duplicated by MC-874 Anvil Resolved
is duplicated by MC-3053 Named item loses name Resolved
is duplicated by MC-3102 Misnomer of the object. Resolved
is duplicated by MC-5308 When you place down an enchanted or r... Resolved
is duplicated by MC-1007 Rename Block Bug Closed
Relates
relates to MC-91006 Some entities lose their name when pl... Open
relates to MC-91007 Some items lose their name/data tags ... Open
relates to MCPE-160885 Carved Pumpkins lose enchantments whe... Open
relates to MC-91005 Some Entities/BlockEntities don't sto... Resolved
relates to MCPE-183539 Blocks don't retain their names or en... Resolved
relates to MC-1981 All arrow types lose their name/NBT d... Resolved
relates to MC-276161 Shulker boxes don't keep all componen... Open
relates to MC-26682 Minecarts don't keep their lore text ... Resolved
relates to MC-174496 Player heads lose their name after be... Resolved
CHK:
Confirmation Status: Confirmed
Category:
Block states
Mojang Priority: Low
Area: Platform

 Description   

The Bug:

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

Steps to Reproduce:

  1. Give yourself an enchanted block of dirt by using the command provided below.
    /give @s minecraft:dirt[minecraft:enchantments={levels:{"minecraft:protection":1}}]
  2. Place down the dirt, pick it back up, and observe if the dirt is still enchanted.

Observed Behavior:

The names, enchantments, and attributes are lost after the said block is picked up after being placed down.

Expected Behavior:

The names, enchantments, and attributes would be retained after the said block is picked up after being placed down.



 Comments   
Comment by Chilenderino [ 16/Sep/24 ]

Can confirm 24w37a

Comment by BugTracker [ 13/Apr/24 ]

Affects 1.20.5 pre-release 1.

Comment by 4ebugger [ 12/Apr/24 ]

If this get fixed, will turn all blocks into tile entities, will cause lag and making them can no longer be moved by pistons.

Comment by AMGAMES04 [ 13/Mar/24 ]

Can confirm in 24w10a

Comment by Brain81505 [ 09/Aug/23 ]

Can confirm in 23w32a

Comment by Brevort [ 14/Jun/23 ]

Affects 1.20.1.

Comment by batbrain55 [ 21/Feb/23 ]

Can confirm in 23w07a.

Comment by Brain81505 [ 01/Feb/23 ]

Can confirm in 23w06a

Comment by Brain81505 [ 25/Jan/23 ]

Can confirm in 23w04a

Comment by Brain81505 [ 18/Jan/23 ]

Can confirm in 23w03a

Comment by [Mod] Avoma [ 06/Aug/22 ]

Can confirm in 1.19.2.

Comment by [Mod] Avoma [ 28/Jul/22 ]

Can confirm in 1.19.1.

Comment by HubbiGamingTV [ 22/Jul/22 ]

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 

Comment by Dschinghis Khan [ 20/Jun/22 ]

Can confirm in 22w24a.

Comment by [Mod] Avoma [ 08/Jun/22 ]

Can confirm in 1.19.

Comment by [Mod] Avoma [ 02/Mar/22 ]

Can confirm in 1.18.2.

Comment by MMK21 [ 10/Dec/21 ]

Affects 1.18.1

Comment by user-f2760 (Inactive) [ 11/Sep/21 ]

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)

Comment by W_V [ 29/Aug/21 ]

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

Comment by Boas Bakker [ 29/Aug/21 ]

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

Comment by /dev/loop0 [ 26/Aug/21 ]

Because chests are block entities.

Comment by Leo Tucker [ 31/Jul/21 ]

why do chests keep there nbt data?

Comment by Leo Tucker [ 31/Jul/21 ]

What about servers

Comment by [Mod] Avoma [ 12/Jun/21 ]

Can confirm in 1.17.

Comment by [Mod] Avoma [ 30/Apr/21 ]

Can confirm in 21w17a.

Comment by [Mod] Avoma [ 19/Apr/21 ]

Can confirm in 21w15a.

Comment by [Mod] Avoma [ 12/Apr/21 ]

Can confirm in 21w14a.

Comment by [Mod] Avoma [ 29/Mar/21 ]

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

Comment by [Mod] Avoma [ 25/Feb/21 ]

Can confirm in 21w08b.

Comment by [Mod] Avoma [ 15/Feb/21 ]

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

Comment by [Mod] Avoma [ 12/Feb/21 ]

Can confirm in 21w06a.

Comment by [Mod] Avoma [ 04/Feb/21 ]

Can confirm in 21w05b.

Comment by [Mod] Avoma [ 03/Feb/21 ]

Can confirm in 21w05a.

Comment by [Mod] Avoma [ 21/Jan/21 ]

Can confirm in 21w03a.

Comment by Riley McConnell [ 23/Dec/20 ]

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.

Comment by kasamikona [ 23/Dec/20 ]

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.

Comment by W_V [ 23/Dec/20 ]

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

Comment by Xavier Jiang [ 22/Dec/20 ]

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

Comment by [Mod] Avoma [ 21/Dec/20 ]

Can confirm in 20w51a.

Comment by blablab [ 08/Dec/20 ]

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

Comment by [Mod] Avoma [ 02/Dec/20 ]

Can confirm in 20w49a.

Comment by [Mod] Avoma [ 25/Nov/20 ]

Can confirm in 20w48a.

Comment by K B [ 30/May/20 ]

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

Comment by Nicholas Ng [ 19/Apr/20 ]

Can confirm for 20w16a

Comment by W_V [ 06/Apr/20 ]

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

Comment by [Mod] violine1101 [ 11/Mar/20 ]

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

Comment by Andrew [ 27/Jan/15 ]

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)

Comment by kasamikona [ 14/Aug/14 ]

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?

Comment by WolfieMario [ 12/Jun/13 ]

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.

Comment by Daniel "Glampkoo" [ 11/Jun/13 ]

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

Comment by Daniel [ 17/Feb/13 ]

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

Comment by WolfieMario [ 26/Dec/12 ]

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.

Comment by Zuriki [ 25/Dec/12 ]

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.

Comment by WolfieMario [ 25/Dec/12 ]

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.

Comment by Zuriki [ 25/Dec/12 ]

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.

Comment by WolfieMario [ 24/Dec/12 ]

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.

Comment by Zuriki [ 24/Dec/12 ]

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

Comment by Nathan Huston [ 15/Nov/12 ]

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.

Comment by WolfieMario [ 26/Oct/12 ]

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.

Comment by Joseph Fowler [ 26/Oct/12 ]

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.

Comment by Jonathan Haas [ 26/Oct/12 ]

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.

Comment by Joseph Fowler [ 26/Oct/12 ]

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

Comment by Jonathan Haas [ 26/Oct/12 ]

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.

Comment by Joseph Fowler [ 26/Oct/12 ]

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.

Comment by WolfieMario [ 25/Oct/12 ]

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.

Comment by Joseph Fowler [ 25/Oct/12 ]

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

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

Comment by Tuna YASA [ 24/Oct/12 ]

OK, I find some bugs

Comment by Gravity [ 24/Oct/12 ]

Hi Tuna.

First of all, across your last few reports you've been very impatient and have left several comments demanding replies. We are not robots, instead most of us are volunteers here, so please do not comment on your own report or beg for replies, especially not after only a couple of minutes.

Second of all, while it's possible to rename dirt and other block objects, persistence of these names is not going to be added to Minecraft. If you mine dirt, it's going to be dirt, no matter what name you previously chose it to be.

Comment by [Mojang] Grum (Erik Broes) [ 24/Oct/12 ]

This will never happen. Blocks != items.

Comment by Tuna YASA [ 24/Oct/12 ]

tell me pleaseeee

Comment by Tuna YASA [ 24/Oct/12 ]

Please, Comment

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