Player facing changes when passing through nether portals in certain cases

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:

Teleporter.placeInExistingPortal(Entity, double, double, double, float)

...
    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...)

Teleporter.placeInExistingPortal(Entity, double, double, double, float)

...
    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...

Teleporter.checkDirection()

private int checkDirection(int mainDir1, int horX, int verZ, int horY) {
    boolean frontEmpty = true;
    boolean backEmpty = true;
    if (mainDir1 == 0) { // south
        if (this.worldServer.getBlockId(horX + 0, verZ+0, horY + 1) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX + 1, verZ+0, horY + 1) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX + 0, verZ+1, horY + 1) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX + 1, verZ+1, horY + 1) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX + 0, verZ+0, horY - 1) != 0) backEmpty = false;
        if (this.worldServer.getBlockId(horX + 1, verZ+0, horY - 1) != 0) backEmpty = false;
        if (this.worldServer.getBlockId(horX + 0, verZ+1, horY - 1) != 0) backEmpty = false;
        if (this.worldServer.getBlockId(horX + 1, verZ+1, horY - 1) != 0) backEmpty = false;
        if (frontEmpty == backEmpty) return -1;
        return frontEmpty ? 0 : 2;
    }

    if (mainDir1 == 2) { // north
        if (this.worldServer.getBlockId(horX - 0, verZ+0, horY - 1) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX - 1, verZ+0, horY - 1) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX - 0, verZ+1, horY - 1) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX - 1, verZ+1, horY - 1) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX - 0, verZ+0, horY + 1) != 0) backEmpty = false;
        if (this.worldServer.getBlockId(horX - 1, verZ+0, horY + 1) != 0) backEmpty = false;
        if (this.worldServer.getBlockId(horX - 0, verZ+1, horY + 1) != 0) backEmpty = false;
        if (this.worldServer.getBlockId(horX - 1, verZ+1, horY + 1) != 0) backEmpty = false;
        if (frontEmpty == backEmpty) return -1;
        return frontEmpty ? 2 : 0;
    }

    if (mainDir1 == 1) { // west
        if (this.worldServer.getBlockId(horX - 1, verZ+0, horY + 0) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX - 1, verZ+0, horY + 1) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX - 1, verZ+1, horY + 0) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX - 1, verZ+1, horY + 1) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX + 1, verZ+0, horY + 0) != 0) backEmpty = false;
        if (this.worldServer.getBlockId(horX + 1, verZ+0, horY + 1) != 0) backEmpty = false;
        if (this.worldServer.getBlockId(horX + 1, verZ+1, horY + 0) != 0) backEmpty = false;
        if (this.worldServer.getBlockId(horX + 1, verZ+1, horY + 1) != 0) backEmpty = false;
        if (frontEmpty == backEmpty) return -1;
        return frontEmpty ? 1 : 3;
    }

    if (mainDir1 == 3) { // east
        if (this.worldServer.getBlockId(horX + 1, verZ+0, horY - 0) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX + 1, verZ+0, horY - 1) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX + 1, verZ+1, horY - 0) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX + 1, verZ+1, horY - 1) != 0) frontEmpty = false;
        if (this.worldServer.getBlockId(horX - 1, verZ+0, horY - 0) != 0) backEmpty = false;
        if (this.worldServer.getBlockId(horX - 1, verZ+0, horY - 1) != 0) backEmpty = false;
        if (this.worldServer.getBlockId(horX - 1, verZ+1, horY - 0) != 0) backEmpty = false;
        if (this.worldServer.getBlockId(horX - 1, verZ+1, horY - 1) != 0) backEmpty = false;
        if (frontEmpty == backEmpty) return -1;
        return frontEmpty ? 3 : 1;
    }

    return -1;
}

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:

• Part I is "starting to leave", where the background still shows the entrance portal's dimension behind the portal animation.

• Part II is "in transit", where the background doesn't show any world, only the portal animation. Part II can be as short as a single "in between 2 ticks" moment. In fact I'm not even sure it exists, and in fact it does not need to exist.

• Part III is "starting to arrive", where the background now shows the destination portal's dimension behind the portal animation.

What is of interest here is the 2 following things:

• The "in between 2 ticks" moment between Parts I and II, is the actual "departure". This is where entrance portal values are checked.

• The "in between 2 ticks" moment between Parts II and III, is the actual "arrival". This is where destination portal values are checked, and the player orientation is simply rotated by 0, 90, 180 or 270 degrees, as needed.

• If part II doesn't exist, then both moments coïncide in between the same 2 ticks. It's just that one Part I is fully computed, THEN the player coordinates are changed, THEN Part II is computed, THEN thre player's orientation is adjusted.

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:

• Is the player entering from the "left" or "right" side? ie. Through the first or the second portal block?

• What is the entrance portal's orientation?

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:

• What is the entrance portal's orientation?

• Determine it's favored direction by comparing using the same 3 high 2 wide and 2 deep volume summing Air blocks on each side.

• In case of a tie, the REVERSE of the entrance portal favored direction's upon entrance is used(because obviously, an entrance portal make to be exited from the north, is thus ideally entered from the south, and that is the value that would be used), and that direction is then rotated 90 degrees clockwise if the pair of portals don't share the same orientation (remember, there are only 2 portal orientations, even though there are 4 portal directions - that is because of the portals' inherent frame symmetry).

• For extra credit, the 2x2 "floor" blocks adjacent to the obsidian at each side of the base of the portal can be checked too for the presence of lava, each lava block counting as a -1 penalty on the number of air blocks. This way, odds of exiring "right into a lava lake" on a side without much space to walk on, are lowered when there is not also a wal behind the portal.

• Now, if the player entered from the "first" portal block in the entrance portal, he should come out of the "second" portal block at the destination portal, and vice- versa, so the actual destination coordinate is adjusted if need be, using the inverse of the offset from the block center (so if we entered in the first block but very near the second block, we'll exit in the second block very near the first block, not instead of a straight offset which would instead make us reappear halfway inside the side pillar).

• Finaly, the player's actual direction is rotated 0, 90, 180 or 270 degrees, according the difference between entrance and exit portal favored directions. Note that favorite portal direction always refer to "the way the player should immediately exit".

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:

• Test Case A:

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:

• Test Case B:

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

• Comparing both, proposed minimal correction to the fix:

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:

• In all cases except when nether-portal was at 99-100 and moving from nether to otherworld, the exit coordinate was always the same for the same travel target dimension. In the exceptional case, the exit block was on the same relative half as one entered (walk in on left side, exit at left side, etc.). I did not expect that, but it isn't against my goals, either. I'm not going to do anything about it.

• The movement speed was stopped in all cases (that I paid attention to, that is). I was expecting that when one side was blocked, the movement speed is retained. That is, if I entered running, I would exit running. Since the relevant code in the Teleporter class does not stop the movement, I'm not looking into this more, either. (The stopping is likely somewhere else, and the teleportation code is spread around all over the place and messy...)

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.

This is one reason why bugs should be fixed before doing new features/changes on things related to them.

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.

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.

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

• Created portal facing north/south

• Walked north facing in that direction. Ended up facing east on the nether (Portal generated there was on the other way, rotated so they match and no extra calculations are required)

• Walked again north looking at north (-179,7), appeared on the nether facing south (0.3)

• Walked south facing south. Orientation didnt change this time, still facing south.

• Walked backwards(north) facing south (0,0). Appeared on the nether facing north (-180,0)

• Walked backwards(south) facing north (-180,0). Orientation didn't change

Same case, Nether -> Overworld

• Walking north, facing north: Orientation didn't change.

• Walking south, facing south: Orientation changed from (0,0) in nether to (-180,0) in Overworld

• Walking north, facing south: Orientation didn't change.

• Walking south, facing north: Orientation changed from (-180,0) in nether to (0,0) in 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-120727

I'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:

• Memorize player coordinates and full orientation.

• For BOTH entrance and exit portals:

– 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).

• From this primary side, you can then determine which half is the "leftward" side and which half is the "rightward" side.

• We now know what are the "primary" sides for both the entrance and the destination portals:
  DELTAANGLE = entrance portal's main side's angle + 180 degrees + destination portal's main side's angle

• On teleportation, Player's XZ body orientation, horizontal viewing angle, and horizontal movement direction, are all be adjusted by DELTAANGLE,
  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:

• Now, while we parsed 'the lists', we also took note of which coordinates indicate the topmost, bottommost, leftwardmost and rightwardmost blocks.
  Basically, getting the "width" and height" of both portals and they start/stop coordinates along width and height.

• We reduce width and height values by player model's width and height (respectively).

• Using start/stop coordinates we find the "center" of entrance and destination portals.

• With the above data, we can now determine, in terms of percentage, where the player was (right before teleportation) relative to entrance portal.

• We can then compute where he should reappear in the destination portal, using start/stop, percentage, and center and width (adjusted for player model size).

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.

• If the output destination makes player hitbox hit some blocks other than portal blocks, his reappearance location is simply pushed so that he is inside the portal and if that still doesn't work, simply shunted straight to a valid spot (to take into account really weird portal shapes)

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.

@unknown, please see MC-105207.