Particles emitted from dragon egg when teleporting are not pointing in the correct direction

Please clarify. What exactly is the bug here?

When you hit a placed dragons egg and it teleports, the particles emitted often do not lead in the direction the egg moved. Nor away from. In fact, it seems a little inconsistent overall, and it would be good to have them pointing in the direction of travel.

After hitting the egg directly underneath me, the attached screenshot was the result.

Confirmed in 13w05b

Is this still a concern in the current Minecraft version 1.6.4 / Launcher version 1.2.5 ? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Confirmed in 1.7.4

Confirmed for 14w32d

Confirmed in 1.8.

Confirmed for 1.8.1-pre2.

Confirmed for 1.8.1-pre5.

MC-84535 confirms for 15w31c.

Confirmed for 15w49b

Confirmed for

• 1.9.1-pre3

Please link to this comment in the description

The following is based on decompiled version of Minecraft 1.9 using MCP 9.24 beta. All method and class names are the names used in the decompiled version.

The reason why this happens is probably the fix of MC-160. That bug probably occurred due to the problem described in MC-10369. I assume at this point the method creating the particles was changed to create the particles client side only. The problem is that the net.minecraft.block.BlockDragonEgg.teleport(World, BlockPos) method which is responsible for this is called by client and server. The client uses it for creating the particles, the server for setting the dragon egg. Both call the method java.util.Random.nextInt(int) which returns different coordinates for the client and the server.
This could be solved by having the server creating the particles.

Confirmed for 1.10.2

Is already marked as affected...

Confirmed for 16w32b

EDIT: oh lol i didn't see your comment until after i said confirmed for 16w32b

I wonder if there are plans to fix this for 1.11? 😃

Affects Version/s: ......Minecraft 1.10.2, Minecraft 16w32b

Also marked as affected...

Yes I know. If I had seen your comment earlier I wouldn't have also said confirmed for "16w32b".

Confirmed for 17w17b

Confirmed for 1.12-pre6

Confirmed for 1.12.

Ticket is yours now, @unknown

Confirmed for 1.12.2

Is already marked as affected.

After receiving six mails because of this, I want to make it clear: @unknown, please check the affected version list at the top of the report before submitting such a comment, you're sending multiple mails with each of those comments, in total about 100 mails were just caused by you and FVBico. Even though it might look like it, the comments are not the place to keep track of the versions.

Can confirm in 1.13-pre5.

Please keep the affected versions up-to-date. 

can reproduce in 1.13-pre6

can reproduce in 1.13-pre7

can reproduce in 1.13-pre8

can reproduce in 1.13-pre10

Confirmed for 1.13.1.

Confirmed for 18w49a

Confirmed for 18w50a

Confirmed for 19w02a

Confirmed for 19w03a

Confirmed for 19w03b

Confirmed for 19w03c

Comfirmed for 19w04a

Confirmed for 19w04b and 19w05a

Confirmed for 19w06a

Confirmed for 19w07a

Confirmed for 19w09a

Confirmed for 19w11a

Confirmed for 19w11b

Confirmed for 19w12a

Confirmed for 19w12b

Confirmed for 19w13a

Confirmed for 19w13b

Confirmed for 19w14a

Confirmed for 19w14b

Confirmed for 1.14 pre-1

Confirmed for 1.14 pre-2

Confirmed for 1.14 pre-3

Confirmed for 1.14 pre-4

Confirmed for 1.14 pre-5

Confirmed for 1.14

Confirmed for 1.14.1 pre-1

Confirmed for 1.14.1 pre-2

Confirmed for 1.14.1

Confirmed in 19w45b.

Confirmed in 1.16-pre3.

Confirmed in 1.16-pre5.

Confirmed in 1.16-pre6.

Confirmed in 1.16-pre7.

Can confirm in 20w48a.

Can confirm in 21w05a.

Can confirm in 21w05b.

Attached a vidoe showing how it used to work in 1.2.5,

Can confirm in 1.17.1 Release Candidate 1.

Can confirm in 21w37a.

I am able to confirm this behavior in 21w39a. Here are some extra details regarding this issue.

The Bug:

Particles produced from a dragon egg upon interacting with it don't point in the direction of where the egg was teleported to.

Steps to Reproduce:

• Give yourself a dragon egg and place it down.

/give @s minecraft:dragon_egg

• Interact with the dragon egg, (right-click by default) to make it teleport.

• Take note of the particles produced upon doing this and what direction they're pointing in.

• Locate where the dragon egg is and check whether the particles pointed in the correct direction.

Observed Behavior:

Particles produced from a dragon egg upon interacting with it don't point in the direction of where the egg was teleported to.

Expected Behavior:

Particles produced from a dragon egg upon interacting with it would point in the direction of where the egg was teleported to.

Can confirm in 21w40a.

Can confirm in 21w42a.

Can confirm in 21w44a.

Affects 1.18-pre4.

Can confirm in 1.18.1.

Can confirm in 1.18.2.

Can confirm in 1.19 prerelease-1

Can confirm in 1.19.

Can confirm in 1.19.1.

Can confirm in 1.19.2.

Can confirm in 23w05a

Can confirm in 23w06a

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.