MC-197538Portal linking radius in Nether reduced from 128 to 16 blocks
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).
Created Issue:
Portal linking radius in Nether reduced from 128 to 16 blocks
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.
Changing the radius to 16 makes the linking radius "consistent," you travel the same distance using linked portals regardless of which dimension you started in. So this change may be intended. I'd hope, however, that a change to a long-standing game mechanic would receive mention in the patch notes.
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.
Changing the radius to 16 makes the linking radius "consistent," you travel the same distance using linked portals regardless of which dimension you started in. So this change may be intended. I'd hope, however, that a change to a long-standing game mechanic would receive mention in the patch notes.
Code Analysis:
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); Optional<PointOfInterest> optional = pointofinterestmanager.getInSquare((p_242952_0_) -> { return p_242952_0_ == PointOfInterestType.NETHER_PORTAL; }, blockPos, radius, PointOfInterestManager.Status.ANY).sorted(Comparator.<PointOfInterest>comparingDouble((p_242954_1_) -> { return p_242954_1_.getPos().distanceSq(blockPos); }).thenComparingInt((p_242959_0_) -> { return p_242959_0_.getPos().getY(); })).filter((p_242958_1_) -> { return this.world.getBlockState(p_242958_1_.getPos()).func_235901_b_(BlockStateProperties.HORIZONTAL_AXIS); }).findFirst(); return optional.map((p_242951_1_) -> { BlockPos blockpos = p_242951_1_.getPos(); this.world.getChunkProvider().registerTicket(TicketType.PORTAL, new ChunkPos(blockpos), 3, blockpos); BlockState blockstate = this.world.getBlockState(blockpos); return TeleportationRepositioner.func_243676_a(blockpos, blockstate.get(BlockStateProperties.HORIZONTAL_AXIS), 21, Direction.Axis.Y, 21, (p_242953_2_) -> { return this.world.getBlockState(p_242953_2_) == blockstate; }); }); }
minecraft nether code.png
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.
Changing the radius to 16 makes the linking radius "consistent," you travel the same distance using linked portals regardless of which dimension you started in. So this change may be intended. I'd hope, however, that a change to a long-standing game mechanic would receive mention in the patch notes.
Code Analysis:
public Optional<TeleportationRepositioner.Result> placeInExistingPortal(BlockPos blockPos, boolean inNether) { PointOfInterestManager pointofinterestmanager = this.world.getPointOfInterestManager();intradius = inNether ? 16 : 128;//This line causes the bugpointofinterestmanager.ensureLoadedAndValid(this.world, blockPos, radius); Optional<PointOfInterest> optional =pointofinterestmanager.getInSquare((p_242952_0_) -> {returnp_242952_0_ == PointOfInterestType.NETHER_PORTAL; }, blockPos, radius, PointOfInterestManager.Status.ANY).sorted(Comparator.<PointOfInterest>comparingDouble((p_242954_1_) -> {returnp_242954_1_.getPos().distanceSq(blockPos); }).thenComparingInt((p_242959_0_) -> {returnp_242959_0_.getPos().getY(); })).filter((p_242958_1_) -> {returnthis.world.getBlockState(p_242958_1_.getPos()).func_235901_b_(BlockStateProperties.HORIZONTAL_AXIS); }).findFirst();returnoptional.map((p_242951_1_) -> { BlockPos blockpos = p_242951_1_.getPos(); this.world.getChunkProvider().registerTicket(TicketType.PORTAL,newChunkPos(blockpos), 3, blockpos); BlockState blockstate = this.world.getBlockState(blockpos); return TeleportationRepositioner.func_243676_a(blockpos, blockstate.get(BlockStateProperties.HORIZONTAL_AXIS), 21, Direction.Axis.Y, 21, (p_242953_2_) -> {returnthis.world.getBlockState(p_242953_2_) == blockstate; }); }); }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 portal-linking logic happens in Teleporter.placeInExistingPortal(). 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.
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 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 portal-linking logic happens in Teleporter.placeInExistingPortal(). 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.
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 */ }I generated this code using the most recent release of MCP Reborn (as of 8-14-2020). MCP doesn't name this function in 1.16.2 but it does in 1.16.1 so I chose the 1.16.1 name. If you don't want to install MCP twice like I did, search for "? 16 : 128" in the Teleporter class.
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 portal-linking logic happens in Teleporter.placeInExistingPortal(). A check at the start of the function sets the linking distance to 1 chunk if the entity is entering the Nether.
Settingradiusto 128 and skipping the check fixes the issue.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 */ }I generated this code using the most recent release of MCP Reborn (as of 8-14-2020). MCP doesn't name this function in 1.16.2 but it does in 1.16.1 so I chose the 1.16.1 name. If you don't want to install MCP twice like I did, search for "? 16 : 128" in the Teleporter class.
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 portal-linking logic happens in Teleporter.placeInExistingPortal(). 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.The fix seems to work well for non-player entities but is inconsistent for the player.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 */ }I generated this code using the most recent release of MCP Reborn (as of 8-14-2020). MCP doesn't name this function in 1.16.2 but it does in 1.16.1 so I chose the 1.16.1 name. If you don't want to install MCP twice like I did, search for "? 16 : 128" in the Teleporter class.
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 portal-linking logic happens in Teleporter.placeInExistingPortal(). 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.The fix seems to work well for non-player entities but is inconsistent for the player.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 */ }
I generated this code using the most recent release of MCP Reborn (as of 8-14-2020). MCP doesn't name this function in 1.16.2 but it does in 1.16.1 so I chose the 1.16.1 name. If you don't want to install MCP twice like I did, search for "? 16 : 128" in theTeleporter class.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).
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
[Mojang] Grum (Erik Broes)
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
is duplicated by
Thanks for the reply @grum! I didn't see that this had been identified as a bug before. Was this intentionally left out of documentation or changelogs, or what happened there? Just curious, since this isn't that minor of a change/fix.
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
is duplicated by
relates to
Might relate to MC-197538
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
Thank you for your report!
We're tracking this issue as MC-197538, so this ticket is being resolved and linked as a duplicate.
That ticket has already been resolved as working as intended, which means this is not considered a bug and won't be fixed. Please do not leave a comment on the linked ticket.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Mojang Support – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! Please report any issues in Discord or Reddit
Thank you for your report!
We're tracking this issue in MC-197538, so this ticket is being resolved and linked as a duplicate.
That ticket has already been resolved as working as intended, which means this is not considered a bug and won't be fixed. Please do not leave a comment on the linked ticket.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
I akready know about the ticket MC-197538 in my report I was specially telling, that the bug I am reporting here IS NOT RESOLVED.
To be exact, this bug was already caused, by the changes made for MC-197538.
And linke I was writing in my report, this is NO duplecate, because I write about another problem.
So you should reopen this ticket, until the bug is realy resolved.
[Mod] violine1101 please reopen this issue until the detection ranges are fixed to the well known behavior.
Jeffrey Black you are right that both problems are caused from a wrong portal detection range.
But MC-197538. is caused, because portals in the overworld are not searched in a range of 128 blocks instead of 1024, what would be correct.
This Bug is caused because the portals in the nether are not detected in a 128 blocks range.
Both effects destroy existing portal gateways.
It is clear that it works NOT as intended The well known and documentated fakt is, that range in overworld should be 1024 and range in nether 128.
Yust look at the wiki:
https://minecraft.gamepedia.com/File:OverworldToNetherPortal.png
And when you have an idea to fix long rang travel route, that please share your knowledge in a comment here.
For me and the players of my server it would be a real big problem if we can no longer use nether portals travel to far away places.
@Raydon8472
The wiki is not the sole source of truth, and it can be wrong and has been wrong at times.
Grum, a Minecraft developer, has indicated it works as intended. So it is quite possible they intended to reduce the range, possibly due to having such a large search area in the overworld (and the reduction of the range in the overworld was apparently done in 1.14, when the portals were optimised).
So it is not clear that it does not work as intended. It apparently does work as intended, but clearly not as YOU want. But you wanting something is not the same as the developers of the game intending it.
Even if it changes from prior behaviour, it is still not the same as the devs not intending it.
Even if it is wrong, that doesn't change the fact that both this issue and the one this is marked as a duplicate of are both dealing with the range in the nether.
Your issue is focusing on entering portal A in the overworld not linking to portal B in the nether, because the range in the nether is 16 blocks not 128.
MC-197538, which this issue has been marked as a duplicate of, is that the range in the nether has been reduced to 16 blocks. As such, it is a duplicate.
They are quite literally the same issue. Both are focusing on the range in the nether being reduced to 16.
MC-149705 is the one dealing with the range in the overworld not being 1024 blocks, or more specifically that the range in the nether and overworld were both 128 blocks and thus it did not scale, and thus you could go to the nether and go back and have a new portal generate. But that is not the issue that this issue has been marked as a duplicate of.
Have you actually looked at MC-197538, or did you just assume this was labelled as a duplicate of MC-149705?
As for long range travel in the nether, like I said, don't try turning 3 blocks into 1024.
It is meant to be 1 to 8.
If you need to travel 1024 blocks, then setup a path in the nether that is 128 blocks long, with a portal on either end.
The advantage of this method is you can have other portals nearby without it breaking.
For longer routes, it can make far more sense to make a long path in the nether than repeatedly using portals, given it takes roughly 4 seconds to travel through the portal, thus to travel 1024 blocks in the old system would take 8 seconds (plus a bit for loading and walking between).
If you use a boat on normal/packed ice, those 8 seconds allow you to cover 320 m, which equates to 2560 in the overworld.
Blue ice almost doubles that.
Using an elytra gives you 2144 m.
If you really need to go all out, use an ender-pearl cannon.
The infos in MC-197538, are very great, they explain on what places in the code the wrong distance is written.
But when you read correctly, [Mojang] Grum (Erik Broes) yust said "non-scaled radius" is fixed.
That means, it was wrong that in BOTH worlds the detection range is the same. Its tells nothing against a 1024 (OW) and 128 (nether) range.
Its try, maybe they "intended to reduce the range", but the point is that it breaks all existing portal gateways, and I think that is not intended.
And for sure I can tell you, that the 1024 blocks range is at least a fixed part of the game since 1.11.2 or before, because in that version my server was created and the long range portals where used since that version.
I dont realy unterstand what you mean with "turning 3 blocks into 1024".
Thank you for sharing your Idea of an alternative way to travel, but For me it is no real solution to replace a portal travel agains walking 128 Blocks for each part of the route. (And I think the most players would aggree)
And Farming thausends of ice blocks only to repair already working portal routes would take a gigantic effort in a big world.
I think you missunderstood the comment from [Mojang] Grum (Erik Broes) .
He yust said yust said "non-scaled radius" is fixed.
That means it is intended that the radius in nether must be "scaled" (overworld radius divided by 8).
This issue here handled exactly the problem that for nether and overworld the same radius was used (non-scaled).
But grum did not tell anything about which nether radius is correct.
To make that clear on the code from MC-197538:
Before 1.16.2 it was something like:
int radius = 128;
That was wrong because it created useles portals because it did not detect liked portals in overworld in a range between 128 and 1024.
The problem was that the radius in overwodl was to small.
Since 1.16.2 the code is:
int radius = inNether ? 16 : 128;
Here the scaling is correct, but I say the changed the wrong value, because that causes that portals in nether between a range of 16 and 128 are not linked.
The problem now is that radius in both worlds is to small.
So I think the correct code should be:
int radius = inNether ? 128 : 1024;
Because it fixes the bug and all portals will be linked like they where linked before the bug.
No, I didn't misunderstand. Remember, it isn't only what he said, but also what he did.
He posted that the non-scaled radius has been fixed, and closed the issue as works as intended.
That issue was that the radius in the nether is now 16 blocks.
If it was on MC-149705 you would have a point, but it wasn't. It was on MC-197538, which was specifically focusing on the radius in the nether being 16 blocks instead of 128.
This collectively indicates that the range of 16 in the nether is intended.
It is your opinion that the radius in the overworld was too small and the range in the nether correct.
I find it extremely unlikely that they intended for the range in the overworld to be 1024, with the nether being 128, when they have explicitly changed the code to make it 128 in the overworld and 16 in the nether.
It isn't a case of they made a change to the code and it had an unintended consequence of lowering the range in the nether to 16.
Instead, someone put in those numbers. That is clearly intentional.
So this clearly indicates that it is now working as they intend it to.
That means it wasn't wrong because it created unnecessary portals in the overworld, but because it created portals too far away in the nether. It wasn't wrong because it was searching too small an area in the overworld, but because it was searching too large an area in the nether.
The problem now is that it doesn't work the way you want it to, which is not actually a problem for the game. It doesn't actually mean it is not working the way the dev's intended.
That means it isn't a bug that the range is so small, it is you wanting the range to be larger, which is a feature request.
And no, it previously being larger doesn't mean it is a bug either. Or do you think the texture changes are a bug, and the introduction of new mobs are bugs? Because in both cases the game doesn't work the same. An intended change is not a bug.
This has been fixed at some point, see MC-197538
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
The bug
In 1.16.2, Java Edition updated portal mechanics with two major new features:
- The search radius is now proportional to the dimension scale factor, meaning portals will only search a range of 16 blocks in the nether, compared to 128 in the overworld
- Portals use the POI system to cache links, meaning two portals that are linked will stay linked until one of the portals is destroyed
These changes were not ported to Bedrock Edition, meaning the confusing behavior described in MCPE-39609 still persists.
More information about this change can be found in MC-197538
![[Mod] j_p_smith](../../../data/avatars/users/92851.png){kind=small}
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!
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:
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.
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.
This is indeed correct, the old bug of a non-scaled radius has been fixed.
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
@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.
@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.
@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.
@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.
@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.
@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.
@kittycatkenobi 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-203285When 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.