Player facing changes when passing through nether portals in certain cases
When passing through a nether portal either to or from the nether, the player's facing direction is not preserved. It always turns the player 180°.
This is important to those of us who have very carefully oriented our portals for fast travel.
Linked Issues
testing discovered1
is cloned by1
is duplicated by7
MC-12615Fix Nether Portal orientation (the portal's itself on creation, and Steve's upon traveling)DuplicateMC-19748 x and z axis do not relate between overworld and the netherDuplicateMC-32688nether portal orientation changesDuplicateMC-35950Entering The NetherDuplicateMC-79095Nether portal player orientationDuplicateMC-2336Player orientation changes when traversing portalsDuplicateMC-2446Portal OrientationDuplicate
- Fixed
Steve Blanding![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png)
[Mojang] Nathan Adams- 137
- 27
- Confirmed
1.4.1 - 1.8
1.4.1 1.4.4 1.4.7 13w01b 13w04a 13w10a 13w10b 1.5 1.5.1 1.5.2 13w19a 13w21a 1.6.1 1.6.2 1.6.4 13w38c 13w39a 13w41a 13w42a 13w42b 13w43a 1.7.1 1.7.2 13w47a 13w47b 13w47c 1.7.4 14w02b 14w02c 14w03a 14w03b 14w04a 1.7.5 14w11b 1.7.9 14w20b 14w21a 14w21b 1.7.10-pre1 1.7.10 14w29b 14w30b 14w30c 14w32a 14w32b 1.8-pre3 1.8- 1.8.1-pre1
Created Issue:
Player facing changes when passing through nether portals.
When passing through a nether portal either to or from the nether, the player's facing should be preserved. In the latest build, the player's facing is changed.
This is important to those of us who have very carefully oriented our portals for fast travel.
This used to work properly in 1.3.
is duplicated by
is duplicated by
Oh well, it happened to be almost on top of my todo list anyway, just had to find the correct seed...
Affects 13w10a.
is duplicated by
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
is duplicated by
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
is duplicated by
is duplicated by
Cannot reproduce in 1.7.9
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
Fixed in 30c!
Good thing that one of the oldest bugs has finally been laid to rest!
[Mojang] Nathan Adamstesting discovered
Player facing changes when passing through nether portals.Player facing changes when passing through nether portals in certain cases
relates to
relates to
is duplicated by
relates to
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
relates to
When passing through a nether portal either to or from the nether, the player's facing
should be preserved. In the latest build, the player's facing is changed.This is important to those of us who have very carefully oriented our portals for fast travel.
This used to work properly in 1.3.
When passing through a nether portal either to or from the nether, the player's facing direction is not preserved. It always turns the player 180°.
This is important to those of us who have very carefully oriented our portals for fast travel.
![[Mod] bemoty](../../../data/avatars/users/50554.png){kind=small}
is cloned by
This is a duplicate of MC-3.
Duplicates MC-3
Closed this issue as it duplicated MC-3. In the future, please search before you post.
If I remember it right, this is because the portal creation routine does not check for full portal shape before deciding which way it could possibly be. Having the extra obsidian there confuses the routine so it just bails out, and thus the default action (of starting a fire) is launched instead. Edit: I remembered it correctly. It only checks 4 neighbor blocks for being obsidian, and if there is at least one obsidian block for both orientations, it simply (and incorrectly) decides a portal is not possible.
I might take a look on this, as it may affect another portal bug (MC-3), too. Edit: Does not affect MC-3.
Duplicate of MC-3, please use the search function to see if your bug has already been submitted. Currently over 54% of tickets are being closed as duplicate.
@Loren: You might want to adjust the issue title, as it seems (according to other comments) that it is not related to the actual zombie sieges, but to zombie's path finding in general (or at least when related to attacking or something).
@Jack: 3 weeks and 20 votes? Pfft. Check the most popular issues -list; more than half a year old issues and 395 votes and still there.. or MC-3, just as old with 77 votes and source code for fix is provided, still there... However, I have noticed that recently introduced bugs tend to get fixed soon(er) than the old ones, and this one is quite severe too, so I think there is hope.
I think the reporter is talking about the orientation of the portals, not their position. As such, it's probably a duplicate of MC-3.
Duplicate of MC-3 - If you have not, please use the search function in the future, to see if your bug has already been submitted. If you could not find the original report, please comment with the keywords you searched for.
While testing the fix of MC-3, I found this bug. I then tested it back in 1.8 and it was still there, so I don't know how long it's been around or even if there is a ticket for it already (I tried to look it up but couldn't come up with anything).
Anyways, when you travel to the Nether, generating a new portal, and build a new portal, even just a couple blocks away, and destroy the old one, the overworld portal doesn't adjust your destination coords in the Nether, placing you where the old one was.
To reproduce, build a new Portal in the overworld and travel through, generating a new portal in the Nether. Now build a second portal in the Nether a few blocks away and destroy the first. Now if you travel through the new portal to the overworld and then back again, it will place you where the old portal was, even if it was destroyed. The game also neglects to generate a new portal in that location, so you just spawn in with no portal blocks touching you.
This bug is now present in 1.8-pre3 since dinnerbone fixed MC-3. I tested my portal created in a snapshot prior to the 1.8 release, and I now take damage after I get to the nether, depending on which of the two blocks I stand in when entering from the overworld.
Things to note: Prior to the fix for MC-3 when entering the other dimension when using a portal, you would still be in the portal, now you are no longer in the portal. I believe that this is the source of the damage bug as the player placement is now outside the portal and sometimes this might be inside a block. This could be fatal for the first trip to the nether if you're over lava so I really hope this bug gets escalated!
Both portals are facing north-south. When I enter the overworld portal standing on the left side while facing south, I exit the nether portal on the left side but one block over and forward, facing north. If I enter the overworld portal standing on the right side while facing south, I exit the nether on the left side, but TWO blocks over and forward, which for this portal was a wall so I took damage. My portals are the traditional size of 5 tall by 4 wide with the interior of the portal being 3 tall by 2 wide.
Copied this over from MC-793 since this seems to be the right place.
This bug is now present in 1.8-pre3 since dinnerbone fixed MC-3. I tested my portal created in a snapshot prior to the 1.8 release, and I now take damage after I get to the nether, depending on which of the two blocks I stand in when entering from the overworld.
Things to note: Prior to the fix for MC-3 when entering the other dimension when using a portal, you would still be in the portal, now you are no longer in the portal. I believe that this is the source of the damage bug as the player placement is now outside the portal and sometimes this might be inside a block. This could be fatal for the first trip to the nether if you're over lava so I really hope this bug gets escalated!
Both portals are facing north-south. When I enter the overworld portal standing on the left side while facing south, I exit the nether portal on the left side but one block over and forward, facing north. If I enter the overworld portal standing on the right side while facing south, I exit the nether on the left side, but TWO blocks over and forward, which for this portal was a wall so I took damage. My portals are the traditional size of 5 tall by 4 wide with the interior of the portal being 3 tall by 2 wide.
-and-
And here is some more information - One of my portals in the nether had the four blocks immediately in front of the portal (at the same level as you would be standing on the obsidian of the portal floor) filled with a half slab, which means before this breakage, you would exit the portal and then rise up a half slab height. After the bug was introduced, you now go somewhere else, which in my case is below the portal and into the lava pool underneath 
Should be (mostly) fixed with MC-3, please read the last comments there and respond if that describes this issue.
This is technically a Dupe of MC-3, but since that issue is RESOLVED without the actual bug being so, I guess I'll reignite this issue here.
To summarise:
When traveling to or from the nether the player, in general, gets rotated 180 or 90 degrees. (this is a feature/intentional and not the here mentioned bug!)
This is intentional, but a bug occurs in the latest version (18w07c) which causes the player to not get rotated in one specific case.
This bug or bugs related to this causing simular issues have been in the game for a long time and the specifics of when it occurs and what rotation is or isn't applied may change as well.
But for now it seems to cause the player to rotate 0 degrees every time they travel from the overworld to the nether through a set of portals of which both portals are along the z-axis.
This is a bug, because it's inconsistent as it only occurs in this very specific case.
For some more details. When this bug occurs (traveling to the nether in the specific case) the player may also get displaced 3 blocks in the positive z direction in the nether when they enter the dimension.
So instead of entering the nether inside the portal you entered, you get transported 3 blocks south of that portal.
I myself don't understand why this it happening, but it might as well be a side effect of the main bug here or maybe (very maybe) a whole new bug alltogether.
I tested many different cases with this bug, earlier reported for 1.11.x and 1.12.x, inside 18w07c.
The method I used was as follows:
One portal in the overworld and one in the nether. Take note of the axis each portal is facing and then go through the portal facing south (0 degrees), then back again facing south and then west etc. Then rotate one of the portals and repeat until all four combinations of portal orientations are checked.
I took note of the rotation that was applied to the player after traveling through the portal under those specific circumstances.
I noticed that all outcomes where consistent but one scenario. That's the one described above.
Posted a comment about this on MC-3
This is still an issue in 18w07c, please see this comment on MC-3 for more depth 
https://bugs.mojang.com/browse/MC-3?focusedCommentId=436287&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-436287
Yes, the user is rotated 180 degrees when traveling through a portal and this is either not bad enough to be changed or intentional.
Dinnerbone made a comment about this in MC-3:
https://bugs.mojang.com/browse/MC-3?focusedCommentId=204455&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-204455
It's another dimension so why does north here have to be north there?
- Create a 2x3 portal so that the inner portal blocks are on Z=0 and -0.
(In the nether, make sure to move the portal if it was created in the wrong place.) - In the overworld, walk on Z=0.5 into your portal.
- In the nether, notice that your Z is still 0.5, instead of the expected -0.5.
- In the nether, walk on Z=0.5 into your portal.
- In the overworld, notice that your Z is now -0.5 as expected.
At a guess, this could be caused by the which block Minecraft uses to calculate the portal's position.
I recorded footage but the 10MB limit is too small, by the time I have compressed it enough the video is just a blur.
I also noticed that the player would occasionally face the wrong way after teleporting, like MC-3 and MC-105207.
I am creating a plugin that allows minecarts with passengers to travel through portals, hence the tracks - however, during the test above I am flying on a vanilla world. I also recorded footage with the plugin enabled. It shows that entities travelling along the rail and into the portal are not visible in the nether but will somehow still look like they are looping in the overworld (albeit on alternating sides of the track due to the bug). This only happens on the axis, the same setup away from the axis works perfectly.
This could be intended, see MC-3 (which was fixed)
I think that would be bad because, the way it is now, if you place your portal against your wall, you don't have to turn around when you're coming out. I think this is better then if the rotation is the same.
I'm not sure from his comment if Joshua understood what the bug is or not so just to be absolutely sure that I'm being clear: If you enter a nether portal facing WEST, you should come out the other end facing WEST; if you enter facing EAST, you should come out facing EAST; and so on. That is the way it behaved in the past. In 1.4.1 pre, if I enter a portal facing WEST, I may come out facing NORTH. I haven't worked out all the contributing factors but it seems to behave differently in different circumstances.
Mojang has stated that they changed it to work like portals in the Portal game. So your relative rotation and not the absolute rotation is preserved. For example if your overworld portal is facing north and your nether portal is facing east, going in the overworld portal facing north should probably change your rotation to east.
Well if that was their intention then it's still a bug because it doesn't work that way either.
The fact is, this used to work properly, there was no good reason to change it, and now it's broken.
It seems to be inconsistent dependent on whether you are headed to the Nether, or to the Overworld.
I have a portal in Overworld which I head South into. When arriving in the Nether I am still heading South.
When in the Nether, I head North into the same portal, I'm now facing South when trying to exit the portal in the Overworld.
I'll summarise this with (
indicates error):
Overworld South -> Nether South
Nether North -> Overworld South
Testing the same portal but facing different orientations gives me:
Overworld North -> Nether North
Nether South -> Overworld North
Overworld East -> Nether East
Nether East -> Overworld West
Overworld West -> Nether West
Nether West -> Overworld East
My two portals are up against walls so I can only enter them from one direction. The directions above are the ones I was facing, not the direction I was moving.
Combined with https://mojang.atlassian.net/browse/MC-180 this can get quite confusing especially if the portal animation has completely obscured your view and you're left blindly trying to get out of the portal.
Can confirm this occurring in 1.4.2
The above comment (Jon's) seems typical when in gamemode 0 (I get the same if not similar results). It does seem a little more stable directional wise when in gamemode 1 (creative), however i did notice that i was brought out at an odd facing sometimes, unfortunately it seemed random thus unrepeatable.
Early testing seems to confirm Aidan's thoughts, Creative vs Survival does seem to make a difference.
If the portal remembered its "favored" direction, based upon what side of the portal you were when you ignighted it, that would be great. It would allow you to put one portal facing north, and expect to come out facing east each time. But this isn't what's happening here. If the portals face different directions, you'll come out of the portal facing the same way no matter what side you go through. If this can't be fixed, I'd prefer it if your facing was preserved. At least that way you'll have predictability.
When I set up my nether portal originally, I was facing EAST going in, and I would come out facing EAST in the Nether. When I came back, I was facing WEST going in, and would come out facing WEST. This is what I wanted and it worked fine.
When 1.4.2 came out, I'd still go in facing EAST, and come out facing EAST in the nether. But coming back, I'd be facing WEST going in, and come out facing NORTH, which was sideways in the portal (I went in normally)
I moved the overworld portal to see if I could fix it. when I enter facing SOUTH, I come out facing EAST. This matches the "like Portal (the game)" idea because I'm at least not looking at the side of the portal. However, when I go in facing WEST, I come back out facing EAST, which is neither the same facing NOR is it "correct" in the Portal (the game) sense, as I'm facing the side of the overworld portal.
Is this still a concern on Minecraft 1.4.4 Pre-Release?
Yes. This bug is not fixed in 1.4.4.
Confirmed again in 1.4.4 Pre-release - Single player.
Survival Mode - Changes direction very frequently. Particularly when facing the sides of the Portal rather than straight in.
Creative Mode - Changes direction far less often. Seems to happen more often if you turn as you enter the Portal blocks - Possibly determining your rotation as you touch the block rather than when you are teleported.
Steve, I will update this issue to reflect the affected version field. Please keep track of this bug and update accordingly for new releases/pre-releases as they come out.
This helps us and Mojang know which bugs affect each version, and how many versions in which this has been an issue. If it remains a bug for 10 versions, there should be 10 versions listed in the "Affects Version/s" segment of this ticket. Comment if more information is needed, but a simple update of that field will suffice.
this bug is really annoying because i have carefully constructed and placed my portal so i will be able to have one way in and one way out. i have built it so that people would come out and see a cool thing i had built but now its all messed up and i comeout facing the wrong direction now. i head south in the nether and come out facing south in the over world and i head north in the nether and come out south in the overworld still.
This bug is still present in 1.4.5
This issue seems to be affecting which portals link to which. I have a portal at the exact matching coordinates in the nether but the game seems to prefer linking with a different portal that is oriented 90 degrees off and located much farther away.
@Cory please confirm, when you say "Exact Matching Coordinates" do you mean that the numbers X,Y,Z are the SAME, or that the numbers in the Nether are 1/8th the numbers in the Overworld? A portal at 80,X,160 in the Overworld would match with a portal at 10,X,20 in the Nether. They do this so that you can use the Nether as a fast-transit system on large worlds.
1. Leave Nether via west/east facing West @ -89.49350, 80, -20.30108, portal is actually -89, 80, -20<>-21
2. Arrive in Overworld at west/east facing North @ -713, 21, -167, portal is actually to my right on -712,21,-166<>167
3. Head back to Nether via the arrival portal facing East @ -712.53436, 21, -167.700
4. Arrive in Nether at new north/south portal facing East @ -64, 38, 17, portal is to my left
5. Leaving Nether via this new north/south portal places me at the expected portal near -512, Y, 136
I realize these portals are "close" but I never had an issue before this patch, and have even used portals much closer as long as they matched the coordinates (* or / by 8) exactly.
Can you replicate this issue in latest version of the minecraft? If so, can you update the ticket?
I am seeing this in 1.4.6.
thrown items are also exiting at fixed point and fixed direction.
They preserve only the velocity value.
Should a separate ticket be filled about that?
This bug is still present in the latest snapshot (13w01b).
A bit kinky code to read, but this is what understood for 1.4.7 (still suffering from the issue)...
The failure seems to be in (Using MCP namings with some own interpretations) Teleporter.placeInExistingPortal() method, which tries to find out which way the portal is built. Unfortunately, there is nothing stored that would allow it to differentiate whether it is east or west, or whether it is north or south; the portals being symmetric gives no clue, and there is nothing separate info saved anywhere.
It first gets one portal block to use as a sort of "pivot", and then the "exit direction" is defined so that the other (non-pivot) side of the portal would be on the left.
The result depends on which side of the portal it happens finds first, to use as the pivot. When the portal is well matched (in horizontal coordinates), it will use those exact coordinates for the "pivot" coordinate. When not so matched, it will use the north-west-bottom-most portal block as the "pivot".
And there in lies the rub (or something). Since it always finds the NW-most portal block, only two of the four outcomes are possible. Unless it is an exact match, which case I haven't analyzed yet.
Currently, there simply is not enough data to do the "Portal-game-like" behaviour properly.
(EDIT4: Seems that it is the source portal's details that affect the facing for the destination portal or something. It is kinda messy... I'll give up for now, no point in trying to over-analyze code that isn't going to really work in any case.)
The best compromise idea (for a fix) I have is to check if either side (forward/backward) of the portal has solid blocks (wall), in which case the direction detection is obvious; you wouldn't want to run into a wall. If the path is clear on both sides, keep the facing unchanged (and leave the problem of the case of having 90 degree rotation between entry and exit to the player).
(EDIT: actually, ... "if either side has non-empty block" would be better rule, so as to not run into lava etc. either.)
(EDIT2: and if both sides are non-empty, then again leave the facing intact and as a headache for the player.)
(EDIT3: occasionally I get 90 degree facing change, even when not doing any changes with the portals...)
Markku, thanks for the detailed comment. I suppose I could live with the behavior you describe although I still think that it's over-thinking the problem. IMHO, trying for "Portal-like behavior" was a misguided, although well-meant, idea. It was a thoroughly unnecessary change. It's just so much simpler to count on having your facing preserved whenever you go through any portal. Trying to achieve "Portal-like behavior" just introduces unnecessary complexity which is bound to lead to bugs (as we have seen).
The benefit from the Portal-like is that it allows, in some cases, to fit the portals nicely into walls. I'd sure like that, and it is easy to implement, a 15 minute thing if not less. Well, 30 minutes with testing.
And here is the code changes for my proposed compromise "fix". Not 100% tested, but seeemed to work with both identically faced portals and 90 degree rotated portals. The code tests only the lower 2x2 blocks for emptyness on each side.
Current code:
... int mainDirection = -1; if (this.worldServer.getBlockId(portalHorX - 1, portalVerZ, portalHorY) == Block.portal.blockID) mainDirection = 2; // north if (this.worldServer.getBlockId(portalHorX + 1, portalVerZ, portalHorY) == Block.portal.blockID) mainDirection = 0; // south if (this.worldServer.getBlockId(portalHorX, portalVerZ, portalHorY - 1) == Block.portal.blockID) mainDirection = 3; // east if (this.worldServer.getBlockId(portalHorX, portalVerZ, portalHorY + 1) == Block.portal.blockID) mainDirection = 1; // west ...Fix
(Pardon the very "brute force and ignorance"-solution and my swapped Z and Y, its 4:30 in the morning, need to get some sleep...)
... int mainDirection = -1; if (this.worldServer.getBlockId(portalHorX - 1, portalVerZ, portalHorY) == Block.portal.blockID) mainDirection = 2; // north if (this.worldServer.getBlockId(portalHorX + 1, portalVerZ, portalHorY) == Block.portal.blockID) mainDirection = 0; // south if (this.worldServer.getBlockId(portalHorX, portalVerZ, portalHorY - 1) == Block.portal.blockID) mainDirection = 3; // east if (this.worldServer.getBlockId(portalHorX, portalVerZ, portalHorY + 1) == Block.portal.blockID) mainDirection = 1; // west // Look for possible obstacles/clear paths in the forward and backward directions: mainDirection = checkDirection(mainDirection, portalHorX, portalVerZ, portalHorY); ...Add the new method...
In short:
If the portal has both sides blocked or both sides clear, it works like "old times"; absolute facing is retained through the teleportation and motion is stopped.
If one side is blocked, the facing is handled relatively, as if "forward" direction is to the open side; if you went backwards into the entry portal, you will also get backwards out from the exit portal; if you went in sideways, you'll also get out sideways.
It may still need some more testing and tweaking, but at least it should not work any worse than before.
this is very frustrating because it ruins the idea of having a minecart chest transport line from the overworld to the nether and vice versa
Confirmed to still be a bug in 13w04a
I thought it might have been due to how far through the Portal I stood, but that didn't seem to matter either.
I can confirm that this issue still exists in 13w06a SSP. For instance i enter an overworld portal facing South, and arrive in the nether facing West. Some journeys leave my character not facing out, but facing the frame of the portal.
I am not using tweeter, but I wonder if someone with an account could ping Dinnerbone/Jeb on this issue. They have stated several times that the community should put some effort in describing bugs here, and here only, but this one has been reported consistently for the last 4 months and as far as I can see nobody in the Mojang team gave it any attention. Maybe they are not aware of this bug at all...
There are plenty of "old" bugs here in JIRA which have no indication of Mojang activity. However, that does not mean that they wouldn't be aware of the issues, as there is nothing which would tell about just reading... If one goes tweeting about it, there is like several hundred other issues to tweet about, too.
The way to know Mojang is "on it" would be when the issue is assigned to a Mojang employee to fix it, but typically they skip even on that, and the only notice we ever get is the (hopefully) final update in status to "fixed". Usually they do not even tell how they fixed (in case there was multiple possible solutions).
Edit: this issue happens to be quite high in the list of most "popular" (or more correctly "infamous") issues, so I'm pretty sure Mojang is aware of this particular issue.
Can we get a confirmation of whether this still happens in 13w10a and an update to the affected version?
Feel free to test it by yourself and comment here "affects ..."
Confirmed to still be a bug in 13w10a
Affects 1.5.
1.5.1, same here. While travelling from Overworld to the Nether orientation correctly changes from 0 to 3 to mantain portal placement direction. However, on the way back player orientation doesn't change (still 1) and I finish transfer looking straight to portal border.
affects 1.5.1
I'd also add that when the game automatically "generates" an "exit" portal (either when going from overworld to neter or the oher way around), because there is no already active portal to exit out of, then the "new" portal should ALSO have the same orientation as the entrance portal. This would avoid entering into a portal, and then exiting while facing up against the exit portal's side pillar.
Actually, if the fix shown by me would be implemented, there is no need to change the way the exit portal is created (in order avoid facing the pillar, that is).
Of course, it might still be convenient for other reasons to have the gates with same orientation, but, that would be another issue (a feature request, really) and implementing it wouldn't be as straight forward as it first sounds.
Latter part refers to the possibility of this: assume two somewhat nearby overworld gates built with different orientation. Enter the other gate, it creates exit gate with its own orientation in the nether. Thus the nether gate orientation will not match the orientation of the other overworld gate, which would link to the same nether gate...
Feel free to elaborate better orientation rules, but please do so in the forums (this issue has already enough comments as is).
Markku, your fix doesn't actually take into account when the destination portal's general orientation (north-south-alignment vs east-west-alignment) is different from the entry portal. Things are a little more complicated than that. So I think the player's actual direction at the "instant" of the actual teleportation should be taken into account too.
It should go like this:
When entering a portal, there is a rather lenghty portal animation, which is made of 3 parts:
What is of interest here is the 2 following things:
Let's suppose that, when facing a portal, the base portal block at the left side of the portal is the "first" block, and the other portal block is the "second" block. Right before "leaving" the entrance portal, the game should preserve the following information:
Orientation is different from Direction. Orientation is a binary value: Either a portal is made to be entered from the "north or south", or it is made to be entered from the "east or west".
Then we determine the entrance portal's actual favored direction the ideal "player walking-out direction":
We check all blocks in a 3 high by 2 wide (ie. the size of the portal's "doorway") by let's say only 2 blocks "long". We sum up the total number of blocks that are Air blocks, separately on each side. The side with the most air "wins" as the favored direction. In case of a tie, we use the reverse of the player's orientation instead (not in degrees, just the most general south-west-north-east direction). We use the reverse because the player is currently not walking "out", but walking "in", and the favored portal direction must always be an absolute ideally relative to the portal itself, not the player.
The we do actual the change of world and coordinates.
Then we do the destination portal computation:
If checking a total of 36 blocks for the presence of Air seems too long, then instead these 36 blocks could be checked a few at a time each tick during Part I. So what if another player or whatever changes the layout right then? Odds are, a layout change like that, that would ALSO be big enough to change the portal's favored direction, would happen only very rarely. And even if it did, well, that'd be just one freak occurence, easily attributable to the portal having tried to "do it's best but got momentarily confused by the changes", the result not hurtful just an incorrect exit direction happening once. And the next time you'd use the portal, things would then be ok (unless the same major layout changes occurs again – now, twice in a row, that would really be on purpose).
ooooooooooooooooooooooooooooooooooooooooo
The IDEAL fix of course, would be to use Block Data Values for Portal blocks.
Upon "lighting up" the portal, if it was done using flint & steel, then the player location is checked to see wether it is from the front or back of the portal, determining which of 2 possible "favored portal direction" (defined as when "coming out" of the portal, and the reverse direction for coming into it, of course). If another event lit up the portal, then the default favored portal direction is determined like in the explanations furthewr up above. In case of a tie, since there is no player present, a random selection between both possibilities.
Each of the generated Portal blocks would simply get a value:
0 First lower row block, on a portal with favored exit direction going south.
1 First lower row block, on a portal with favored exit direction going west.
2 First lower row block, on a portal with favored exit direction going north.
3 First lower row block, on a portal with favored exit direction going east.
4 Second lower row block, on a portal with favored exit direction going south.
5 Second lower row block, on a portal with favored exit direction going west.
6 Second lower row block, on a portal with favored exit direction going north.
7 Second lower row block, on a portal with favored exit direction going east.
8 Middle or top row portal block (not used for determining actual transport, only for decoration).
Then it would really become be a piece of cake to determine the player's facing using that data for determining destination portals and teleports.
Patrick, my fix does handle all combinations of portal orientations (using your terms). However, it does not handle directions, as there is not enough information in the game to do so (as you also noticed). I did not even try to add that information... but the solution I made is enough to fix most of the complaints that were reported in the comments.
I did not claim my fix would solve this 100% completely, it is a compromise. But it does fix the main issue about player facing changing apparently erratically. It tries its best to do following things:
1) Player does not walk into wall or portal frame when exiting. (Caveats, if he moves in sideways/backwards, things may not work as expected.)
2) The same direction is kept. (Go in west, go out west).
The rest is about handling cases where these desires can not be met, and a particular "old times" case (when both sides on the exit are clear).
Since portal travels are infrequent (from a computer's perspective); one could easily check hundreds of blocks without player noticing any delays or lags. However, for simplicity of the provided code, my fix only checks very few blocks around in order to detect a blocked side. It could be made better (trivial thing), but it is not likely needed, as gates are made (or at least improved later) by players - typical portal placements will be handled by that code sufficiently (and at least better than now).
Note also that there is no need to consider the timings of portal travel. At least not for my fix, as it is merely a "fine-tuning" of the current functionality.
If it was up to me, I would add the direction information for portals, e.g. record the side of the "igniting" player as the "primary side". Such info would indeed make the case much easier. But those changes are too large to be dropped here in comments. I'll leave large changes like that for Mojang.
Good heavens. So much arguing over what would be just so darn simple if the game never changed the player's orientation at all. I still fail to understand why it was ever changed. Enter facing N, exit facing N. What's so hard about that? It's predictable. It's understandable. And it's trivial to orient your portals to exploit it.
Can we please just put it back to the way it was and stop trying to engineer overcomplicated solutions to something that was never a real problem to begin with?
Steve: There were problems with this to begin with, otherwise it would not have been changed.
It is not always trivial to orientate portals any way liked, as sometimes one wants to have them fit the environment, without changing that environment radically. (Just as an example, say you want a large temple with door facing east (rising sun) and the portal to be visible at the west end of that temple. Then, in the Nether, the local area happens to be such that the portal would give the best view when the player steps out facing south...)
And my fix is not even close to an overcomplicated solution (at least not for me, could be for you, but since I've already made and tested it, you don't have to worry about it). This issue exists because the current, relatively simple code just has a bug. There is now a relatively simple fix. There are other relatively simple fixes. And there are other, more complicated fixes. Implementing any fix is a good thing (as long as it is tested properly and does not make any part of the functionality worse than before).
And my fix gives a very easy and predictable behavior for the portals, too. If the portals are placed with the same orientation (trivial as you say), then yes, enter facing N, exit facing N. You would be happy.
And if the portals are oriented differently, and player enters "normally" walking in, he will exit the portal "normally" walking out (instead of walking into the portal frame). Even when one side of the portal would be against a wall (e.g. portals embedded in that wall). Thus, most other players would be happy, too.
A fix is already coded and tested. It would make you happy, it would make most other happy, it would make pretty much every player at least less unhappy than they are now. Any objections still?
(The "arguing" we're having with Patrick is simply about trying to find mistakes each others stuff, how to make it even better, and more or less constructive criticism about the ideas, etc... You can safely ignore it all, lay back, and enjoy the results some day - or simply ignore the improvements and keep working with the portals just like you wanted.)
Markku,
I'm not arguing that your proposed fix is bad. (In fact, I'd be quite happy if Mojang would implement it.) I'm arguing that if your fix seems too difficult or risky or time consuming to the developers, they would be far better served to revert to having NO facing changes whatsoever. At least that made some sense. The way it is now makes no sense whatsoever.
And despite what you may say, it is NOT clear to me that even a significant minority of players felt there was any problem at all with the original behavior.
Just trying to help here!
For all non-coders, I'd rather see Markku's fix than none at all, really.
Still, Marrku, please check carefully the program variable state by going step by step through the effect of the code fix, and you'll see that wether you come out of the portal's "left" side or the "right" side, the actual direction becomes swapped, without consideration to wether or not the other world's portal was entered one way or the other.
Let's say you have the following situations:
A pair of North-South oriented portals (i.e. portals normally entered/exited from either north or south) in Overworld + Nether.
Overworld coordinates of base portal blocks (X,Z only) = [+800, +1600] and [+801, +1600].
Nether world coordinates of base portal blocks (X,Z only) = [+100, +200] and [+101, +200].
You come out of the nether portal from block [+100, +200].
Wether you enter the overworld portal from the north or south directions, you'll come out of the nether portal going:
If front is empty and back is empty = Going nowhere (direction -1)
If front is not empty and back is not empty = Going nowhere (direction -1)
If front is empty and back is not empty = Going south
If front is not empty and back is empty = Going north
Now, let's SHIFT the nether portal one block to the west, so that we get:
The pair of North-South oriented portals:
Overworld coordinates of base portal blocks (X,Z only) = [+800, +1600] and [+801, +1600]. Same as in Test case A.
Nether world coordinates of base portal blocks (X,Z only) = [+99, +200] and [+100, +200].
You still come out of the nether portal from block [+100, +200].
Wether you enter the overworld portal from the north or south directions, you'll come out of the nether portal going:
If front is empty and back is empty = Going nowhere (direction -1)
If front is not empty and back is not empty = Going nowhere (direction -1)
If front is empty and back is not empty = Going north
If front is not empty and back is empty = Going south
All 4 lines
"if (frontEmpty == backEmpty) return -1;"
should instead be
"if (frontEmpty == backEmpty) return mainDir1;"
As for the direction swap upon exiting depending on wether you exit from the left or right side portall bock, it is unavoidable unless the game somehow "saves" the direction the player used upon entering the source portal, as my "much more complicated" previous post described.
Steve, simply making zero orientation change would mean that everytime you enter a portal that is oriented one way in one world but that is oriented the other way in the other world, you'd come out face straight against the exit portal's pillar. Irrelevant for those who carefully place their own portals. A big deal for those using game-generated portals, because that orientation is randomly set when the game creates a new portal frame.
Patrick,
At least that was predictable behavior and it was easy to build your portals to accomodate it. Instead we have today's situation, where my carefully placed portals, which used to line up perfectly, now leave me always facing a pillar due to a seemingly random change which seems to have benefited nobody.
There is no way that you can convince me that the behavior we have now is an improvement. If Mojang is unwilling or unable to fix it properly, they should at least put it back the way it was! Even if only until they find the time to implement a proper fix! Please!
Patrick, I was aiming to fix it so that it completely ignores the "left or right" side part of entering the portal; imho it should be irrelevant for the process.
Thanks for the test cases; I did do similar tests (even going in on the left half vs. right half, east vs. west, and walking backwards vs. forwards), but could not find any difference in the results. I may have made mistake during testing, or maybe some other thing was hiding the bug; wouldn't be the first time I thought I had already deployed a change, when it still required a restart.
The reason for those -1's on the main dir are to try keep certain "old style" operation; when the code can not deduce which side is "open" (i.e. both sides are open or both sides are closed), it will not return any "main" direction.
Checking and testing the logic now...
Steve, applying my fix above is pretty much as easy as (if not easier than) to revert the changes back to old behavior. The problem is not that the fix would be too difficult to put in... the problem is time. Mojang hasn't made any fixes for weeks now; they obviously have something else to do for the time being. And this particular issue isn't even close to a "significant" one (although it does have plenty of votes, but that is mostly due to this issue being one of the oldest in this JIRA), so once Mojang gets back to fixing things, don't expect this one to be done first...
Steve, I totally agree with you than simply keeping current behavior is way worse than all of the fixes presented here. Its a typical example of having tried to fix some stuff actually made it much worse. As you say, at least the previous behavior was simple enough to understand. Now, it screws up portals 100% of the time lol.
Mojang has made a lot of fixes in the last few updates, I think. Still, we're due to another release this week I hope.
As for fixing difficulty, I'd summarize everything like this:
Solution #1 - The "Not bothering with it" fix "[The "Mojang doesn't have enough time" no-prize fix]. Can't be easier and quicker than that! Crappy solution tho. Most likely solution to be implemented in the short and medium term.
Solution #2 - The "K.I.S.S. IT" (Keep it Stupid Simple) >Steve's Fix. Super easy, fast, simple. Works only with some carefully placed portals, not those were orientation changes or where you want a definite exit direction. Would be ideal in the short term. Truly simply a "rewinding back a bad update decision", and would be way better than the weirdness we have now.
Solution #3 - The "Best Guess without Too Much Hassle " >Markku's Fix. Relatively easy, wouldn't really take more time than Solution #2 since the code for the fix is already done anyway. Would work for most purposes, especially if the player takes care to make sure exactly one side has "obstacles". Maybe in the medium term. If we get lucky.
Solution #4 - The "True Portals Behavior As It Was Originally Intended" >Patrick's Fix. Most solid and works exactly like the player would expect and intends at all times, even with automatically created portals, not just those carefully placed". Only solution adressing all possible cases but also the one definitely that would be a big step up in the time required to code the fix. Thus, not really likely to occur. At all.
Solution #5 - "We finally fixed the portals in this update!" >Mojang's (eventual) fix. Something totally new that will probably surprise us in many ways probably with nice new and superbly original behaviors and portal features, yet still not quite working like it should anyway. Most probable solution in the long run.
Okay, done with testing with that same setup at 800,1600. I tested north and south straight-walk-in (i.e. no sideways/backwards walking), entering left and right half of the portal, nether portal at 99-100 and 100-101; total 16 cases. Then some more tests for trying one-side-blocked cases and couple rechecks due to getting unexpected results. (Note, I did the testing with fixes on 1.4.7, not against the latest 1.5-series.)
Otherwise it worked exactly as I expected (and as I intended), but:
Also, when the nether-portal was at 99-100, I always exited at 99,200 to nether, not at 100,200.
All in all, my fix was giving the results I wanted (except for the stopping movement). That is, I never ended up facing a blocked side (let alone portal frame), and if both sides were open, I always kept the facing; no matter which direction (north/south) or which half (left/right) I entered. For those parts, the requirements are met.
If I'd do anything more, it would be to make sure the exit position is always in the middle of the portal, at the edge between two blocks (like it is when one side is blocked).
Ah, I finally see now how your code "works as intended"...
... and it is because our "requirements" actually differ a little bit!
=== Your requirements are ===
Requirement Markku #1: The player never exits face up against an obsidian pillar (even when one portal is oriented North-South and the other portal is oriented East-West).
Requirement Markku #2: Whatever opening the player enters (either North-or-south, or East-or-West, according to the portal's general orientation), and whatever "half" of the portal the player actually entered into (left or right), the player should always comes out of the same (the 'best') opening.
--> Markku requirements example: 2 portals: Portal #1 with openings on sides A and B, and Portal #2 with openings on sides C and D:
Then when player enters from "Portal #1 Opening Side A" (through either left or right half)
he would exit out of "Portal #2 Opening Side C" (i.e. the "preferred exit" side)
and when player enters from "Portal #1 Opening Side B" (through either left or right half)
he would ALSO exit out of "Portal #2 Opening Side C" (also the "preferred exit" side)
And in all cases, he never exits facing straight into a portal's obsidian pillar or through "Portal #2 Opening Side D".
=== Meanwhile my own requirements are ===
Requirement Patrick #1: Same as yours: The player never exits face up against an obsidian pillar (even when one portal is oriented North-South and the other portal is oriented East-West).
Requirement Patrick #2: Whatever whatever half of the portal player actually enters into (left or right), the player always comes out of the "best exit" side of the exit portal when he entered from the "best exit" side of the entrance portal, and always comes out of the other opening of the exit portal when he entered from the other oening of the entranve portal.
--> Patrick requirements example: the same 2 portals: Portal #1 with openings on sides A and B, and Portal #2 with openings on sides C and D:
Then when player enters from "Portal #1 Opening Side A" (through either left or right half), which happens to be the portal #1's "best exit" opening side,
he would exit out of "Portal #2 Opening Side C" (i.e. the "preferred exit" side)
and when player enters from "Portal #1 Opening Side B" (through either left or right half), which happens to be the other side of entrance portal,
he would instread come out of "Portal #2 Opening Side D" (which is also the "non best" side")
And in all cases, he never exits facing straight into a portal's obsidian pillar.
Your algorithm merely needs to check out only the neighbouring blocks around the exit portal to determine which is it's "best exit" side, and always use that side.
My version would simply require to also check out the neighbouring blocks around the *entrance portal to determine (in the same manner) which is it's "best exit" side.
Then simply apply directly to the player's facing whatever angle difference obtained between both portals "best" orientation, dephased 180 degrees to account for the fact that the player "entering" one portal is 180 rotated relative to the "best exit direction" of that portal.
In case of a "tie" between both exit directions, a portal's "best" exit direction would always be say always North over South and West over East. Thus, in the case of matched pairs of similarly oriented portals, you'd obtain the extremely natural "enter going north, out going north, but and enter going south, and going south you also go out it".
I think it would be quite simple to do and would allow being able to use all available openings in portals with a much more natural "feel".
Patrick: Yep, I was thinking we had differences in requirements, but I couldn't catch that explicitly until now that you made the above text.
I also considered first to examine the surroundings on the entrance portal, but that would have required even more changes to the code, and they are already on limits of what is suitable to throw in here in comments.
The real fix, of course, as is already mentioned, is to record the portal orientation e.g. by detecting the side of the player relative to the portal at the time of activation, and use this automatic system only for the auto-generated & auto-activated portals (which can be closed and reactivated properly after first pass through). But that is way out of scope for comment-fixing, as it would require changes to saved data etc.
I.e. I'm trying to keep my source code "patches" at the level of minimum that fixes the reported problem, in the hopes that small fixes would be more likely to be taken into the game (less things to check/test). (I have since lost all that hope, as proven by 40+ similar small reported bugfixes still waiting after months...)
Cannot reproduce in the latest version of minecraft
Try again. That time was a little odd, but it's still happening.
Same problem on version 1.7.2
Even if I broke my portal, change the orientation, the glitch is still here
Updated
Is this still a concern in the latest Minecraft version 14w02c? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
The bug is still here in 14w02c.
Still in 14w03b
Still happens in 14w04a too
It blows my mind that the 3rd bug reported on this site has never been even LOOKED AT by a programmer, and the only activity by anybody (other than the people who reported it) is to ask if it's still a problem.
If a programmer fixed it, they would have updated this task, assuming the programmers actually ever come to this site. Of course, if they did come here, they'd probably have noticed that a simple bug caused by someone trying to fix something that wasn't broken has been an outstanding issue for over a year.
It's obvious to me that the programmers don't use this site to find bugs to work on or to report that they've worked on the bugs, so I'm not going to use it any more.
Wesley, I'd like to direct you to this graph: http://cl.ly/TVHu which shows how many of the reported bugs are fixed. The number: almost half.
Ezekiel, would be (not so) fun to produce my own graph: I am tracking (iirc) about 50 bugs, of which about 45 have the reason (in code) analyzed and code fixes provided.. of all those, about 10 have been resolved (properly) so far. Newest of those issues are starting to approach a year... So, for older cases, the resolve rate seems to be close to 20%, not even close to half. Silliest thing is, Mojang fixed one issue I had provided the code for, but didn't fix the related issue (it was linked properly) which would have needed pretty much the exact same fix in another class. Sad, really.
But, I think this is something to be discussed on forums, not in these comments.
To have some input on the topic: The fixes I provided/proposed over year ago are of course no longer valid, as the portals can now have all kinds of shapes. (This is one reason why bugs should be fixed before doing new features/changes on things related to them.) The idea is likely still usable, but the algorithm needs to be expanded to check more blocks.
Actually, the reverse is probably true. Bugs may be fixed or invalidated with no additional effort as a result of intentional changes to the game. In such an event, the effort spent fixing the bug would have been wasted.
Large portions of Minecraft are still relatively incomplete and unfinished. It's a game that's in continual development, and the 1.0 release was largely symbolic, rather than reflecting any shift in development priorities or attitude. What's the point in fixing up code you're just going to replace later? Once they've gone through each of the game's systems, and are relatively happy with them, I think we'll see a shift towards focusing on fixing bugs over content development. Right now, they're incredibly busy reworking major game systems, and working on the plugin API.
They can only work so fast, and have to prioritize. No matter what order they do things, someone's going to complain that their pet peeve wasn't addressed fast enough.
Don't bullshit people. I'm programmer in a company where our first value is quality of the product and the code. In a product that we have been developing for over 3 years, there has never been a bug present more than a week (we release new versions weekly), and none of them has been severe bug. We also provide new features very often, and fixing bugs that we find on the way doesn't stop us from that. And how do we do that? We fix bugs before writing new code, we write test before writing implementations, and we practice pair programming to always have another person looking at what we write and provide alternative ideas.
What is happening with minecraft would be unacceptable at our company. We paid for this game and we have all the rights to demand quality and demand bugs to be fixed, especially the ones that have been present for over a year and have most of the votes in Jira. There are 11 bugs that are older than a year and have over 100 votes:
https://bugs.mojang.com/issues/?jql=project%20%3D%20MC%20AND%20resolution%20%3D%20Unresolved%20AND%20created%20%3C%3D%20-52w%20and%20votes%20%3E%20100%20ORDER%20BY%20votes%20DESC
And how many programmers do you have at your company? There are only about 5 people working on Minecraft. They have to manage their time and prioritize.
Just to ensure that we're not mixing up things, you paid for the game in the current state the game was in at the time that you bought it. Our ToS states we have no obligation to do any changes to the game. That said, this will end up getting fixed when we overhaul the portal system.
Glad to hear that portals are still going to get some attention, and that the more flexible shapes and sizes weren't all that's planned for them.
Can reproduce in 1.7.9.
I just had a pair of portals set up, such that you have to face east-west to enter them normally. I still came out facing north-south, right toward the portal frame.
@Blah - this is still confirmed in 1.7.9 and 14w20b
Confirmed for 14w21b and 1.7.10-pre1.
is this still an issue in 14w29b?
Yes, it is still an issue in 14w29b.
NVM. Still an issue in 30c. I was (out of stupidity) testing in creative.
Blah, it happens in creative as well
Confirmed for 14w31a and 14w32a and 14w32b
Affects 1.8-pre3.
Still in 1.8
Woo! Possibly going to be fixed!
Quite not fully fixed yet. Depending on the side of the portal you're teleporting from, you can get your orientation inverted. You can check it on video in http://youtu.be/pFSb51h4pxI?t=2m24s
"Reopened", under the condition that the exact cases when it happens are written down.
Ok, here are the possible cases, based on orientation of the portal, and side one enters:
Overworld->Nether
Same case, Nether -> Overworld
I don't have time to do the east-west case, but I thjink this helps a bit to understand the situation. If it's still needed, let me know here and when I get back I'll check it out.
Whilst I personally do not consider it a bug that travelling relatively through a portal between two different worlds doesn't share the exact polar coordinates (why would north here be north there?), I have made it that way regardless.
However, this bug is staying Fixed for the previous pre-release as this is unrelated to the main issue being reported in this ticket.
Although technically, I think the new bug is still related, I'll do as you request and report it in a new bug if it happens again... About the bug itself, I think the problem is that it's not just all directions that are inverted, but only a handful of them... If it just sent us always facing the opposite direction, It would be okay, although someone would still complain . But if half of the orientations are respected, and half aren't, then that doesn't seem very logical
Seems to be reopened in 1.12. See
MC-120727I've done some testing in 18w07c:
(Confirmed in 18w07c? Although it may very well be a different bug alltogether...)
If both portals are aligned along the x-axis you Always get rotated 180 degrees, north, east, south or west.
If portal A is along the x-axis and portal B is along the z-axis (which dimension doesn't have any effect):
Going through A to B rotates you 90 degrees to the left,
Going through B to A rotates you 90 degrees to the right.
(To me all seems fine for those orientations above, the following is weird)
If both portals are aligned along the z-axis:
Going from nether to ow rotates you 180 degrees,
Going from ow to nether doesn't rotate you (0 degrees) and you get displaced: (sorry, I haven't worked this out enough, it's almost a whole new bug on its own, but I guess it's related...)
In one test the ow portal is 3x3 and the nether portal is 2x4 (high), when going to the nether you get transported 3 blocks south from the portal instead of inside the portal.
The same happened for two 3x3 portals. So I assume it works the same for the rest.
So everything is fine unless you have two portals along the z-axis and you travel to the nether from the overworld. (you don't get rotated at all and you (may) get "displaced" (sometimes))
How IMHO it should be fixed:
At moment of teleportation:
– Determine portal shape, making a list of all Portal blocks for both portals, aka 'the lists'.
One list for the entrance portal, one list for the destination portal.
– Determine portal's orientation (EW or NS?)
– Determine the portal's "primary direction" as follow:
— Determine what are the portal sides A and B that will be checked:
If orientation is EW: then A is East and B is West; while if orientation is NS = then A is North and B is South.
— For each of the portal's portal blocks in 'the list', check the blocks on side A and on side B, sum up how many are "air" blocks in A_count and B_count.
— Determine which if the portal's sides is the "main" side:
> If A_count > B_count, then main side is side A
> If A_count <= B_count, then main side is side B
(thus, in case of a tie, the south-West rule applies: West wins over East, and South wins over North).
DELTAANGLE = entrance portal's main side's angle + 180 degrees + destination portal's main side's angle
then modulo 360 degrees on each of the 3 values.
IN OTHER WORDS:
If player enter some portal by the side with the least obstacles (no matter portal shape and size), he will also exit by the destination portal's by the side that also has the least obstacles. If player enters portal by side with more obstacles, then same thing he exits on side with more obstacles.
Also, if you enter by strafing or walking backwards, then you also exit by strafing or walking backwards. Relative angle is preserved.
THEN:
Basically, getting the "width" and height" of both portals and they start/stop coordinates along width and height.
For example, if you enter a 2 high by 10 wide portal while floating with your head and left side both touching the top left corner of the portal, then you would exit a 10 high by 2 wide destination portal also with your head and body touching to the top left corner. If you enter on the ground with your body at the midpoint between rightmost location and center, you are also exiting at the midpoint between where your body would be at center and rightmost possible positions.
IN OTHER WORDS:
Players always exits in a location that makes the most sense as if the portal was really like some kind of doorway.
That algorithm should cover all situational cases pretty neatly and would be very intuitive to use too.
This issue came back. It seems to always turn you 180° now.
This isn't fixed, as Fabian said the portals now turn you 180° (enter portal facing east, and you'll come out the other side facing west)
Consider reopening - 1.14 seems to have regressed. Portals in my world which worked "correctly" in 1.13.2 and prior now exhibit different player facing behavior.
Ben W, please see
MC-105207.