mojira.dev
MC-2157

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

The Bug

When you cause a dragon egg to teleport (such as by clicking on it), the teleportation particles point in a random direction and not to the actual location of the dragon egg.

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.

Code Analysis

Code analysis by @unknown can be found in this comment, and code analysis by @unknown can be found in this comment.

Linked issues

Attachments

Comments

CubeTheThird

Please clarify. What exactly is the bug here?

Chalmes (Jon)

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.

Chalmes (Jon)

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

Mustek

Confirmed in 13w05b

CubeTheThird

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.

Fluffy89502

Confirmed in 1.7.4

galaxy_2alex

Confirmed for 14w32d

Sonicwave

Confirmed in 1.8.

Sonicwave

Confirmed for 1.8.1-pre2.

Sonicwave

Confirmed for 1.8.1-pre5.

Sonicwave

MC-84535 confirms for 15w31c.

Esophose

Confirmed for 15w49b

marcono1234

Confirmed for

  • 1.9.1-pre3

marcono1234

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.

Ben Mintz

Confirmed for 1.10.2

user-f2760

Is already marked as affected...

Ben Mintz

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? 😃

user-f2760

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

Also marked as affected...

Ben Mintz

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

JUE13

Confirmed for 17w17b

JUE13

Confirmed for 1.12-pre6

Sonicwave

Confirmed for 1.12.

wobst.michael

Ticket is yours now, @unknown

hzmi

Confirmed for 1.12.2

user-f2760

Is already marked as affected.

FaRo1

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.

qwerty23495

Can confirm in 1.13-pre5.

Please keep the affected versions up-to-date. 

Gravinser

can reproduce in 1.13-pre6

Gravinser

can reproduce in 1.13-pre7

Gravinser

can reproduce in 1.13-pre8

Gravinser

can reproduce in 1.13-pre10

Kraif

Confirmed for 1.13.1.

Jack McKalling

Confirmed for 18w49a

Jack McKalling

Confirmed for 18w50a

Jack McKalling

Confirmed for 19w02a

Jack McKalling

Confirmed for 19w03a

Jack McKalling

Confirmed for 19w03b

Jack McKalling

Confirmed for 19w03c

Jack McKalling

Comfirmed for 19w04a

Jack McKalling

Confirmed for 19w04b and 19w05a

Jack McKalling

Confirmed for 19w06a

Jack McKalling

Confirmed for 19w07a

Jack McKalling

Confirmed for 19w09a

Jack McKalling

Confirmed for 19w11a

Jack McKalling

Confirmed for 19w11b

Jack McKalling

Confirmed for 19w12a

Jack McKalling

Confirmed for 19w12b

Jack McKalling

Confirmed for 19w13a

Jack McKalling

Confirmed for 19w13b

Jack McKalling

Confirmed for 19w14a

Jack McKalling

Confirmed for 19w14b

Jack McKalling

Confirmed for 1.14 pre-1

Jack McKalling

Confirmed for 1.14 pre-2

Jack McKalling

Confirmed for 1.14 pre-3

Jack McKalling

Confirmed for 1.14 pre-4

Jack McKalling

Confirmed for 1.14 pre-5

Jack McKalling

Confirmed for 1.14

Jack McKalling

Confirmed for 1.14.1 pre-1

Jack McKalling

Confirmed for 1.14.1 pre-2

Jack McKalling

Confirmed for 1.14.1

TheBoy358

Confirmed in 19w45b.

Conem

Confirmed in 1.16-pre3.

Conem

Confirmed in 1.16-pre5.

Conem

Confirmed in 1.16-pre6.

Conem

Confirmed in 1.16-pre7.

Avoma

Can confirm in 20w48a.

Avoma

Can confirm in 21w05a.

Avoma

Can confirm in 21w05b.

bugsbugsbugs

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

[media]

ampolive

Can confirm in 1.17.1 Release Candidate 1.

ampolive

Can confirm in 21w37a.

Avoma

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.

ampolive

Can confirm in 21w40a.

ampolive

Can confirm in 21w42a.

ampolive

Can confirm in 21w44a.

clamlol

Affects 1.18-pre4.

Avoma

Can confirm in 1.18.1.

Avoma

Can confirm in 1.18.2.

RXB3000

Can confirm in 1.19 prerelease-1

Avoma

Can confirm in 1.19.

Avoma

Can confirm in 1.19.1.

Avoma

Can confirm in 1.19.2.

Brain81505

Can confirm in 23w05a

Brain81505

Can confirm in 23w06a

ISRosillo14

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.

Jose Angel Guzman Moreno

Sonicwave

(Unassigned)

Confirmed

Gameplay

Low

Particles

12w18a, dragon_egg

Minecraft 1.4.2, Minecraft 1.4.7, Snapshot 13w05b, Minecraft 1.5, Minecraft 1.7.4, ..., 24w44a, 1.21.4 Pre-Release 1, 1.21.4, 25w08a, 1.21.6 Pre-Release 1

Retrieved