ISRosillo14

The described issue has been fixed in 1.21.11 Pre-release 2, mentioned as a change. (please mark the report as Fixed instead of Won’t Fix)

@isXander The behaviour is still not the expected one, though.

I’d like to clarify that the bug MAY have impact in gameplay, but it depends on what behaviour the developers were intending for. (wheter if it has to check for “isWet” or not?)

Hey @tryashtar , take a look at this:

Coding error at net.minecraft.world.entity.Entity.resetPos() - Minecraft: Java Edition - Jira Service Management

• Was valid and got fixed.

Thanks for your patience.

As of 1.20.10, the “pressed” animation has returned but it is very bugged. It stays on that state even after you stop pressing on them, and they also show the animation when you mouse-hover them without clicking.

Fixing this caused MC-277218.

This has been "fixed" in 24w18a.

@BugTracker But that's just pure coincidental, for example, the video from the report of MC-180 also shows the bug of MC-193749 (and it's not considered a duplicate)

@EliteTracker This bug doesn't have anything to do with camera stuttering, that's only mentioned in the history of a related boat bug which indirectly affected this.

Can confirm in 24w10a.

Can confirm in 24w09a. I forgot to mention that the good way of fixing this, is by somehow pausing animations from the singleplayer world and continue ticking animations for the screen only.

Can confirm in 24w05a.

As of 20w05a the issue seems fixed. Probably related to the fix of MC-225170.

Can confirm in 23w51b.

Can confirm in 23w51b.

Can confirm in 1.20.4.

Introduced in 1.9 snapshot 15w44b, relates to MC-91715. Also can confirm in 1.20.4.

Can confirm in 1.20.2 and 1.20.3 Pre-release 2. Regarding the proposed fix by ~marcono1234, there's a problem which makes it unviable, as it creates way too many single particles, and each one is sent by the server to every player (client) near the egg, which definitely would lag the server.

So the rest of this comment will adress an alternate fix, which has been already tested on my modified client and seems to work fine without creating lag. Here it is:

The concept of this fix is to basically let server tell the client that it has to create various teleport particles from one position to another. For this we are going to take advantage of the LevelEvent feature, which consists of sending packet ClientBoundLevelEventPacket from server to client (so now we are reducing from hundreds of packets to a single one), but since not everything is perfect, I had to modify level event's integer "data" parameter to use a long number, since we want to store the destination position on the packet witout altering this feature's behaviour (this is why I'm not suggesting to add another BlockPos parameter to the packet, because otherwise it would break this feature for any other part of the game using it and would add more weight), so now we can use the got destination position's BlockPos.asLong() directly at BlockDragonEgg.teleport(BlockState, Level, BlockPos) and through "LevelEvent" the client will handle the teleport particles correctly at LevelRenderer.levelEvent(int, BlockPos, int).

Code attachment depicting the classes I changed (excluding all LevelEvent methods' changes to "data" parameter, from integer numbers to long ones). — From decompiled minecraft 1.19.3 by MCP Reborn using official mapping and my own parameter names.

package net.minecraft.world.level.block;

public class DragonEggBlock extends FallingBlock {
   //...

   private void teleport(BlockState thisState, Level level, BlockPos position) {
       if (level.isClientSide) {//no need to use this method in the client anymore, make it server-side only
           return;
       }

       WorldBorder worldborder = level.getWorldBorder();

       for (int tries = 0; tries < 1000; ++tries) {
           BlockPos destPos = position.offset(level.random.nextInt(16) - level.random.nextInt(16), level.random.nextInt(8) - level.random.nextInt(8), level.random.nextInt(16) - level.random.nextInt(16));

           if (level.getBlockState(destPos).isAir() && worldborder.isWithinBounds(destPos)) {
               level.setBlock(destPos, thisState, 2);
               level.removeBlock(position, false);
               level.levelEvent(1999, destPos, position.asLong());//send DRAGON_EGG_TELEPORT LevelEvent
               return;
           }
       }
   }

   //...
}

Also, in these examples I assigned "1999" as the id of this level event type I added (also present in net.minecraft.level.block.LevelEvent.DRAGON_EGG_TELEPORT).

package net.minecraft.client.renderer;

public class LevelRenderer implements ResourceManagerReloadListener, AutoCloseable {
   //...
   public void levelEvent(int p_234305_, BlockPos eventPos, long /* instead of int */ data) {
      RandomSource randomsource = this.level.random;
      int dataAsInt = (int)data; //compatibilize with other level events
      switch (p_234305_) {
         //...
         case 1999: /* using this number for DRAGON_EGG_TELEPORT event */
             BlockPos destPos = BlockPos.of(data);//this is why we need long number

             for (int j = 0; j < 128; ++j) {//this is moved from DragonEggBlock.teleport(..)
                 double d0 = randomsource.nextDouble();
                 float f0 = (randomsource.nextFloat() - 0.5F) * 0.2F;
                 float f1 = (randomsource.nextFloat() - 0.5F) * 0.2F;
                 float f2 = (randomsource.nextFloat() - 0.5F) * 0.2F;
                 double d1 = Mth.lerp(d0, (double)destPos.getX(), (double)eventPos.getX()) + (randomsource.nextDouble() - 0.5D) + 0.5D;
                 double d2 = Mth.lerp(d0, (double)destPos.getY(), (double)eventPos.getY()) + randomsource.nextDouble() - 0.5D;
                 double d3 = Mth.lerp(d0, (double)destPos.getZ(), (double)eventPos.getZ()) + (randomsource.nextDouble() - 0.5D) + 0.5D;
                 this.level.addParticle(ParticleTypes.PORTAL, d1, d2, d3, (double)f0, (double)f1, (double)f2);
             }

             break;
          //...
      }
   }

   //...
}

In short, instead of creating the particles by the server like Marcono said, we are making the client create them to reduce packet usage, while also fixing this bug.

Can confirm in 1.20.3 Pre-release 2.

I think the best way of solving this problem is by fixing this the way I described before (that "easy" way) and marking MC-116696 as WAI, which makes a lot more sense since the advancements & statistics screens are considered to be pause screens, (and this bug has been re-opened, which inherently means that things aren't supposed to move in pause).

Can I request the ownership for this issue? Of course if user33 agrees first...

This issue also affects particle "minecraft:vibration", because it uses the same animation method as blocks. Video attached reproducing this issue in latest snapshot (23w44a).

The main reason (I think) Dinnerbone marked this issue as WAI is because the fix applied for MC-116696 directly contradicts the fix this bug needs, inside the code. What it's happening here is that the advancements screen is a menu that also pauses the game, so if this bug got fixed the easiest way (just readding the "if not paused" check to the TextureManager.tick() call on Minecraft.tick()), MC-116696 would reappear because AdvancementsScreen is a "pausing screen".

//class Minecraft.java
   public void tick() {
      if (this.rightClickDelay > 0) {
         --this.rightClickDelay;
      }

      this.profiler.push("gui");
      this.chatListener.tick();
      this.gui.tick(this.pause);
      this.profiler.pop();
      this.gameRenderer.pick(1.0F);
      this.tutorial.onLookAt(this.level, this.hitResult);
      this.profiler.push("gameMode");

      if (!this.pause && this.level != null) {
         this.gameMode.tick();
      }

      this.profiler.popPush("textures");

      if (this.level != null) {//what should be here is " && !this.pause" but can't really do it because of MC-116696
         this.textureManager.tick();
      }
      //...
   }

Yeah, you would say that by simply adding a "is advancements screen", the two bugs would get fixed, but no, instead, textures would get animated when you have the advancements screen open. Making the advancements screen a non-pausing screen wouldn't be a good option either, because that wouldn't make much sense since this is very often opened from the pause menu. Also I forgot to mention that MC-116696 also affected the statistics screen.