Portals generate far-away chunks & set player on fire

Could anyone link to the video proofs of those confirmed issues?

I will make a video showing all the issues soon but MC-97523 has a couple videos showing portal behaviour (although you now take less fire damage in pre-4). I tested all these issues which were claimed by other people on a fresh world on a 1.9 pre-4 server, if you would like to reproduce them.

I think the mention of swiftness should be removed because of MC-10755

MC-10755 is a totally different case, where sound game logic just results in some non-intuitive behaviours. This is an anti-cheat feature accidentally breaking the game logic.

@Fang Zhang

https://youtu.be/w0sv2ZvQJ_k

This was actually created in relation to MC-89928, but relates to the anti-cheat kicking in and then teleporting the player. The teleport action is clearly visible.

Also, if I'm correct, this was the cause of MC-89928 and all bugs related to the Nether Portal since 15w40a, all of which effects have been patched, including, but not limited to:

• Incorrect Teleport Coordinates after Dimension Shift - Players would find themselves in the wrong location after dimension shift. Coordinates would be the same as the overworld vs the nether, which sometimes would lead to death (especially if you TPed into the void in the End, or Lava in Nether). This was later patched to where the game teleports you back into the portal.

• Portal Looping - Since anti-cheat moved you out of the portal, and then the patch moved you back in, you effectively broke the game logic that you couldn't teleport immediately after spawning in a portal block. Due to the client attempting to load three locations (proper location, overworld equivalent coordinates, then back to the proper location), this often caused client side lag, as well as server lag, which would not let the player move from the portal before they teleported again. The only way to break this looping was to kill the game. This was later patched with what I believe was a dimension shift cooldown.

• Incorrect Teleport Coordinates after Dimension Shift After Game Crash - If the game was killed during teleport, players would often find themselves spawned at the overworld equivalent location in the nether or in the nether equivalent location to the overworld depending on what dimension they were in while the game crashed (or was forced shut down), since the game effectively believed them to be disconnected and didn't bother with the translation back to the portal frame. This bug is not as often seen since the Portal Looping has been resolved with a dimension shift cooldown, however, would still be possible if the game crashes for any reason during teleport.

• Portal Damage (Suffocation & Fire) - If the anticheat moved you into the corresponding block in the nether as the overworld portal after dimension shift, and that corresponding block was solid (suffocation) or lava (fire), you would take the appropriate damage. Since players are invulnerable during teleport now (as of Pre-4), they will not take the suffocation damage, but may still catch on fire, which can lead to additional damage once you leave the dimension shift sequence.

Finally, a current effect of this bug,is that you load & generate chunks far out in the nether that would otherwise never be visited. For example:

If you are at 800 70 800 in the overworld, and make a nether portal, the game will teleport you to a portal near 100 70 100. However, anticheat moves you to 800 70 800 (the location of the portal block you came through in the other dimension). If lava happens to be in that location, you will catch fire before your finally teleported back into the proper nether portal frame at ~ 100 70 100. I had also observed in gamemode 3 that if a ghast was spawned, it would attempt to lock onto the teleporting player at the 800 70 800 range.

Not only does this increase server load, it also unnecessarily increases the size of the server save file.

Please ask if you have any additional questions about these points.

Yes. Mojang have been patching effects not causes which I cannot imagine is good for either the code quality/changeablilty or stability in future versions.

I will admit, certain patches such as the cooldown on dimension shifts and invulnerability while shifting dimensions are good safeguards, especially if there is server lag involved. But you are correct, future versions can really get screwed if they make one minor change and then suddenly all of the patches unravel. At this point, if this specific bug is fixed, there's a bunch of technically unneeded code in the game as well. :/

@James Koon Do you know any other issues that are caused by this?

@bob

I believe you've outlined quite well in the description everything else that I've noticed except for one thing I noticed: If using a Speed 2 Beacon + a Haste 2 beacon, there is a vast increase in ghost blocks due to corrections to coordinates while breaking blocks. I was clearing out a 10 x 7 x 100 long tunnel around a beacon and was constantly getting ghost blocks.

The main reason I know so much about the nether is I have been building the nether hub on my server, and have been having to poke around to fix all the issues in regards to portal issues.

That last issue is MC-94438

Yes, however, I was able to correlate the amount of "moving too fast" errors to the amount of ghost blocks. I'll have to record with a console open to show this. I'm about to head to work, but the ghost block issue seems to happen everytime the server corrects the coordinates of the player while using instant mine.

Oh; in that case it is this bug, sorry

st*s*tus

@James Koon
Just tried a load of tests using speed 2 in survival; could not reporoduce either rubberbanding or log messgages.

Also, can anyone reproduce MC-98209? I flew around for a while but nothing happened.

Edit: Does it have to be on a server?

https://youtu.be/UyrrEdEbkHo

The portal issue is the only one I've had time to test. I have yet to see a "Player Moved Too Fast" while testing however, and since it's still happening, and we don't know what's going on behind the scenes (as far as if they changed how it's reported), and since the same things are happening without the error, I'm skeptical as to the bug itself being fixed.

I'll be checking the other items as well. I'll add a new comment if I find anything (such as the ghost blocks with beacons).

OK thank you! I can confirm portals also.

I'm on the 1.9 release and went through a portal to the nether then went back to the overworld, the console displayed the Player moved too quickly message.

23:41:01 [Warn] DecrepitDoors moved too quickly! -233.2804134719363,24.0,-201.96840655578762
23:43:43 [Warn] DecrepitDoors moved too quickly! 233.5886696276972,-24.0,202.1310059257861

Broken anti-cheat code is far, far worse than cheaters. This should never have been present in RC-level releases.

@Kai I strongly agree. Cheaters are not that common, and if they DO get seen, an OP can just ban them. But this broken code stretches into territory that we as players use too often to be interfered with.

I catch fire every time I go through my portal to the nether, but there is no fire at the portal there. Overworld portal at y=22 might correspond to lava suspected by other commenters. What patch do I need to download to fix this?

@Jeffry R. Fisher
There is no patch for this. The best you can do is go to the exact coordinates in the nether that the overworld portal is in (so if the portal is at 300 22 300 in the overworld, go to 300 22 300 in the nether), and remove all lava blocks from that location. Hopefully this will be fixed in a later version.

This bug is much more serious than I thought!

@unknown it's "little" not "lettle", lettle isn't a word

Sorry: typo

I fixed it before as well, and you changed it back XD

Wow I'm bad.

One other thing I noticed one day when my internet was acting up a little was that moving at all causes "Moved too Fast" errors, creating bad bad bad rubber banding, and simply jumping would kick you using the No Flying kick.

I'm guessing it is because the client sends several ticks' worth of movement packets in one go so the game thinks you moved that far in a single tick.

I'm not sure if this counts as a suggestion (and as such would be considered off topic), but could an additional solution for the possible fixes, however temporary, be to add a game rule or server.properties option to disable this anti-cheat, in the same vein as the allow-flight option? Say, allow-speed. It'd fix half the problem if you were playing on a server with people you trust not to cheat/hack.

Off topic: I was actually initially under the impression that allow-flight was what disabled the subject of this bug report.

Edit: Apparently /gamerule disableElytraMovementCheck was already a thing when I posted this, lol. I do wish this would apply to all movement and not just elytra movement.

@unknown ^This. It should be a gamerule though, so that you can toggle it in singleplayer.

I'm actually coming to think that the real fix lies in calculating how many ticks of movement data came from the client. So if the speed limit is 10 m/tick (I think it is this) and the client sends a move packet of 20m after 3 ticks, the game would currently TP the player back as they "moved too quickly" but should not actually as the player only moved 6.67 m/tick

Just an additional note, under "The following actions can cause the player to rubberband back and forth", I have found that my TNT cannons no longer launch me in the air... they now launch me one block up and the server says I moved too quickly. I have also been seeing this when I fly in creative or with Elytra, even though I have set

allow-flight:true

and have added the gamerule

disableElytraMovementCheck:true

I cannot confirm the portal issues that others have been discussing, but I can confirm this is still an issue.

Thank you for the information. Is this confirmed for 16w15a then?

@unknown Honestly I don't know. I am new to bug-reporting... I made an account to follow this bug. I'm playing on 1.9.2 currently and am not downloading pre-releases, if that helps.

Where do I find my specific snapshot code, for future reference?

Well it says what snapshot you are on in the top left corner if you press F3, but I really meant "version" not "snapshot", sorry. Confirmed for 1.9.2 then.

I've heard disableElytraMovementCheck doesn't work properly.

Which of the non-portal (strikethrough) issues are others getting in 1.9.3?

Just created a new world, teleported to 10.000 10.000, built a portal, opened world in Minutor. There were the usual chunks loaded in the nether around 1.250 1.250, but also 2x2 chunks around 10.000 10.000 in the nether. So I still got teleported back (bug confirmed), but only generated a few chunks, because I'm playing on a laptop with multiple programs open.
tldr: "Portals loading chunks at the exact location of the entry portal, but in the other dimension" <-confirmed for 1.9.3-pre2.

Thank you. But have you seen any issues with bring teleported back ("rubberbanding") while riding a horse, sprinting with speed effects, rowing a boat at max speed, flying with elytra, flying in creative or spectator etc.?

Nope. Just flew with maximum speed in gamemode 3 and even had a repeating command block with
tp @p 0 ~ ~
This was a command where I first encountered rubberbanding, but it worked good this time.

I also haven't been able to reproduce over the past few days of playing so I'll remove that bit.

Edit: Log now says stuff like "<Player> moved wrongly". I think this implies that no attempted reverse teleportation is occuring.

@unknown that message means that theplayer attampted to move via a invalid path, for example through blocks in creative.

Why am I getting it in a boat on an ice path? Has this been reported?
Edit: MC-90062, a related issue.

Because the ice boat speed is not a feature, as known so far, no mojangster said it's intended.

I changed this bug to focus in the portal issues in light of MC-90062.

Well, then this has become a duplicate of MC-89928.

No it hasn't. MC-89928 is about end portals teleporting you into the void. This bug is about nether portals setting you on fire. They were going to be merged but some Mojangsta intervened AFAIK so they are separate bugs.

The entire bug seems to be about the game not following the division/multiply by 8 rule in the Nether/End placement when entering the said realms, which can lead to spawning inside blocks, or falling into the Void.

It mentions nether as well, setting on fire = spawning inside blocks with said blocks being fire or lava.

You don't spawn inside that block though. You are instantly teleported to the correct location. With MC-89928 you remain at the wrong location until you fall in the void, burn or suffocate, and the nether part has been fixed--the description is outdated. The end part was thought fixed, but it was reproduced in 1.9.0. Also:

bob added a comment - 27/Feb/16 10:49 AM - edited
If the invulnerablility has been added, this bug should be marked as resolved. Instead, a new bug should be opened detailing the various effects of the broken anti-cheat system (rubberbanding with speed, portals briefly loading wrong chunks, portals setting you on fire and so forth).
[Mod] Kumasasa added a comment - 27/Feb/16 10:55 AM
bob: Go ahead.

Well, to me this still seems like a duplicate now, but we'll see what other mods have to say about this.

If you resolve as dupe please update the description of the other bug at least; it is very outdated.

As far as I know, there is currently no other unresolved bug to track 'nether portal sets you on fire' due to the bad coords. The comment section of MC-89928 is kind of a disaster to understand 'what effects' any of the bugs actually tracks.

MC-89928 is tracking the (fixed AFAIK) bug that portals actually TP you to the wrong coords.

I cannot attach the video I've recorded as the file is too large, but I've dug around the portal and cannot find any lava that would represent a threat, yet the burning issue is persistent as of May 4, 2016.

Not around the portal; around the portal's exact location (xyz) in the other dimension. So if you had an overworld portal at (100, 64, 100) you would dig at that spot in the nether, not around the exit portal at (12,64,12) or so.

I've managed to dig around both portals now, yet am still set on fire. Note that the first portal I created was in the overworld, and the second one of the pair within the Nether.

I apologize for misinterpreting your previous comment, what you've said makes sense now that I've reread it.

It's fine; this issue is really confusing!
Edit: added fix instructions; are they clear enough?

Also @mathew what version are you running?

The "fix" instructions sound like Mojang could fix it this way (for me at least).

I'm currently running the latest version of Minecraft, which should be 1.9.2 (the debug says 1.9.2/vanilla)

OK; thank you

I can confirm "burning coming out in nether" beginning with 1.9.0 and still with 1.9.4. (pure vanilla server).
It does not happen all the time, but most of it.
I will check out the workaround/fix, sometime soon.

I TPed to coordinates in nether, where portals coordinate are in overworld and removed lava there, seems working, no burning yet.

Edit: I must relativise my prior statement. It still happens that i'm burning when coming out of the portal in nether, though not happening as often.

This video was originally made for MC-89928 for Pre-2, but it offers a side by side shot of what's happening.
https://youtu.be/n9hZgJDO9TA

I can make an updated version with 1.9.4 but I've been able to repeat this in current versions.

Also, if you, due to latency, disconnect from the server during dimension shift, you are likely to find yourself in the opposite dimensions coordinates when you log back on.

EG: You enter a portal in overworld at 1000, 70, 1000 in the overworld. You DC. You log in. Instead of being at 125, 70, 125, you find you're at 1000, 70, 1000 in the nether. And it's in a wall. And you suffocate to death. GG.

How do you disconnect whilst going through a portal?

Due to latency? Had one of the people on my server disconnect during dimension shift numerous times because he was playing at 2-3 bars. He was disconnected from the server, he didn't disconnect himself. Don't know if it'd work if you alt-F4'd during dimension shift or not to recreate or force-crashed your client?

This bug is still very lag-based but also reproducible. I think it's because of the quick-and-dirty way in which they patched MC-89928.

Myself and my sever's players just noticed this problem. We're running 1.10. It seems to either have been introduced with 1.9.x or 1.10. I've tried replacing World files in the Nether but that doesn't help at all. When using a Nether Portal my start coordinates are -5/120/34 and upon going through to the Nether I arrive at -3/-3/-2 (Y value may actually be zero). I appear to be in "The Void" and immediately begin falling from some solid surface, take suffocation damage and die shortly thereafter. Server logs do indeed show "<player name> moved too quickly!" and right after the death message for that player is "<player name> fell out of the world."

I would be happy to provide any files or other data that would help resolve this problem. Right now our Nether Portals are effectively broken in our game.

Two questions: First, is there a workaround for this problem as I've described it? Second, does this affect any new Nether Portals outside the portal-linkage radius (1024 blocks, I think) of the original portals or does this only affect already-existing portals?

@unknown What is the Seed of the world? In which version did you generate the world?
I just created a regular world and went into a portal at -5/120/34, but I landed safe in the Nether at around Y-level 109.
There are generating differences even when one uses the very same seed, and maybe the issue isn't the seed after all, but I'd like to make sure.
Also, do you run any plugins on the server, or is it 100% Vanilla?

Edit: Check in the NETHER at around the same coordinates, so, around -5/120/34, if there is any lava, fire or something that sort of obstructs the exit there.
If so, remove all the Lava and Fire closeby and try again (go into creativemode to be sure).

If they are falling out of the world, I guess the chunk is not loading.

If you get teleported to y=-3 instead of your overworld coordinates, it's not this bug.

Thanks Meri Diana for writing. My world's seed is -2466281547766755436. The Create date on the \World\level.dat file is Feb 28, 2016 so I'm pretty sure we started with 1.9. I run a Spigot server and the only plugin I use is PermissionsEx. If you think it's helpful I can try and load the world using a vanilla server build instead of Spigot.

I went into the Nether in creative mode and had to bust upwards through a wall in the sky of bedrock to get to the nether proper. Once I did I was in the normal Nether area that we're used to seeing. I flew to -5/120/34 (not at all where the Nether portal is) and it's within solid Netherrack for quite a distance in any direction. For reference the actual location of our portal within the Nether is -2/52/-2. There's a structure around it so no fire but one side of the portal is covered by cobblestone.I removed that cobblestone but the problem still persists. I did note too that when I took the portal in the Nether to get back to the normal overworld it sent me roughly (I moved slightly before recording the coords) to -51/38/-49. It put me within solid rock and if I weren't in Creative mode I would have died.

Thanks Fabian, I actually came to this bug by way of MC-89928 which references this one. If you're saying that what I'm describing is a different bug (albeit one with strikingly similar symptoms) should I start a brand new bug report?

I can confirm this bug, it just happened on my multiplayer server. Travelling through a portal in the nether at 5, 8, -127 set me on fire when I arrived in the overworld at 40, 64, -1000. The was no lava near the overworld portal, but going to the nether coordinates of the portal in the overworld (5, 8, -127) and removing the lava there stopped me from being set on fire when using the portal.

@unknown MC-89928 was kind of the old version of this bug. Then a short invulnerability after going through portals was introduced that hid some of the symptoms. Because parts of it technically got fixed, this bug report was created. It's still the same cause, just some effects are not there anymore.
If you can't find a bug report that says that you get teleported below y=0, you should create one, yes.

@unknown Sounds good, I've created MC-103905 for what I'm seeing. It sounds extremely similar and I do know that others have reported the same symptoms of "falling out of the world."

MC-90062 also describes some other effects of this bug. Does it cover your effect MC-103905?

Bob that's a good question. I do see that message in the server console while falling out of the world but I don't get TP'd upwards to my starting point. I would have to say that it covers part of what I'm seeing as described in MC-103905. However any of that is a consequence of my chief issue that our Nether Portals are now depositing players under the Nether at the incorrect Y coordinates instead of to the proper destination. That's the primary issue at hand for myself.

Confirmed in 16w35a & 16w36a

Confirmed in 16w38a

Confirmed in 16w39a

Confirmed in 16w39b

Confirmed in 16w39c

Have come to this bug via MC-98209 which has been marked as a duplicate of this one.
I'm running a 1.10.2 vanilla server on Windows 7 x64 JRE1.8.0_102-b14 (also 64-bit) and getting the "<player> moved too quickly!" message in the server console whenever I sprint and far worse if I have my Speed 2 beacon on - I can barely walk. Doesn't happen if the same world is loaded as SP. This is on a quad core i7 with 32GB RAM (8 allocated to server) across a 1Gb LAN

Just saying, as the focus of the discussion here seems to be on Nether Portals, should the other bug be reopened?
Either way, please please give us the ability to just disable the broken anti-cheat in server.properties!

Richard you are looking for MC-90062

Confirmed in 16w40a

Confirmed in 16w41a

Confirmed in 16w42a

The issue is that due to the new teleport acknowledgement system, after moving through the portal, the server sets the player back to the last position acknowledged until the client acknowledges the new position later causing a rubber band / teleport.

When was the teleport acknowledgement system added?

1.9

Oh right. Is this the same thing as the anti-chest thing around 15w4xx?

Confirmed in 16w43a

Confirmed in 16w44a

Confirmed in 1.11-pre1

Confirmed in 1.11

Confirmed in 16w50a

Confirmed in 1.11.2

Isn't it related to MC-114022 ?

👍

Also confirmed in 1.11.2. I have confirmed with spectator mode that there are no lava blocks in the vacinity of either portal.

UPDATE (solution confirmation for an unmodded multiplayer server)

My example:
I was catching fire only when returning to the Nether from the Overwold. My Overworld portal (5x5 sized portal) bottom center block is at [710, 25, 431]. I went to [710, 25, 431] in the Nether (not the Nether equivalent coordinates). This was in the middle of a lava lake. I filled a portal sized area at those coordinates, plus some surrounding area with a solid block (approx. a 7x7x9 area filled).

This HAS solved the problem for this portal. After doing this, I did not have to move EITHER portal, and the portal behavior is now normal in both directions.

In my case I am not sure which part fixed the portal:
A) Because the chunks at that location [710, 25, 431] had not been generated in my world in the Nether?
B) Because I removed the lava from that location and the surrounding area?

Please edit your message as few times as possible, with this comment you sent 195 mails. There is a blue icon on the bottom right of the text box, that's a preview.
Also this is not a solution, the bug is still in the game and has to be fixed. It's a workaround to encounter the bug more rarely. And it's already known, it says in the description here: "Workaround: Remove all fire/lava at the exact location of the entry portal in the other dimension"

We just encountered this bug on our 1.12 world. The world was created during recent snapshot phase, not sure during which snapshot exactly. The portal was created during one of the late 1.12 pre-releases. We had no problems at first. When we returned after full release we started burning when going through it. I followed the advice from here, which fixed the problem.

Confirmed 1.12.2

Me, Tim Miller, and Pokechu22 found the fix!

add ((EntityPlayerMP)entityIn).connection.captureCurrentPosition(); to Teleporter.java to line 186.

if (entityIn instanceof EntityPlayerMP)
            {
                ((EntityPlayerMP)entityIn).connection.setPlayerLocation(d5, d6, d7, entityIn.rotationYaw, entityIn.rotationPitch);
                ((EntityPlayerMP)entityIn).connection.captureCurrentPosition();
            }

What is happening is that the player is being moved to the new portal location but as there is a speculated redundant code in the NetHandlerPlayServer.java function update().

public void update()
    {
    	this.captureCurrentPosition();
        this.playerEntity.onUpdateEntity();
        this.playerEntity.setPositionAndRotation(this.firstGoodX, this.firstGoodY, this.firstGoodZ, this.playerEntity.rotationYaw, this.playerEntity.rotationPitch);

captureCurrentPosition saves the location of the player. Then onUpdateEntity updates the players positions to teleport to the other dimensions portal location. Then the position of the player is set in setPositionAndRotation back to the older saved position in captureCurrentPosition creating a pink pong effect. Later the position is updated by the teleport confirmation making the player end up in the correct destination eventually. But this ping pong effect causes massive issues with players being placed in the wrong location in the correct dimension, both fire and chunk loading happens due to this and causes extra strain on the server when travelling through a portal as unneeded chunks are loaded. The simplest fix is to update the position via captureCurrentPosition in the place where the player is being teleported to i.e. the part of the Teleport.java code that updates the players position to the new portal exit position.

Just for clarity:

We couldn't figure out why it calls captureCurrentPosition, then onUpdateEntity (which through a long chain of calls to e.g. onUpdate, gets to Entity.onEntityUpdate which changes the entity's dimension+teleports them to the portal) but then reverts it, but didn't feel comfortable removing the reversion since we couldn't determine that removing it would be safe. All of the stuff in EntityPlayerMP.onUpdateEntity is network-related, but onUpdate and such isn't. It's kind of weird.

This bug originated sometime during 1.9's snapshot phase (might have been 15w30-42 if memory serves). I'm not sure if any devs can look into changes back to that time, but whatever caused the initial bug has never been fixed, only the effects have been patched. I noted all of the ways this bug was 'patched' in a previous comment, but am going to repost/update it here to help hopefully clarify the logic behind some of the code, that way if someone reads through this trying to figure out what's causing the problem, it may help in peeling back all of the patching involved so they can make sense of it.

• Incorrect Teleport Coordinates after Dimension Shift - This was the original culprit. Players would find themselves in the wrong location after dimension shift (800x100x800 in overworld would lead to 800x100x800 in the nether or end). Coordinates would be the same as the overworld vs the nether, which sometimes would lead to death (especially if you TPed into the void in the End, or Lava in Nether). This was later patched to where the game teleports you back into the portal/location after you originally should have been teleported there (effectively rubberbanding the player to the portal, to the previous dimension coordinates, then back to the portal).
  Portal Looping - Since you were moved out of the portal, and then the previous patch moved you back in, you effectively broke the game logic that you couldn't teleport immediately after spawning in a portal block. Due to the client attempting to load three locations (proper location, overworld equivalent coordinates, then back to the proper location), this often caused client side lag, as well as server lag, which would often not let the player move from the portal before they teleported again. The only way to break this looping was to kill the game. This was later patched with what I believe was a dimension shift cooldown.

• Incorrect Teleport Coordinates after Dimension Shift After Game Crash - If the game was killed during teleport, players would often find themselves spawned at the overworld equivalent location in the nether or in the nether equivalent location to the overworld depending on what dimension they were in while the game crashed (or was forced shut down), since the game effectively believed them to be disconnected and didn't bother with the translation back to the portal frame. This bug is not as often seen since the Portal Looping has been resolved with a dimension shift cooldown, however, would still be possible if the game crashes for any reason during teleport (Please note though this was bandaid fix, it happens often STILL for some people if their game crashes or they are DCed for any reason during dimension shift, especially if they are playing with a weaker PC).

• Portal Damage (Suffocation & Fire) - Corresponding with the rubberbanding effect of being moved in and out of the portal frame during dimension translation, if any of the corresponding blocks were solid (suffocation) or lava (fire), you would take the appropriate damage. Since players are invulnerable during teleport now (as of 1.10 Pre-4?), they will not take the suffocation damage, but may still catch on fire, which can lead to additional damage once you leave the dimension shift sequence.

Ultimately, I've been watching this bug for a couple years now, as I admin a server and am often having to go remove lava blocks from server members portals. If there are any questions about this please feel free to contact me, but as I said, it originated in the 1.9 Snapshots, the effects of the bug have been patched instead of the bug itself, which in all honesty has probably made it more difficult to fix, especially as time goes on.

Can confirm that the code in question was introduced during the 1.9 snapshots - it's not present in 1.8.9 MCP and is present in 1.9 MCP (that's the simplest test). MC-89928 is pretty important to note (already linked as related).

Doing a binary search on the (obfuscated!) versions, using the string " moved wrongly" to find the right class, I can confirm that code to this effect was introduced in 15w41a (a bunch of new fields were added that are updated in c() based off of b's position - that matches this description, although c() is a general tick thing. Another search shows that this was moved into its own method in 15w43c (I can't say whether there were any other logic changes or if this was just general cleanup, as it's hard to read without any naming).

From NetHandlerPlayServer:

d9 = d6 - this.player.posZ;
                            d11 = d7 * d7 + d8 * d8 + d9 * d9;
                            boolean flag = false;

                            if (!this.player.isInvulnerableDimensionChange() && d11 > 0.0625D && !this.player.isPlayerSleeping() && !this.player.interactionManager.isCreative() && this.player.interactionManager.getGameType() != GameType.SPECTATOR)
                            {
                                flag = true;
                                LOGGER.warn("{} moved wrongly!", (Object)this.player.getName());
                            }

                            this.player.setPositionAndRotation(d4, d5, d6, f, f1);
                            this.player.addMovementStat(this.player.posX - d0, this.player.posY - d1, this.player.posZ - d2);

The position seems to get reverted right after the teleport: this.player.setPositionAndRotation(d4, d5, d6, f, f1); Removing that line fixes the problem. Disconnecting right after changeDimension (by setting a breakpoint) causes the player to have the dimension changed but not the position, which could even be abused intentionally by some players.

I thought Grum confirmed fixing this bug as per the suggestion above. Can this be tested with a snapshot to see if its fixed. It's already fixed as far as I remember and if not the suggested fix is the least invasive until a complete rewrite of the netcode is needed.

this still doesn't seem fixed for the 1.13 release mainly the MC-98209 part,

It happens in both teleport directions - you end up in the destination dimension, but at the source dimension's coordinates.

In my world, I always get my home base's beacon effects when entering a portal in the overworld (far from my base) and entering the nether, assuming I was at the nether coordinates, but in the overworld for a brief moment.

Same issue happens with parrots when walking into a portal, keeping the overworld chunk loaded by a 2nd player to enable the parrot teleporting to the player when exiting the nether. Parrot should stay there when player enters the nether, but often vanishes and can be found again in the overworld at the nether coordinates of the portal. I assume it tries to teleport to the player in between changing dimension and coordinates. Could be related to MC-123147.

Fixing this bug should be high priority. It has nasty interactions with MC-138550 (High ms ticks in 1.14+, player cannot interact with world normally) and MC-151082 (Loading chunks creates irrecoverable lag). Those bugs are issues with chunk loading and/or chunk caching. This bug causes chunks to be loaded unnecessarily. Combine the two, and this is probably why players can take several minutes to forever to teleport through a Nether portal in 1.14+.

Fixing this bug should not be difficult as a suggested fix has already been provided.

Is this still happening in 19w45b or later?

Test: New world, teleported to 3M 100 0, went through a portal. Waited a few minutes, went back. Then the same process again in Survival. Resulting region files:

minecraft/saves/New World (6)/region/r.-1.-1.mca
minecraft/saves/New World (6)/region/r.-1.0.mca
minecraft/saves/New World (6)/region/r.0.-1.mca
minecraft/saves/New World (6)/region/r.0.0.mca
minecraft/saves/New World (6)/region/r.5858.-1.mca
minecraft/saves/New World (6)/region/r.5858.0.mca
minecraft/saves/New World (6)/region/r.5859.-1.mca
minecraft/saves/New World (6)/region/r.5859.0.mca
minecraft/saves/New World (6)/DIM-1/region/r.732.-1.mca
minecraft/saves/New World (6)/DIM-1/region/r.732.0.mca
minecraft/saves/New World (7)/region/r.-1.-1.mca
minecraft/saves/New World (7)/region/r.-1.0.mca
minecraft/saves/New World (7)/region/r.0.-1.mca
minecraft/saves/New World (7)/region/r.0.0.mca
minecraft/saves/New World (7)/region/r.5858.-1.mca
minecraft/saves/New World (7)/region/r.5858.0.mca
minecraft/saves/New World (7)/region/r.5859.-1.mca
minecraft/saves/New World (7)/region/r.5859.0.mca
minecraft/saves/New World (7)/DIM-1/region/r.732.-1.mca
minecraft/saves/New World (7)/DIM-1/region/r.732.0.mca

So yes, this is indeed fixed. Otherwise the files DIM-1/region/r.5858.0.mca and region/732.0.mca would exist at least in the Survival world.
Disclaimer: I don't know if you can still get on fire if those chunks were already generated. I doubt it, because that would almost imply intentional differentiation between whether the chunk was generated before or not when putting the player in the wrong location, but I have no tested it, because that part of the bug is annoying to test.

It's not resolved yet, as of 1.18.2. I am constantly getting chunks loaded and the region/poi/entities files created/updated at the coordinates of the wrong dimension. Running on a vanilla server.

This report is currently missing crucial information. Please take a look at the other comments to find out what we are looking for.
If you added the required information and a moderator sees your comment, they will reopen and update the report. However, if you think your update to this report has been overlooked or you want to make sure that this report is reopened, you can contact the Mojira staff on Discord or Reddit.
_{-- I am a bot. This action was performed automatically! If you think it was incorrect, please notify us on Discord or Reddit}