clove
- clovee
- JIRAUSER458738
- Europe/Stockholm
- Yes
- No
![[Mod] redstonehelper](../../../data/avatars/users/10122.svg){kind=small}
The bug
Some items which can be used to place the respective entity in the world do not apply the custom item name to the entity. This means once you destroy the entity and pick it up as item it will not have a custom name anymore.
This was fixed for:
minecartsarmor stands(23w03a)boatchest_boat(MC-249408)ender_pearleye_of_enderfirework_rocket
Affected items / entities
- ender_crystal
- fishing_bobber (from fishing rod)
- item_frame / glow_item_frame
- leash_knot
- painting
Code analysis
Code analysis by clove can be found in this comment.
The bug
The NBT tag of mobs DeathLootTableSeed can only affect the loot when the mob actually dies. However when you use "/loot kill" command on the mob, the loot is still random instead of fixed.
How to reproduce
- Summon a sheep with a certain loot table seed:
/summon minecraft:sheep ~ ~ ~ {DeathLootTable:"minecraft:entities/sheep",DeathLootTableSeed:123} - Kill it:
/kill @e[sort=nearest,type=sheep,limit=1]
→ You will get exactly 2 piece of mutton.
- Summon the sheep again and use /loot command on it:
/loot give @s kill @e[sort=nearest,type=sheep,limit=1]
→ You know how many mutton you get
Code Analysis
Code analysis by clove can be found in this comment
Since its effects still apply above y=255 and below y=0, it should render there as well.
Code analysis
Code analysis by clove can be found in this comment.
Happening for me in 1.16.2 pre-2 but not 1.16.1.
Pretty sure this is a duplicate of
MC-97087.Happening for me with endermen and wolves but not bees, iron golems and polar bears.
Hi! This project is for Minecraft: Java Edition bug reports, and this is a bedrock edition problem. (Additionally, I'm pretty sure this would fall under tech support which is not something that the bug tracker can help you with)
Can confirm for 1.16.2
Can confirm.
This also happens when commands aren't inside /execute. (Happens to all commands)
Duplicate of
MC-137783Editing NBT data during the lifetime of an entity is not supported. Also pretty sure this is a duplicate of
MC-93559which is marked as Won't Fix.Can confirm.
Can reproduce on 1.16.2-pre1 but not 1.16.2.
This project is for Minecraft: Java Edition reports. For Minecraft (Bedrock) please use the MCPE project. Also, this sounds like a technical support issue which is unfortunately not something the bug tracker can help with.
Can't reproduce in 1.16.2.
Duplicate of MC-88181.
Confirmed for 1.16.2
Can confirm for 1.16.2
Can confirm.
Can confirm for 1.16.2
Can confirm in 1.16.2
Can confirm
Can confirm for 1.16.2
Could this be quasiconnectivity?
The inventory being duplicated is WAI – singleplayer save data is stored in the world and is not user-specific. (IIRC)
Can confirm for release 1.16.2
Can confirm for release 1.16.2
Can confirm for release 1.16.2
Can confirm for 1.16.2
Can confirm for 1.16.2
Can confirm for 1.16.2
Can confirm for 1.16.2
Can confirm for 1.16.2
Can confirm for 1.16.2
Multiplayer inventories are stored in the server files in the playerdata folder if I remember correctly. However, in singleplayer, the items are stored as part of the world and are shared between users (you'll see this effect if you ever opened up a world you got from someone else and started with items). I'm not sure about LAN worlds, however.
Can confirm for 1.16.3rc1
Can confirm in 1.16.3rc1
Can confirm for 1.16.3rc1
Can confirm for 1.16.3rc1
Can confirm for 1.16.3rc1
Can confirm for 1.16.3rc1
Can confirm for 1.16.3rc1
Can confirm for 1.16.3rc1
Can confirm for 1.16.3rc1+
Can confirm for 1.16.3rc1
Tried to do a code analysis, if I messed up please tell me
The following was decompiled using https://github.com/hube12/DecompilerMC and CFR.
If we look at net.minecraft.server.commands.LootCommand, the method for /loot kill is declared on line 252.
private static int dropKillLoot(CommandContext<CommandSourceStack> commandContext, Entity entity, DropConsumer dropConsumer) throws CommandSyntaxException {
if (!(entity instanceof LivingEntity)) {
throw ERROR_NO_LOOT_TABLE.create((Object)entity.getDisplayName());
}
ResourceLocation resourceLocation = ((LivingEntity)entity).getLootTable();
CommandSourceStack commandSourceStack = (CommandSourceStack)commandContext.getSource();
LootContext.Builder builder = new LootContext.Builder(commandSourceStack.getLevel());
Entity entity2 = commandSourceStack.getEntity();
if (entity2 instanceof Player) {
builder.withParameter(LootContextParams.LAST_DAMAGE_PLAYER, (Player)entity2);
}
builder.withParameter(LootContextParams.DAMAGE_SOURCE, DamageSource.MAGIC);
builder.withOptionalParameter(LootContextParams.DIRECT_KILLER_ENTITY, entity2);
builder.withOptionalParameter(LootContextParams.KILLER_ENTITY, entity2);
builder.withParameter(LootContextParams.THIS_ENTITY, entity);
builder.withParameter(LootContextParams.ORIGIN, commandSourceStack.getPosition());
LootTable lootTable = commandSourceStack.getServer().getLootTables().get(resourceLocation);
List<ItemStack> list2 = lootTable.getRandomItems(builder.create(LootContextParamSets.ENTITY));
return dropConsumer.accept(commandContext, list2, list -> LootCommand.callback(commandSourceStack, list, resourceLocation));
}
When it adds parameters to the LootContext.Builder (the bolded part), it does not set the random seed (this is done by calling LootContext.Builder.withOptionalRandomSeed). Therefore, the seed is variable.
However, in net.minecraft.world.entity.Mob (this may not be the correct class, but even if this is in a different file the problem and solution are still accurate) on line 463, there's this method:
@Override
protected LootContext.Builder createLootContext(boolean bl, DamageSource damageSource) {
return super.createLootContext(bl, damageSource).withOptionalRandomSeed(this.lootTableSeed, this.random);
}
As you can see, it creates a LootContext.Builder with an optional random seed of this.lootTableSeed (which is the NBT tag).
The solution would be to add an additional builder.withOptionalRandomSeed(this.lootTableSeed) in dropKillLoot()
This report is invalid because your game and server are modified.
Code analysis, if I missed something please tell me
The following is based on Minecraft 1.16.2 decompiled using the Yarn mappings and CFR.
In net.minecraft.client.render.WorldRenderer, the worldborder is rendered using the method renderWorldBorder.
The sides are rendering using 4 calls to a method.
this.method_22978(lv, f, g, h, lv2.getBoundEast(), 256, t, m + s, m + 0.0f);
this.method_22978(lv, f, g, h, lv2.getBoundEast(), 256, t + u, m + v + s, m + 0.0f);
this.method_22978(lv, f, g, h, lv2.getBoundEast(), 0, t + u, m + v + s, m + 128.0f);
this.method_22978(lv, f, g, h, lv2.getBoundEast(), 0, t, m + s, m + 128.0f);i
As you can see, it's hardcoded to use 256 and 0 for height. This could be fixed by changing those numbers to something like camera.getBlockPos().getY() - [distance] and + [distance].
(There may be a limitation in BufferBuilder preventing it from rendering under 0 and above 256)
The reason this happens for the majority of entities is that the calls to drop the items are just for the item name, and don't store NBT data.
This could be fixed by instead of just spawning in a blank item this.dropItem(Items.PAINTING);, the game also added the CustomName as NBT.
An example of this occurring can be found below:
The following is just for the Boat item and was decompiled using the Yarn mappings and CFR.
In net.minecraft.entity.vehicle.BoatEntity, the condition for the boat to break is declared.
As you can see, the Boat item is dropped using a call to this.dropItem. However, this.asItem does not store the CustomName or any NBT at all, it's just a switch to determine the type of item.
The method is seen below.
This could be fixed by changing the item to add in the CustomName NBT into its display.Name nbt.