mojira.dev
MC-10077

Ajasent Obsidian Blocks prevent Nether portal appearing

If you build a nether portal frame against an obsidian wall and then try to light it with the flint the block will catch on fire instead of forming a portal. The blocks causing the problem are the lowest two directly behind where the portal will apear. Placing any other kind of block there does not stop the portal appearing. If you remove one block the portal can then be created on that side but not the other.

Occurs in both creative and survival

Related issues

Attachments

Comments

migrated
[media]
bugi74

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.

bugi74

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

Blacksky

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?

bugi74

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.

Blacksky

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.

bugi74

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.

Blacksky

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?

bugi74

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

Dean Baset

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

bugi74

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

Blacksky

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.

bugi74

Affects 13w09b.

Blacksky

(Unassigned)

Confirmed

Minecraft 1.4.7, Snapshot 13w07a, Snapshot 13w09a, Snapshot 13w09b, Snapshot 13w09c, ..., Minecraft 1.5.1, Minecraft 1.5.2, Snapshot 13w18c, Snapshot 13w19a, Minecraft 1.6.2

Minecraft 13w37a

Retrieved