"Entering the Nether" and "Entering the End" messages haven't appeared since 1.3
Linked Issues
is duplicated by1
- Unresolved
Greg Milson
tbh1138
- 88
- 37
- Confirmed
Low
- Platform
- UI
- end entering leaving loading-screen messages nether
1.4.7 - 24w35a
1.4.7 1.5.1 1.8.9 16w02a 16w04a 16w05b 16w06a 16w07a 16w07b 1.9-pre1 1.9-pre3 1.9-pre4 1.9 1.9.1-pre3 1.9.1 1.9.2 1.9.4 16w20a 1.10.2 16w32a 16w32b 16w35a 16w36a 1.11.2 17w06a 1.12.2 17w49a 17w49b 17w50a 1.13-pre1 1.13-pre2 1.13-pre4 1.13-pre5 1.13-pre6 1.13-pre7 1.13-pre8 1.13 18w30a 18w30b 18w31a 18w32a 1.13.1 1.13.2-pre1 1.13.2 18w48a 18w48b 18w49a 19w08b 19w09a 19w12b 19w13a 19w13b 1.14-pre2 1.14-pre3 1.14-pre4 1.14-pre5 1.14.2 1.14.3-pre3 1.14.4 19w40a 1.15.2 20w06a 20w08a 20w10a 20w11a 20w12a 20w13b 20w14a 20w18a 20w19a 20w20b 20w21a 20w22a 1.16-rc1 1.16 1.16.1 20w27a 20w28a 20w29a 20w30a 1.16.2-pre1 1.16.2 1.16.3-rc1 1.16.3 1.16.4 20w46a 20w51a 21w03a 1.16.5 21w05b 21w06a 21w07a 21w11a 21w14a 21w15a 21w17a 1.17 1.17.1-rc1 1.17.1 21w39a 21w40a 21w41a 1.18.1 1.18.2 22w15a 1.19 1.19.2 1.19.3 1.19.4 1.20-pre1 1.20-rc1 1.20 1.20.1 23w32a 23w33a 23w35a 1.20.2-pre2 1.20.2-pre3 1.20.2-rc2 1.20.2 23w42a 1.20.4 1.20.5-pre2 1.20.5-pre3 1.21 24w35a
Created Issue:
"Entering the Nether" and "Entering the End" messages haven't appeared since 1.3
Since 1.3, the "Entering the Nether" messages have stopped appearing onscreen. I realize that this is because single player is now a server, but the code for this is still in the game and the messages should either be completely removed or added alongside "Downloading Terrain".
Environment
All
duplicates
duplicates
duplicates
duplicates
relates to
is duplicated by
All
Since 1.3, the "Entering the Nether" messages have stopped appearing onscreen. I realize that this is because single player is now a server, but the code for this is still in the game and the messages should either be completely removed or added alongside "Downloading Terrain".
Since 1.3 , the Entering the Nether , and Entering the End messages have stopped appearing onscreen. I realize that this is because single player is now a server, but the code for this is still in the game and the messages should either be completely removed or added alongside "Downloading Terrain .
Since 1.3 , the Entering the Nether , and Entering the End
messages have stopped appearing onscreen.I realize that this is because single player is now a server, but the code for this is still in the game and the messages should either be completely removed or added alongside "Downloading Terrain .Since 1.3 , the Entering the Nether , and Entering the End messages have stopped appearing onscreen.
I realize that this is because single player is now a server, but the code for this is still in the game and the messages should either be completely removed or added alongside "Downloading Terrain .
Since 1.3 , the Entering the Nether , and Entering the End messages have stopped appearing onscreen.
I realize that this is because single player is now a server, but the code for this is still in the game and the messages should either be completely removed or added alongside"Downloading Terrain .Since 1.3 , the Entering the Nether , and Entering the End messages have stopped appearing onscreen.
I realize that this is because single player is now a server, but the code for this is still in the game and the messages should either be completely removed or added alongside the Downloading Terrain message.
Since 1.3 , the Entering the Nether , and Entering the End messages have stopped appearing onscreen.
I realize that this is because single player is now a server, but the code for this is still in the game and the messages should either be completely removed or added alongside the Downloading Terrain message.Whenever you enter a portal (Nether or end), normally a message that says "Entering the nether" and/or "Leaving the end" would appear and that teleport noise happens. It's been happening ever since singleplayer became multiplayer-managed in 1.3 .
What I expected to happen was...:
Hearing the teleport noise upon entering the portal.
Seeing the "Entering/Leaving the Nether/End" message
What actually happened was...:
Hearing the teleport noise after spawning in the nether.
Seeing "Downloading Terrain"
Steps to Reproduce
1. Create a nether portal or repair an end portal.
2. Enter the portal.
Whenever you enter a portal (Nether or end), normally a message that says "Entering the nether" and/or "Leaving the end" would appear
and that teleport noise happens. It's been happening ever since singleplayer became multiplayer-managed in 1.3.What I expected to happen was...:
![]()
Hearing theteleport noise upon entering the portal.
Seeing the "Entering/Leaving the Nether/End" message
What actually happened was...:
Hearing the teleport noise after
spawning in the nether.
Seeing "Downloading Terrain"
Steps to Reproduce
1. Create a nether portal or repair an end portal.
2. Enter the portal.Whenever you enter a portal (Nether or end), normally a message that says "Entering the nether" and/or "Leaving the end" would appear. It's been happening ever since singleplayer became multiplayer-managed in 1.3.
What I expected to happen was...:
Seeing the "Entering/Leaving the Nether/End" message
What actually happened was...:
Seeing "Downloading Terrain"
Steps to Reproduce
1. Create a nether portal or repair an end portal.
2. Enter the portal.
relates to
Whenever you enter a portal (Nether or end), normally a message that says "Entering the nether" and/or "Leaving the end" would appear. It's been happening ever since singleplayer became multiplayer-managed in 1.3.
What I expected to happen was...:
Seeing the "Entering/Leaving the Nether/End" message
What actually happened was...:
Seeing "Downloading Terrain"Steps to Reproduce
1. Create a nether portal or repair an end portal.
2. Enter the portal.
relates to
relates to
relates to
In 1.20.2 Pre-Release 3
Requesting ownership of this report as the reporter has only been active for a short period in 2020
Info for snapshot video creators
Here are two gifs which can be used to compare the two versions of the nether portal exit animation:
- Correct animation, used up until 1.2.5 (broke in 1.3.1 snapshot 12w18a) and is now used again as of 1.20-pre1: https://cdn.discordapp.com/attachments/399390463930400778/1097153888597069844/1point2point5-netherportal-anim.gif
- Incorrect animation, used from 12w34a to 23w18a and now fixed as of 1.20-pre1: https://cdn.discordapp.com/attachments/399390463930400778/1097156653687787692/1point19point4-netherportal-anim.gif
Note that the "Entering the Nether" message being absent in modern versions is a separate bug and is not yet fixed (MC-12789). The absence of inner faces in nether portal blocks is also a completely separate issue (MC-262512).
The bug
When you reach the other side of a nether portal the animation plays forever until you step out of it, even in creative. The animation is completely unnecessary here.
This bug first appeared in 1.4 snapshot 12w34a - versions 12w32a and earlier are completely unaffected (but many are affected by MC-217613).
I'd recommend fixing this and MC-217613 at the same time. A table explaining the expected behaviour can be found here: https://minecraft.fandom.com/wiki/Java_Edition_1.3.1/List_of_broken_features#Nether_portal_exit_animation
Refer to Ismael Rosillo's code analysis below for how these issues can be fixed (and why MC-217613 cannot be considered a duplicate of this issue).
How to reproduce
- Build a nether portal
- Enter it
- Stay in the exit portal
- The animation will start playing when it shouldn't
@Dlawso the Really Lucky Rabbit: Do you have a link to that issue? MC-12789 is resolved as a duplicate of this.
There is a separate issue! It's MC-12789. However, it's marked as a duplicate.
Edit: it seems you are already talking about it.
Closely related to, or caused by MC-12789
How to reproduce
- Enter a nether or end portal
→ See that a "Joining world" message is shown, even though you've already joined the world.
Like with MC-12789, this message ended up going missing with the whole client-server split in 12w18a.
As far as I'm aware the game still does save when the pause menu is brought up.
This comment is an extensive bug (and code) analysis of the fifth oldest persisting issue, along with a working and fully tested workaround (fix), so this comment will be split in different categories.
What @Connor Steppie Meant with MC-217613
Then, we have MC-217613 which indeed is (and it's not) a duplicate of this, depending on the point of view; Connor Steppie means that MC-217613 is the bug that refers to the lack of a slow-to-stop animation for the portal (it happened for the first time in 12w18a), while MC-180 refers to the visual "re-trigger" of the portal (it happenned for the first time in 12w34a). It's like these two bugs have been "stacked" or that they are "sister bugs", because they represent a very similar issue.
Code Analysis
Here, a bit of history of the code that worked, using Mojang's mapping names for this analysis:
- 1. Prior to 12w18a, it only worked on singleplayer, as the whole world was client. This is because the method we now call LocalPlayer.handleNetherPortalClient() (was part of aiStep() back then) handled the whole teleportation and then used the "distortion fade out" behaviour using field LocalPlayer.portalTime. The code below is a recreation of the sourcecode present in 12w17a, using mojang names and my own ones.
public class LocalPlayer extends Player { ... public void aiStep() { ... this.oPortalTime = this.portalTime; if (this.isInsidePortal) { if (!this.level.isClientSide && this.vehicle != null) { this.startRiding((Entity)null); } if (this.minecraft.screen != null) { this.minecraft.setScreen((Screen)null); } if (this.portalTime == 0.0F) { this.minecraft.soundManager.play("portal.trigger", 1.0F, this.random.nextFloat() * 0.4F + 0.8F); } this.portalTime += 0.0125F; //START OF CODE REMOVED IN 12w18a if (this.portalTime >= 1.0F) { this.portalTime = 1.0F; if (!this.level.isClientSide) { this.portalCooldown = 10; this.minecraft.soundManager.play("portal.travel", 1.0F, this.random.nextFloat() * 0.4F + 0.8F); byte newDimension = 0; if (this.dimension == -1) { newDimension = 0; } else { newDimension = -1; } this.minecraft.changeDimension(newDimension); this.takeAchievement(Achievements.portal); } } //END OF REMOVED CODE this.isInsidePortal = false; } else if (this.hasEffect(MobEffects.CONFUSION) && this.getEffect(MobEffects.CONFUSION).getDuration() > 60) { this.portalTime += 0.006666667F; if (this.portalTime > 1.0F) { this.portalTime = 1.0F; } } else { if (this.portalTime > 0.0F) { this.portalTime -= 0.05F; } if (this.portalTime < 0.0F) { this.portalTime = 0.0F; } } if (this.portalCooldown > 0) {//old equivalent to Entity.processPortalCooldown() this.portalCooldown--; } ... } ... }
- 2. After the changes made in 12w18a, the code described above was completely removed without adding a replacement, causing the unwanted behavior described in
MC-217613. - 3. In 12w34a, the way nether portals were handled by entities was changed internally, causing the actual behavior where the animation plays forever.
Note in the code that method this.minecraft.changeDimension(newDimension) was also removed from Minecraft.java and also it was forgotten to be re-added for the client listener, causing MC-12789.
Workaround and Fix
After the client-server singleplayer split up, the game switched to fully use the network system, and the source code described in history would not be able to just be copied and pasted, however, it's still useful for reference.
A possible way to fix this is to let the client know when a dimension change was caused by a nether portal to set the proper animation.
But first, we are going to head to LocalPlayer.java and add a new method (named justPostalTraveled() in this example), that will prevent the player to enter to the in-portal state, and set the Animation/Portal Effect at 100%. This will make the player think it's just exiting a portal and will decrease the Animation/Portal Effect at every aiStep()->handleNetherPortalClient() (This would also fix MC-193749). Now there's a problem with the animation effect: the animation starts before the Downloading Terrain screen is gone, causing the animation to be gone at the time or shortly after the game is rendering the world. To fix this, we are gonna make handleNetherPortalClient() know when it should progress the animation using a check. The end result is shown here in the code:
public class LocalPlayer extends AbstractClientPlayer { ... private void handleNetherPortalClient() { this.oPortalTime = this.portalTime; boolean shouldStatusProgress = !(this.minecraft.screen instanceof ReceivingLevelScreen); if (this.isInsidePortal) { if (this.minecraft.screen != null && !this.minecraft.screen.isPauseScreen() && !(this.minecraft.screen instanceof DeathScreen) && shouldStatusProgress) { if (this.minecraft.screen instanceof AbstractContainerScreen) { this.closeContainer(); } this.minecraft.setScreen((Screen)null); } if (this.portalTime == 0.0F) { this.minecraft.getSoundManager().play(SimpleSoundInstance.forLocalAmbience(SoundEvents.PORTAL_TRIGGER, this.random.nextFloat() * 0.4F + 0.8F, 0.25F)); } this.portalTime += 0.0125F; this.isInsidePortal = false; } else if (this.hasEffect(MobEffects.CONFUSION) && this.getEffect(MobEffects.CONFUSION).getDuration() > 60) { this.portalTime += 0.006666667F; } else if (shouldStatusProgress) { if (this.portalTime > 0.0F) { this.portalTime -= 0.05F; } } this.portalTime = Mth.clamp(this.portalTime, 0.0F, 1.0F); if (shouldStatusProgress) { this.processPortalCooldown(); } } public void justPortalTraveled() { this.isInsidePortal = false; this.oPortalTime = this.portalTime = 1.0F; this.setPortalCooldown(); } ... }
In other hand, we need to use this new method somewhere, and returning to the second paragraph, we'll make the client know when the player used a portal. I added a condition at the packet ClientboundRespawnPacket.java and I called it boolean fromPortal. It will also be read and written to the packet.
The change is quite obvious so I will not show the end result for that. Instead we are going to make this fix fully efective. At the ClientPacketListener.java at method handleRespawn(), after the player is being initialized and "adjusted", let's check whether if the player came from a portal (using the previously added fromPortal field) to call for justPortalTraveled():
public class ClientPacketListener implements TickablePacketListener, ClientGamePacketListener { ... public void handleRespawn(ClientboundRespawnPacket p_105066_) { ... localplayer1.resetPos(); localplayer1.setServerBrand(s); this.level.addPlayer(i, localplayer1); localplayer1.setYRot(-180.0F); localplayer1.input = new KeyboardInput(this.minecraft.options); this.minecraft.gameMode.adjustPlayer(localplayer1); localplayer1.setReducedDebugInfo(localplayer.isReducedDebugInfo()); localplayer1.setShowDeathScreen(localplayer.shouldShowDeathScreen()); localplayer1.setLastDeathLocation(p_105066_.getLastDeathLocation()); if (packet.isPortalTravel()) { localplayer.justPortalTraveled(); } if (this.minecraft.screen instanceof DeathScreen) { this.minecraft.setScreen((Screen)null); } this.minecraft.gameMode.setLocalMode(p_105066_.getPlayerGameType(), p_105066_.getPreviousPlayerGameType()); } ... }
The fromPortal field should be true only when we are sure that the player is naturally changing from dimensions, like in ServerPlayer.changeDimension(ServerLevel), which is triggered only when the player is joing to change dimensions throught portals.
However, this fix didn't always work; in certain cases that i couldn't determine, the glitched animation played intead. That left me confused for a while until I found an alternative to this fix.
The new fix comes from the same concept of letting the player know whether or not the dimension travel was a because of a portal, but splitting ClientboundRespawnPacket.java's dimension change function into ClientboundDimensionTravelPacket.java. This new packet didn't create a new player instance and will reuse the previous one. I'm sure of something; that the previous fix did not work because the player could have lost some data. This new fix has worked at the 100% of tests. This is the new dimension travel packet handler:
public class ClientPacketListener implements TickablePacketListener, ClientGamePacketListener { ... @Override public void handleDimensionTravel(ClientboundDimensionTravelPacket packet) { PacketUtils.ensureRunningOnSameThread(packet, this, this.minecraft); Holder<DimensionType> holder = this.registryAccess.compositeAccess().registryOrThrow(Registries.DIMENSION_TYPE).getHolderOrThrow(packet.getDimensionType()); LocalPlayer localplayer = this.minecraft.player; ResourceKey<Level> newDimension = packet.getDimension(); ResourceKey<Level> oldDimension = localplayer.level.dimension(); if (newDimension != oldDimension) { Scoreboard scoreboard = this.level.getScoreboard(); Map<String, MapItemSavedData> map = this.level.getAllMapData(); boolean flag = packet.isDebug(); boolean flag1 = packet.isFlat(); ClientLevel.ClientLevelData clientlevel$clientleveldata = new ClientLevel.ClientLevelData(this.levelData.getDifficulty(), this.levelData.isHardcore(), flag1); this.levelData = clientlevel$clientleveldata; this.level = new ClientLevel(this, clientlevel$clientleveldata, newDimension, holder, this.serverChunkRadius, this.serverSimulationDistance, this.minecraft::getProfiler, this.minecraft.levelRenderer, flag, packet.getSeed()); this.level.setScoreboard(scoreboard); this.level.addMapData(map); Component title; if (newDimension == Level.OVERWORLD) {//this is exta code from my mod, it fixes MC-12789 ResourceLocation resourcelocation = oldDimension.location(); String s = resourcelocation.toLanguageKey("dimension"); title = Component.translatable("menu.leavingDimension", Language.getInstance().has(s) ? Component.translatable(s) : Component.literal(resourcelocation.toString())); } else { ResourceLocation resourcelocation = newDimension.location(); String s = resourcelocation.toLanguageKey("dimension"); title = Component.translatable("menu.enteringDimension", Language.getInstance().has(s) ? Component.translatable(s) : Component.literal(resourcelocation.toString())); } this.minecraft.setLevel(this.level, new ReceivingLevelScreen(title)); localplayer.fishing = null;//This a fix for an issue that happened in one of my tests. Since the player instance is not a new one and because the client doesn't unload entities from previous level (yeah client worlds work like that) and the player doesn't to check if the fishing rod is a valid entity to unset it, I had to put that here. if (packet.isPortalTravel()) { localplayer.justPortalTraveled(); this.minecraft.getSoundManager().play(SimpleSoundInstance.forLocalAmbience(SoundEvents.PORTAL_TRAVEL, this.random.nextFloat() * 0.4F + 0.8F, 0.25F)); //You can see the portal travel sound playing from here and not from levelEvent() because with this fix we no longer really need to use another packet (I removed the level event 1032 as well) } } if (localplayer.hasContainerOpen()) { localplayer.closeContainer(); } localplayer.setLevel(this.level); if (newDimension != oldDimension) { this.minecraft.getMusicManager().stopPlaying(); } this.level.addPlayer(localplayer.getId(), localplayer); } ... }
Well I hope my fix is clear to understand, if not, or if there are any questions, feel free to ask
It's time to get this fixed
Duplicate of
MC-2097. Please use the search function to check before posting in the future.How is this a duplicate of
MC-233? That issue is about sound, not messages, and Kumasasa has said in the comments of that issue that this is a separate issue.Agree. This is not a duplicate.
Thirded, this is not a duplicate, not of
MC-233, nor ofMC-2097. Please reopen.Affects 16w04a.
Affects 16w05b.
Probably relates to
MC-2681Affects 16w06a.
A related bug was marked as works as intended, so I guess this is intended too.
Affects 16w07a.
Affects 16w07b.
"Simulating the world for a bit" (menu.simulating) does not appear anymore neither even though it is still listed on crowdin
Affects 1.9-pre1.
Affects 1.9-pre3.
Affects 1.9.1-pre3.
Affects 1.9.2.
Affects 16w20a.
Affects 1.13-pre1
Greg Milson, ticket is yours now.
Confirmed for 1.13.1.
Confirmed for 20w11a
Still in 20w12a
Affects 20w13b
Affects 20w18a
Affects 20w19a
Affects 20w21a
Affects 20w22a
Affects 1.16 Release Candidate 1
Affects 20w27a
Affects 20w28a
Affects 20w29a
Affects 1.16.2
Affects 1.16.3-rc1
1.16.3 has been released?
Can confirm in 20w51a.
Can confirm in 21w03a.
Can confirm in 21w05b.
Can confirm in 21w06a.
Can confirm in 21w07a.
Can confirm in 21w11a.
Can confirm in 1.16.5 and 21w14a.
Can confirm in 21w15a.
Can confirm in 21w17a.
Can confirm in 1.17.
Can confirm in 1.17.1 Release Candidate 1.
Can confirm in 21w39a.
Can confirm in 21w40a.
Can confirm in 21w41a.
Can confirm in 1.18.1.
Can confirm in 1.18.2.
In 22w15a
Can confirm in 1.19.
Can confirm in 1.19.2.
Affects 1.20.1.
Would this count as a parity issue?
Predates busy bees, so no.
In 23w32a
In 23w33a
In 23w35a
In 1.20.2 Pre-Release 2
In 1.20.2 Pre-Release 3
In 1.20.2 Release Candidate 2
In 1.20.2
In 23w42a