kittycatkenobi

@Sketa Swed To see the source code you need to decompile Minecraft. The tool I used is called MCP Reborn, it's a project which you can open in an IDE like IntelliJ and then run setup scripts to create source code. You can also edit the code in the editor and run it to see what happens (very useful for figuring out what a piece of code does!). Here are some links.

GitHub repo for MCP Reborn: https://github.com/Hexeption/MCP-Reborn

 Installation tutorial for Eclipse: https://youtu.be/K6KScyIpCtc

 Installation tutorial for IntelliJ (with Optifine): https://youtu.be/ocz1tPI_YSE

I'll be honest, setting this up for the first time is quite annoying and will take a while. But hopefully the tutorials help. I seem to recall a better tutorial for IntelliJ but I couldn't find it. I may find it in the future though. Good luck! If you have any trouble, try gleaning hints from other tutorials, experiment, use Google, etc. Also feel free to reply here.

@Radon8472 Implementing the change in the opposite direction (by increasing the radius in the Overworld) would cause a lot of issues, and it doesn't really make that much sense. I'd honestly prefer that they kept the old behavior and not change it at all, but Grum has confirmed that this won't happen.

@Radon8472 That's not correct. The old behavior was to have a linking distance of 128 blocks in both the Overworld in the Nether. If two portals are 1024 blocks away in the Overworld from a center point, then they are 128 blocks away from the equivalent point in the Nether. To put it more simply, you travel super far when you go into the Nether, because a linking distance of 128 blocks is equivalent to 1024 blocks in the Overworld. When you leave the Nether you will end up a maximum of 128 blocks away from your equivalent Overworld position, at the destination portal. The graphic you shared explains the old mechanic perfectly. The graphic is wrong in 1.16.2+. If you don't believe me, just try it. The Minecraft Wiki is not always reliable / up-to-date.

Edit: I've struck through my original comment because it's clear that I misunderstood you. I'm leaving a new comment instead.

@Sketa Swed The code isn't in one file. Just to clarify, every class in Java gets its own file with the same name. Since the function Teleporter.placeInExistingPortal() is in the class Teleporter, it resides in Teleporter.java. All the portal linking code is called by Entity.updatePortal() (line 1721 in 1.16.1, 1738 in 1.16.2), and the portal linking logic itself happens in the functions I put in the code analysis. If you want to get a big-picture idea of how the code works, start from updatePortal() and work your way through the call chain to placeInExistingPortal() (line 52 in 1.16.1), which itself calls getInSquare(). Note that while the function names may be obfuscated, the line numbers will stay consistent (between different copies of the same version). So don't panic if you can't find a function I mentioned by just searching for it by name.

Just added code analysis: the change/bug looks very intentional. The question is whether or not this was an oversight and whether or not Mojang will change it back.

Asta Zora, thanks for commenting. I don't think a world download would really help the developers fix this, since this bug is so easy to reproduce and is pretty narrow in scope. I do have two questions:

• Does your farm work how I suspect it does, which is that pigmen spawn in Nether portals in the Overworld and are then sent back to a single portal in the Nether?

• I don't know what you mean by this: "The pigman prefers portals, MUCH closer to where they should be, however, the multiplied distance is still relevant."