mojira.dev
MC-216362

Jukeboxes that have been placed don't stack with jukeboxes that have not been placed

The bug

Jukeboxes that have been placed, broken, and then picked up again will not stack with jukeboxes that have never been placed.

Expected behaviour

Jukeboxes all stack.

How to reproduce

  1. Get 2 jukeboxes

  2. Place one of them on the ground

  3. In survival mode, break it with the hand and pick it up
    ❌ The broken jukebox creates a new stack

Related issues

Attachments

Comments

migrated
[media][media][media]
FireSkorpion

can confirm for non-optifine 1.16.5  

[media]

@Adan Chappuis Ideally remove the 'optifine' bit

Jack McKalling

I've tested this in vanilla single player in both 1.16.5 as well as the latest 21w07a. It still happens exactly as described, although it apparently has nothing to do with optifine so I removed that part.

migrated

In the setPlacedBy method of net.minecraft.world.level.block.JukeboxBlock (mojang mappings),

an empty compound tag is created on the item stack that is used to place the jukebox.

Avoma

Can confirm in 21w08a.

Avoma

Can confirm in 21w13a.

Avoma

Can confirm in 21w17a.

migrated

Can confirm in 1.17 Pre Release 2

migrated

Can confirm in 1.17-pre5

ampolive

Can confirm in 21w37a.

migrated

Cannot replicate in 21w37a and further versions.

PR0CESS

This has been fixed in 1.18

ampolive

Can confirm that this issue has been fixed.

pokechu22

This issue seems to have been introduced in 1.16-pre5 when MC-180867 was fixed. That version added the following code to JukeboxBlock.setPlacedBy (as noted by @unknown):

CompoundTag tag = stack.getOrCreateTag();
if (tag.contains("BlockEntityTag")) {
  CompoundTag tag2 = tag.getCompound("BlockEntityTag");
  if (tag.contains("RecordItem")) {
    // Update has_record state
  }
}

21w37a replaced that code with this:

CompoundTag tag = item.getBlockEntityData(stack);
// above is equivalent to stack.getTagElement("BlockEntityTag"), which doesn't create tag if there is no tag
if (tag != null && tag.contains("RecordItem")) {
  // Update has_record state
}

I also am able to reproduce the issue in 1.17.1 but not in 21w37a, so I'm marking it as fixed. (MC-180867 also remains fixed.)

aceplante

It doesnt even contain any extra nbt data, so Luckily this seems to be solved by throwing the items on the ground, then they can both be picked up and stacked as normal

migrated

(Unassigned)

Confirmed

Normal

Block states

1.16.5, 21w07a, 21w08a, 21w08b, 21w10a, ..., 1.17 Pre-release 5, 1.17 Release Candidate 2, 1.17, 1.17.1, 21w37a

21w37a

Retrieved