The Bug:
In previous versions of the game, when going through a Nether portal in the Overworld the game would search a 17x17 chunk area, centered on the chunk containing the point with the coordinates of the Overworld portal divided by 8, for an existing portal and pick the closest one or generate a new portal. This behavior has been changed and now the game only searches a 3x3 chunk area. The linking radius is unchanged in the Overworld.
Code Analysis:
The main portal-linking logic happens in Teleporter.placeInExistingPortal() (line 29). A check at the start of the function sets the linking distance to 1 chunk if the entity is entering the Nether. Setting radius to 128 and skipping the check fixes the issue, mostly.
public Optional<TeleportationRepositioner.Result> placeInExistingPortal(BlockPos blockPos, boolean inNether) {
PointOfInterestManager pointofinterestmanager = this.world.getPointOfInterestManager();
int radius = inNether ? 16 : 128; //This line causes the bug
pointofinterestmanager.ensureLoadedAndValid(this.world, blockPos, radius);
/* The rest of the code searches the area and finds the closest portal */
}The second half of the fix is removing an unnecessary filter from PointOfInterestManager.getInSquare() (line 59). The filter checks that the portal block is within radius blocks of the entity's equivalent position in the new dimension in both the x and z axes. This can preclude parts of chunks from being searched even if the chunk is within the search region, which makes linking inconsistent. Removing the filter, along with the previous change, completely fixes the issue.
public Stream<PointOfInterest> getInSquare(Predicate<PointOfInterestType> predicate, BlockPos blockPos, int radius, PointOfInterestManager.Status status) {
int i = Math.floorDiv(radius, 16) + 1;
return ChunkPos.getAllInBox(new ChunkPos(blockPos), i).flatMap((chunk) -> {
return this.getInChunk(predicate, chunk, status);
}).filter((portal) -> { //This filter is unnecessary and causes an edge-case bug
BlockPos portalPos = portal.getPos();
return Math.abs(portalPos.getX() - blockPos.getX()) <= radius && Math.abs(portalPos.getZ() - blockPos.getZ()) <= radius;
});
}I generated this code using the most recent release of MCP Reborn (as of 8-14-2020).
Related issues
is duplicated by
Comments
migrated
migrated
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."
migrated
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.
migrated
Can confirm this is happening for me as well in 1.16.2, changed from the behavior in 1.16.1. I couldn't find any documentation or mentions about this change (if intentional – and, if so, why?) and spent a while trying to figure out what was going on! Hoping this can be addressed. Thanks for posting the helpful code snippet!
This broke my standard portal linkage/setup on a small survival server (can provide coords or more info if needed), so just to note this can affect basically any player, not just when exploiting exact distance mechanics to build farms.
Erik Broes
This is indeed correct, the old bug of a non-scaled radius has been fixed.
migrated
I aggree that the non-scaled radius was wrong.
But I think one lin in the posted code is still wrong.
It think it must be
int radius = inNether ? 128 : 1024;otherwise it would break existing portal routes that are based on the well know ranges explained in this graphic:
https://minecraft.gamepedia.com/File:OverworldToNetherPortal.png
migrated
@kittycatkenobi may I ask in which file you found the code? I am on 1.16.1 because of a mod and my portals work in a weird way, wanna take a look at it.
migrated
@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.
migrated
@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.
migrated
@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.
migrated
@kittycatkenobi
sorry, I am not best with coding, may I ask where you found the Teleporter.java file? I searched my .minecraft folder for Teleporter and it didn't find anything. I even have hidden files enabled to be seen, so this shouldn't stop the search either.
migrated
@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.
migrated
@@unknown the problem you wrote in your first comment was MC-149705 - that is the "unscaled" behavoir Grum was talking about (It created useless portals in overworld, when you return from nether).
I waited a very long time that this would be fixed, and I realy hoped it would be done in the nether update.
But it seems that it was fixed in the wrong way.
Instead of increasing the range in overworld, the reduced the range in nether, what destroys all long rang teleport gateways like you can read at MC-203285
When I enter my world, no portal connects anymore and I get always new portals in the nether when I enter a portal in the overworld that is part of a long range route, created before 1.16.2.
Erik Broes
I'm not sure what kind of information I can provide, however, I have a very massive gold farm I was using in 1.16.1 that worked wonderfully, (using portal mechanics) I can confirm that this is 100% broken (yeah 5 days spent on this project for it to break the next day, hah. karma)
What I can provide is some strange information
While the farm went from 100k nuggets an hour, to basically 0 some noticeable changes have occurred.
The pigman prefers portals, MUCH closer to where they should be, however, the multiplied distance is still relevant.
The farm rates are now near 0. I can provide a world for this if needed. I do not want to provide it, but if it helps prove this breakage, I am more than willing to assist!