Ajasent Obsidian Blocks prevent Nether portal appearing

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.

Fix
(MCP naming and my own interpretations)

BlockPortal

// Copied out from the other (old method) for multiple calls:
    private boolean checkPortalShape(World world, int x, int y, int z, int eastwest, int northsouth) {
        int hor;
        int ver;

        for (hor = -1; hor <= 2; ++hor) {
            for (ver = -1; ver <= 3; ++ver) {
                boolean onEdge = hor == -1 || hor == 2 || ver == -1 || ver == 3;

                // If not in corner:
                if (hor != -1 && hor != 2 || ver != -1 && ver != 3) {
                    int blockId = world.getBlockId(x + eastwest * hor, y + ver, z + northsouth * hor);
                    if (onEdge) {
                        if (blockId != Block.obsidian.blockID) {
                            return false;
                        }
                    } else if (blockId != 0 && blockId != Block.fire.blockID) {
                        return false;
                    }
                }
            }
        }
        return true;
    }

    // Existing method, quite heavily modified:
    public boolean tryToCreatePortal(World world, int x, int y, int z) {
        int eastwest = 0;
        int northsouth = 0;

        // Check for all 4 possible portal frames around the input location:
        // East or west end (of east-west portal):
        if (checkPortalShape(world, x, y, z, 1, 0)) {
            eastwest = 1;
        } else if (checkPortalShape(world, x-1, y, z, 1, 0)) {
            x--;
            eastwest = 1;
        }
        // North or south end (of north-south portal):
        if (checkPortalShape(world, x, y, z, 0, 1)) {
            northsouth = 1;
        } else if (checkPortalShape(world, x, y, z-1, 0, 1)) {
            z--;
            northsouth = 1;
        }

        if (eastwest == northsouth) {
            // Either two valid frames or no frames at all.
            return false;
        } else {
            int horiz;
            int verti;

            world.editingBlocks = true;

            for (horiz = 0; horiz < 2; ++horiz) {
                for (verti = 0; verti < 3; ++verti) {
                    world.setBlockWithNotify(x + eastwest * horiz, y + verti, z + northsouth * horiz, Block.portal.blockID);
                }
            }

            world.editingBlocks = false;
            return true;
        }
    }

Tested on 1.4.7. After those changes, even crossed portal frames will be handled as long as either orientation can be detected as valid and the other not. Or, if overlapping portals are both full/valid, but the fire is applied to a block that is not in the crossed/overlapping section (in which case the fire block can only be part of one portal frame), the changes still work (as they did before, too).

Wow, you fixed that fast!

By the way, I'm not sure if it strictly a bug or not, but you can walk all the way through an active portal and out the other side without travelling to the Nether. Do you know if it is supposed to do that or not?

Depends on the timing. Portal activation has a minimum time the player must stay "in" the portal. If you just speed through it, the time might remain too short.

It does cause a few problems for me since I suffer from lag a lot, it hasn't happened yet but every time I use the portal I very nearly get sent back before I can get out. The first time I tried to use it I walked right through it and fell down a cliff.

It should not send you back if you stay in the portal after teleport (even if the swirling effect starts). You need to get out and then back in, in order to reactivate the portal for getting back.

Also, to make it a bit more safe to approach the gate (if there are cliffs on the other side), use sneaking, and move a bit sideways aiming at the portal frame, instead of walking directly through it. As soon as you notice the swirling to start, just stop, it'll take you through.

Thanks I've walled up the back with cobblestone now so it should be 0k. Do you know if there are any plans to make it so you walk through the portals instead of standing in them, or making the worlds connected enough to drive a cart through?

No idea, though I thought driving carts through is already semi-working, but just currently a bit messed up by other bug(s).

I believe this is intended so that you do not make 2 nether portals adjacent to eachother

(No need to 'believe' something if someone has already analyzed the code and even provided a fix, like I have already done.)

If its intention was to prevent two adjacent nether portals, it would be bugged still, as the current behavior does not prevent it. And there is no need to prevent such, either. (There are consequences for having two portals close each other, but they are something that the player can handle, should he find them undesirable.)

This is simply the result of a bit simple implementation. It does prevent, unnecessarily, certain portal arrangements, but it is just a coincidence, not the intention. The intention was merely to stop the algorithm in a case where it thought it can not resolve which orientation is the right one.

My fix simply improves that check. It still prevents certain portal frame arrangement, but is much more accurate about it.

Ah well, at least this is something that might help if a player gets an obsidian block in the wrong place or tries to wall up behind the portal with obsidian blocks like I did.

Affects 13w09b.