When using a nether portal to travel from the nether to the overworld, the game positions the player into the corner position of the overworld nether portal. This issue applies to all possible portal frame sizes, and is most noticeable as an issue when creating large portal frames, as you are spawned in the corner of a large nether portal, as opposed to the middle of it.
Things worth noting:
When traveling from the overworld into the nether, the positioning is always in the middle.
The portals behave in this manner even when perfectly linked through coordinates (with overworld X and Z divided by 8).
Occasionally, the player is placed near the middle, but seems to happen randomly with no apparent variable.
In the Java version of Minecraft, the player is spawned in the middle of the portals.
Steps to Reproduce:
1. On a creative world, create a 11x11 portal frame, ignite it and enter.
2. Once in the Nether, rebuild the portal into a 11x11 frame (optional but demonstrates the spawn positioning), enter the portal again.
Observed Results:
The player is spawned in the corner of the portal when traveling from nether to overworld. This issue does not happen when traveling from overworld to nether, and the player is instead spawned in the middle. The position from which the player enters the portal doesn't affect the spawn positioning that is observed.
Expected Results:
The player should spawn in the middle, like they would when entering the portal from overworld to nether (assuming a 11x11 frame in the nether), and like it would work in Java.
Comments 3
Thank you for the in-depth explanation. Yes, I didn‘t account for chunk borders, so the results might differ when that‘s considered. When it comes to the Java disparity, I created portals in different locations and chunks in the similar method described above, and the player was always spawned in the middle. So the coincidence of crossing chunk borders is possible but unlikely.
Is this game behavior going to be changed (if reasonably possible) to make the player spawn in the middle location of the portals without the effect of chunk borders? Its a very niche issue, however I encountered it when trying to build a large nether portal frame on a survival world, where this behavior is a nuisance as the player is spawned in the corner.
I've been able to test Bedrock vs. Java with portals that spanned roughly -6 X to +6 X in the overworld and nether. In Java it seems like the game tries to put you at the same relative spot in the exit portal as where you went in to the first portal. In Bedrock there is some variability and a tendency to put the player at one of the corners. For example, in Bedrock going in the nether-side at 0 X would usually put me out at 3 X overworld-side, but sometimes at 6 X. Going in at -4 X nether-side would send me to -6 X overworld-side, but going in at -6 X overworld-side would send me to 0 X nether side. I also tried expanding the overworld portal to span -10 X to +10 X. Then going in at less than about +/-5 X overworld-side would send me to 0 X nether side, but coming back from +1 nether-side would send me anywhere from +3 to +10 overworld side.
I did a final test with nether-side portals at X = 100 to 101, and overworld portals at X = 796 to 797.
Java: 100 --> 796, 101 --> 797, 796 --> 100, and 797 --> 101.
Bedrock: 100 --> 797, 101 --> 797, 796 --> 100, and 797 --> 100.
Conclusion: in general, Java portals send you to the same relative position within the portal on the other side, Bedrock portals send you to the closest part of the portal to the exact converted coordinates on the other side (which usually is a corner, unless you've taken care to exactly align your portals).
This difference does not qualify as a "parity issue" because it older than the Buzzy bees update, so it could be considered a feature request. However, I am confirming it as a possible bug for the developers to assess because
the Java behavior is more intuitive, and
the Bedrock behavior can make it cumbersome for players to set up portals where you come out of the middle, which you might want to do for aesthetic reasons or for practical reasons when working around existing natural generation or builds.
You mention:
This almost assuredly occurs only when the portal crosses a chunk border. When comparing results in your tests of overworld-side and nether-side portals, have you taken chunk borders into account?
The game stores portal location data as the NW coordinate plus length and direction (X or Z) that it extends. The described behavior occurs because it sends you to the stored portal location. You can confirm this using "ghost" portals (MCPE-73179). I'm not sure why the offset occurs when a portal crosses a chunk border, though I'm sure it occurs when the coordinate where you enter the portal in one dimension is closer to the south or east side of the exit portal in the other dimension. It may occur when that chunk loads before the actual portal chunk. Or, it may be due to the game using the portal data first to determine which chunk to send you to (choosing the chunk closest to the converted coordinate into which part of a portal extends), and then second searching for a portal block in that chunk by reading the chunk's block data in order (starting from the portal's Y position), which would mean it always finds the NW portal block in that chunk first. (I am speculating this because third-party tools show that when entities are stored in "limbo" waiting to be loaded into the other dimension from a portal, their position is stored by chunk, not by discrete coordinates.)
I cannot vouch for the Java disparity reported here since I have no experience with Java Edition. It is possible, though, that Java portal travel behaves exactly the same way and the test in Java just happened to be done with portals crossing chunk borders.