| Type: | Bug | ||
| Reporter: | [Mod] Sonicwave | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 89 |
| Labels: | 12w18a, dragon_egg | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Category: |
Particles
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Mojang Priority: | Low | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Area: | Gameplay | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
The BugWhen 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
Observed BehaviorParticles produced from a dragon egg upon interacting with it don't point in the direction of where the egg was teleported to. Expected BehaviorParticles produced from a dragon egg upon interacting with it would point in the direction of where the egg was teleported to. Code AnalysisCode analysis by marcono1234 can be found in this comment, and code analysis by ISRosillo14 can be found in this comment. |
| Comments |
| Comment by Ismael Rosillo [ 24/Nov/23 ] |
|
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. |
| Comment by Brain81505 [ 11/Feb/23 ] |
|
Can confirm in 23w06a |
| Comment by Brain81505 [ 01/Feb/23 ] |
|
Can confirm in 23w05a |
| Comment by [Mod] Avoma [ 06/Aug/22 ] |
|
Can confirm in 1.19.2. |
| Comment by [Mod] Avoma [ 28/Jul/22 ] |
|
Can confirm in 1.19.1. |
| Comment by [Mod] Avoma [ 08/Jun/22 ] |
|
Can confirm in 1.19. |
| Comment by RXB3000 [ 21/May/22 ] |
|
Can confirm in 1.19 prerelease-1 |
| Comment by [Mod] Avoma [ 02/Mar/22 ] |
|
Can confirm in 1.18.2. |
| Comment by [Mod] Avoma [ 14/Dec/21 ] |
|
Can confirm in 1.18.1. |
| Comment by [Helper] clam lol [ 18/Nov/21 ] |
|
Affects 1.18-pre4. |
| Comment by [Mod] ampolive [ 10/Nov/21 ] |
|
Can confirm in 21w44a. |
| Comment by [Mod] ampolive [ 20/Oct/21 ] |
|
Can confirm in 21w42a. |
| Comment by [Mod] ampolive [ 12/Oct/21 ] |
|
Can confirm in 21w40a. |
| Comment by [Mod] Avoma [ 04/Oct/21 ] |
|
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:
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. |
| Comment by [Mod] ampolive [ 18/Sep/21 ] |
|
Can confirm in 21w37a. |
| Comment by [Mod] ampolive [ 03/Jul/21 ] |
|
Can confirm in 1.17.1 Release Candidate 1. |
| Comment by bugsbugsbugs [ 25/Mar/21 ] |
|
Attached a vidoe showing how it used to work in 1.2.5, MC-2157 How it used to work in 1.2.5.mp4 |
| Comment by [Mod] Avoma [ 04/Feb/21 ] |
|
Can confirm in 21w05b. |
| Comment by [Mod] Avoma [ 03/Feb/21 ] |
|
Can confirm in 21w05a. |
| Comment by [Mod] Avoma [ 25/Nov/20 ] |
|
Can confirm in 20w48a. |
| Comment by Conem [ 17/Jun/20 ] |
|
Confirmed in 1.16-pre7. |
| Comment by Conem [ 16/Jun/20 ] |
|
Confirmed in 1.16-pre6. |
| Comment by Conem [ 12/Jun/20 ] |
|
Confirmed in 1.16-pre5. |
| Comment by Conem [ 10/Jun/20 ] |
|
Confirmed in 1.16-pre3. |
| Comment by TheBoy358 [ 08/Nov/19 ] |
|
Confirmed in 19w45b. |
| Comment by [Helper] Jack McKalling [ 13/May/19 ] |
|
Confirmed for 1.14.1 |
| Comment by [Helper] Jack McKalling [ 09/May/19 ] |
|
Confirmed for 1.14.1 pre-2 |
| Comment by [Helper] Jack McKalling [ 07/May/19 ] |
|
Confirmed for 1.14.1 pre-1 |
| Comment by [Helper] Jack McKalling [ 23/Apr/19 ] |
|
Confirmed for 1.14 |
| Comment by [Helper] Jack McKalling [ 18/Apr/19 ] |
|
Confirmed for 1.14 pre-5 |
| Comment by [Helper] Jack McKalling [ 17/Apr/19 ] |
|
Confirmed for 1.14 pre-4 |
| Comment by [Helper] Jack McKalling [ 16/Apr/19 ] |
|
Confirmed for 1.14 pre-3 |
| Comment by [Helper] Jack McKalling [ 15/Apr/19 ] |
|
Confirmed for 1.14 pre-2 |
| Comment by [Helper] Jack McKalling [ 10/Apr/19 ] |
|
Confirmed for 1.14 pre-1 |
| Comment by [Helper] Jack McKalling [ 08/Apr/19 ] |
|
Confirmed for 19w14b |
| Comment by [Helper] Jack McKalling [ 03/Apr/19 ] |
|
Confirmed for 19w14a |
| Comment by [Helper] Jack McKalling [ 29/Mar/19 ] |
|
Confirmed for 19w13b |
| Comment by [Helper] Jack McKalling [ 27/Mar/19 ] |
|
Confirmed for 19w13a |
| Comment by [Helper] Jack McKalling [ 21/Mar/19 ] |
|
Confirmed for 19w12b |
| Comment by [Helper] Jack McKalling [ 20/Mar/19 ] |
|
Confirmed for 19w12a |
| Comment by [Helper] Jack McKalling [ 14/Mar/19 ] |
|
Confirmed for 19w11b |
| Comment by [Helper] Jack McKalling [ 13/Mar/19 ] |
|
Confirmed for 19w11a |
| Comment by [Helper] Jack McKalling [ 28/Feb/19 ] |
|
Confirmed for 19w09a |
| Comment by [Helper] Jack McKalling [ 13/Feb/19 ] |
|
Confirmed for 19w07a |
| Comment by [Helper] Jack McKalling [ 06/Feb/19 ] |
|
Confirmed for 19w06a |
| Comment by [Helper] Jack McKalling [ 30/Jan/19 ] |
|
Confirmed for 19w04b and 19w05a |
| Comment by [Helper] Jack McKalling [ 24/Jan/19 ] |
|
Comfirmed for 19w04a |
| Comment by [Helper] Jack McKalling [ 19/Jan/19 ] |
|
Confirmed for 19w03c |
| Comment by [Helper] Jack McKalling [ 17/Jan/19 ] |
|
Confirmed for 19w03b |
| Comment by [Helper] Jack McKalling [ 16/Jan/19 ] |
|
Confirmed for 19w03a |
| Comment by [Helper] Jack McKalling [ 09/Jan/19 ] |
|
Confirmed for 19w02a |
| Comment by [Helper] Jack McKalling [ 12/Dec/18 ] |
|
Confirmed for 18w50a |
| Comment by [Helper] Jack McKalling [ 05/Dec/18 ] |
|
Confirmed for 18w49a |
| Comment by Kraif [ 24/Aug/18 ] |
|
Confirmed for 1.13.1. |
| Comment by Paul Rozhkov [ 17/Jul/18 ] |
|
can reproduce in 1.13-pre10 |
| Comment by Paul Rozhkov [ 14/Jul/18 ] |
|
can reproduce in 1.13-pre8 |
| Comment by Paul Rozhkov [ 10/Jul/18 ] |
|
can reproduce in 1.13-pre7 |
| Comment by Paul Rozhkov [ 04/Jul/18 ] |
|
can reproduce in 1.13-pre6 |
| Comment by Matthew [ 28/Jun/18 ] |
|
Can confirm in 1.13-pre5. Please keep the affected versions up-to-date. |
| Comment by Fabian Röling [ 26/Oct/17 ] |
|
After receiving six mails because of this, I want to make it clear: Hazmi35, 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. |
| Comment by user-f2760 (Inactive) [ 26/Oct/17 ] |
|
Is already marked as affected. |
| Comment by hzmi [ 26/Oct/17 ] |
|
Confirmed for 1.12.2 |
| Comment by [Mod] Michael Wobst [ 14/Jun/17 ] |
|
Ticket is yours now, ericz1 |
| Comment by [Mod] Sonicwave [ 14/Jun/17 ] |
|
Confirmed for 1.12. |
| Comment by user33 [ 31/May/17 ] |
|
Confirmed for 1.12-pre6 |
| Comment by user33 [ 01/May/17 ] |
|
Confirmed for 17w17b |
| Comment by Ben Mintz [ 18/Aug/16 ] |
|
Yes I know. If I had seen your comment earlier I wouldn't have also said confirmed for "16w32b". |
| Comment by user-f2760 (Inactive) [ 17/Aug/16 ] |
Also marked as affected... |
| Comment by Ben Mintz [ 17/Aug/16 ] |
|
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? |
| Comment by user-f2760 (Inactive) [ 17/Aug/16 ] |
|
Is already marked as affected... |
| Comment by Ben Mintz [ 17/Aug/16 ] |
|
Confirmed for 1.10.2 |
| Comment by Marcono1234 [ 12/Mar/16 ] |
|
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 |
| Comment by Marcono1234 [ 12/Mar/16 ] |
|
Confirmed for
|
| Comment by Esophose [ 03/Dec/15 ] |
|
Confirmed for 15w49b |
| Comment by [Mod] Sonicwave [ 01/Aug/15 ] |
|
|
| Comment by [Mod] Sonicwave [ 21/Nov/14 ] |
|
Confirmed for 1.8.1-pre5. |
| Comment by [Mod] Sonicwave [ 21/Oct/14 ] |
|
Confirmed for 1.8.1-pre2. |
| Comment by [Mod] Sonicwave [ 03/Oct/14 ] |
|
Confirmed in 1.8. |
| Comment by Galaxy_2Alex [ 21/Aug/14 ] |
|
Confirmed for 14w32d |
| Comment by Fluffy89502 [ 26/Jan/14 ] |
|
Confirmed in 1.7.4 |
| Comment by [Mod] CubeTheThird [ 26/Sep/13 ] |
|
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. |
| Comment by Mustek [ 05/Feb/13 ] |
|
Confirmed in 13w05b |
| Comment by Chalmes (Jon) [ 04/Nov/12 ] |
|
After hitting the egg directly underneath me, the attached screenshot was the result. |
| Comment by Chalmes (Jon) [ 04/Nov/12 ] |
|
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. |
| Comment by [Mod] CubeTheThird [ 04/Nov/12 ] |
|
Please clarify. What exactly is the bug here? |