How It Works: Static 0-Tick Flickering Portal Zombified Piglin Farm

How It Works: Static 0-Tick Flickering Portal Zombified Piglin Farm

Author: 橘猫sama · Updated 2026-10-18 11:33 cv53412179 · Entity Mechanics 中文

Zombified Piglins, long known as Zombie Pigmen (or pigmen for short), are the zombified variant of Piglins.

This article gives a quick overview of their mob mechanics, then explains why a farm driven by rapidly relit Nether portals works, and how modern designs keep it fast and stable.


Spawning

First, a quick summary of how Zombified Piglins spawn:

Every naturally spawned Zombified Piglin has a 5% chance to be a baby. Most spawn holding a golden sword, and 5% spawn with a golden spear.

They spawn in groups of 2–4 in the Nether Wastes and Crimson Forest at light level 11 or below, but never on Nether Wart Blocks or Shroomlights.

Natural spawns make a poor farm. Nether portals can spawn them as well, and much faster.

Every random tick, each Nether portal block has a small chance to spawn one:

Easy difficulty 1 2000 \frac{1}{2000}

Normal difficulty 2 2000 \frac{2}{2000}

Hard difficulty 3 2000 \frac{3}{2000}

They appear on the east or south side of the portal, depending on which way it faces, one block above the portal's lowest obsidian. No block can obstruct this spawn.

In Bedrock Edition, every portal block also makes one spawn attempt the instant the portal is lit, at the same chance. Relighting and breaking portals therefore mass-produces Zombified Piglins.

Piglins spawned this way count against the mob cap, and the portal cannot send them to the Nether for the first 15 s.

A bug prevents them from spawning in portals below Y=0. (MCPE-149718)

In addition, 26.0+ has a 0.75% chance to spawn a special variant that cannot ride minecarts. (MCPE-236034)


Nether portals

Let's walk through the farm in the video and the principles behind it. The most common, stable and efficient design today is this one:

Simple unload-resistant static flickering portal pigman farm, by TK Minecraft

Why does the facing matter? Why must the portals straddle exactly two chunks and measure 22×22? Why we need a special 22×21 portal? Why does the igniter rig look like that? Why does the dispenser throw powder snow buckets at 2.5 Hz (one cycle every 0.4 s)? Read on.

Why does the facing matter?

Portals are lit by fire spreading from lava onto a flammable block, and fire checks its neighbours in this order:

East > West > Up > Down > South > North

That is why the video settles the build direction first, to keep ignition as reliable as possible. (Once the other five directions are walled off, the difference is small anyway.)

The portal's facing sets how efficient the igniter rig is
The portal's facing sets how efficient the igniter rig is

Why exactly two chunks?

Why exactly two chunks? Would slightly more or less on either side not work? What about three chunks?

That comes down to the core of this article: pending ticks.

When a portal is built, each portal block schedules a pending tick (pt; Java Edition calls it a scheduled tick). A single chunk can process at most 100 pending ticks per game tick (0.05 s).

Running a pending tick calls function A (listed at the end of the article). Its last two lines are the spawn attempt itself, so every pending tick gets a roll.

Before that, we need to know how a dispenser behaves. One full eject/retract cycle with a powder snow bucket takes 0.4 s:

0.1 s to eject, 0.2 s cooldown, 0.3 s to retract, 0.4 s cooldown

With the flicker portal running at 2.5 Hz (cycle T = 0.4 s), a game tick of t = 0.05 s, and a ceiling of N = 100 pending ticks per tick, the number of pending ticks per cycle is:

C = T t × N = 0.4 s 0.05 s × 100 = 800  (pending ticks) C = \frac{T}{t} \times N = \frac{0.4\text{s}}{0.05\text{s}} \times 100 = 800 \text{ (pending ticks)}

So each chunk can process 800 pending ticks in one 0.4 s cycle.

The goal is to keep those 800 slots filled with portal blocks: saturating pending ticks is how you maximise the spawn rate.

[MinecraftBE] Pigman farm too slow? Too laggy? Here's the data

Take the farm in the video: two portals, each spanning three chunks (3/16/2) and 21 blocks tall. Lighting one portal produces 672 pending ticks in the middle chunk. With the dispenser running at 2.5 Hz as well, the portal is open for 0.2 s and closed for 0.2 s. The 400 pending ticks are spent while it is open, and the remaining 272 are wasted while it is closed, because a closed portal cannot spawn anything.

Stack enough portals and you run into the per-tick limit: a cycle that cannot spend all of its pending ticks leaves a pt backlog. The usual symptom is that you shut the farm down and the portals you left lit keep producing Zombified Piglins. Be careful here — a large backlog can permanently damage your world.

So, to state the conclusion plainly: more portals is not better. The pending ticks and the spawn output a chunk can handle are both finite. To get the most out of the spawn rate, split the portals evenly and keep each one at 22×22 (400 portal blocks), precisely to control pending ticks.

Each portal is split evenly: 200 portal blocks and 200 pending ticks per side
Each portal is split evenly: 200 portal blocks and 200 pending ticks per side

But the farm above also runs at 2.5 Hz, so why doesn't it waste pending ticks?

Because observers, dispensers, droppers and even lava all react to pending ticks.

A short, well-timed pt backlog shifts when the dispenser fires, so it can eject the bucket, retract it and let the lava ignite within zero gametick.

700 or more portal blocks deliver the ideal backlog, which keeps the portal lit the whole time: not a single spawn is wasted.

Mind the budget, though. The dispenser consumes pt as well, so remove one column of portals in the portal's chunk, reserve (portals/2, rounded up) × 3 pt for the lava plus portals × 2 pt for the dispensers, and build nothing else in that chunk.

For four portals, reserve 4×2 pt (dispensers) + 2×3 pt (igniter).

Remove one column of portal blocks in the powder-snow door's chunk
Remove one column of portal blocks in the powder-snow portal's chunk

The igniter rig

With the portal and the breaker covered, one part remains: the igniter rig.

You can craft flint and steel in a crafter and have a dispenser use it, but that burns materials. Lava lights portals for free.

In Bedrock Edition, every time lava ticks it first checks whether the block directly above it is air or a flammable block; if neither, nothing ignites. It then draws 10 random blocks from the 3×3×3 cube centred on the lava, independent uniform draws with repeats allowed. As soon as a flammable block comes up, it checks that block's six orthogonal neighbours in the order +X, −X, +Y, −Y, +Z, −Z and places fire on the first air block it finds, then stops. Fire can therefore appear up to 2 blocks horizontally from the lava, except for the four corners of the 5×5, or up to 2 blocks vertically, in which case the horizontal range shrinks to 3×3. The flammable block itself must sit inside the 3×3×3 cube. Fire placement checks neither support nor a valid fire location, so fire can float in mid-air.

Orange wool marks flammable blocks. Orange stained glass marks the six adjacent air blocks where fire can appear, grey stained glass the ring around them, and t
Orange wool marks flammable blocks. Orange stained glass marks the six adjacent air blocks where fire can appear, grey stained glass the ring around them, and the outer planks the safe zone.

Blocks such as crafting tables and trapdoors carry fire but do not burn away.

Natural spread is still slow. The fix is to activate the lava.

You may have heard that high-frequency redstone makes fluids flow faster. Cobblestone generators and moss farms rely on this.

High-frequency redstone charges a trapdoor, and the trapdoor activates the lava
High-frequency redstone charges a trapdoor, and the trapdoor activates the lava

Before 1.21.70, fluids came in two kinds: static and dynamic. An nc update turns a static fluid dynamic and schedules 2 pt. When the pt fires, the fluid turns static again.

Fluid activation in a cobblestone generator really means inserting a third party's pt between the fluid's two pt.
The rough timeline runs:
0gt: the static fluid takes an nc update, schedules 2 pt to fire after n gt, and becomes dynamic.
ngt: the first dynamic pt fires; the fluid turns static and tries to flow, and lava additionally tries to ignite. The third party's pt fires, producing an nc update, so the fluid schedules another 2 pt after n gt and turns dynamic again. The second dynamic pt fires, and the fluid turns static and tries to flow and ignite. The fluid ends up static again, but with two extra pt queued n gt out. If it takes another nc update within that window it ends up with 4 pt and can flow twice per cycle; repeat that and the fluid is activated. A dynamic fluid taking an nc update produces no pt.

Before 1.21.70 the lava had to be isolated in single cells, because switching between static and dynamic also fires nc updates. The design looked like this:

Lava isolated in single cells
Lava isolated in single cells
The side trapdoors supply nc updates too (works in every version)
The side trapdoors supply nc updates too (works in every version)

Before 1.21.70 this had to be stacked four layers deep with delays: lava's pt fires after 30 gt, and each layer adds 8 gt at 2.5 Hz or 6 gt at 3.33 Hz, giving totals of 32 gt and 30 gt. Since 1.21.70, just copy the picture.

The chance that three lava sources light both portals is:

1 − ( ( 1 3 ) 30 + ( 1 − ( 1 3 ) 10 ) ( 2 3 ) 20 + ( 1 3 ) 10 ( 1 − ( 1 3 ) 10 ) ( 2 3 ) 10 + ( 1 3 ) 20 ( 1 − ( 1 3 ) 10 ) ) = 99.970 % 1-\left(\left(\frac{1}{3}\right)^{30}+\left(1-\left(\frac{1}{3}\right)^{10}\right)\left(\frac{2}{3}\right)^{20}+\left(\frac{1}{3}\right)^{10}\left(1-\left(\frac{1}{3}\right)^{10}\right)\left(\frac{2}{3}\right)^{10}+\left(\frac{1}{3}\right)^{20}\left(1-\left(\frac{1}{3}\right)^{10}\right)\right)=99.970\text{\%}

Since 1.21.70 there is no static/dynamic split. An nc update simply schedules one pt to fire n gt later.

The build is smaller
The build is smaller
For 1.21.70–26.0 only
For 1.21.70–26.0 only

Since 1.26.10 a fluid can schedule only one pt per tick at the same position. Either build the pre-1.21.70 version, or join the cells together:

No static/dynamic split, so the lava cells can be joined
No static/dynamic split, so the lava cells can be joined
For 26.10+
For 26.10+

High-frequency clocks

The redstone itself is straightforward. A 2.5 Hz portal breaker opens and lights the portal once every 8 gt. The dispensers must fire twice every 8 gt, so once every 4 gt: a 2 gt pulse every 4 gt, the fastest clock Bedrock allows. The igniter fires once every 8 gt, an 8 gt pulse every 16 gt. Do not use an observer clock here, because observers also react to pt; the observer loop only supplies the initial short pulse.

Short-pulse loop
Short-pulse loop
Note that Zombified Piglin spawns cannot be blocked, so they do spawn inside the igniter's blocks and the door's blocks and fall out. If one spawns on a redston
Note that Zombified Piglin spawns cannot be blocked, so they do spawn inside the igniter's blocks and the door's blocks and fall out. If one spawns on a redstone line, raise that line by one block as shown.

To sum up: design the portals so that a pt backlog builds up, then let the dispensers eject and retract the bucket while the lava ignites within the same game tick. That is all a static flickering portal pigman farm is.

One more note: 26.0+ includes a Zombified Piglin that cannot ride minecarts. If you gather and kill with minecarts, add powder snow or turtle eggs as a backup kill method.


Finally, my thanks to everyone who made this article possible:

@8848yyds — code support and editorial guidance

I hope this article helps.


Source code

A. What happens on every random tick of a portal block:

C++
void PortalBlock::tick (
    ::BlockSource&    region,
    ::BlockPos const& pos,
    ::Random&         random
){
    auto& block       = region.getBlock(pos);
    auto  portalAxis  = block.getState<TorchFacing>(VanillaStates::PortalAxis());
    auto  portalShape = PortalShape(region, pos, portalAxis);
    auto& dim         = region.getDimension();
    if (portalShape.isValid() && portalShape.isFilled()) {
        auto  portalRecord = portalShape.createRecord();
        auto& poralForcer  = region.getLevel().getPortalForcer();
        auto  dimId        = region.getDimensionId();
        if (!poralForcer.portalRecordExists(dimId, portalRecord)) {
            poralForcer.addPortalRecord(dimId, portalRecord);
        }
    }
    if (SpawnChecks::canSpawnPigZombieFromPortal(dim, random)) {
        PortalBlock::trySpawnPigZombie(region, pos, portalAxis);
    }
}

B. Spawn chance versus difficulty:

C++
static bool PortalBlock::canSpawnPigZombieFromPortal(::Dimension const& dimension, ::IRandom& random) {
    auto& level     = dimension.getLevel();
    auto& gameRules = level.getGameRules();
    if ((*gameRules.mGameRules)[static_cast<int>(GameRules::GameRulesIndex::DoMobSpawning)].mValue->boolVal) {
        int randomValue     = random.nextIntInclusive(0, 1999);
        int difficultyValue = static_cast<int>(level.getDifficulty());
        return randomValue < difficultyValue;
    }
    return false;
}

C. Finding the spawn position and spawning:

C++
void PortalBlock::trySpawnPigZombie(
    ::BlockSource&    region,
    ::BlockPos const& pos,
    ::PortalAxis      axis
){
Vec3 _pos = pos;
    while (_pos.y-- > 1) {
        if (region.canProvideSupport(_pos, 1, ::BlockSupportType::Any)
            // && !region.isSolidBlockingBlock(_pos.x, _pos.y + 1, pos.z)
            // The original check, kept here for reference. As far as I can tell no
            // solid block fails to support the block above it, so it is redundant.
        ) {
            if (axis == PortalAxis::Z) {
                _pos.x += 1.5f;
                _pos.z += 0.5f;
            } else if (axis == PortalAxis::X) {
                _pos.x += 0.5f;
                _pos.z += 1.5f;
            }
            _pos.y += 1.1f;
            ll::service::getLevel()->getSpawner().spawnMob(
                region,
                ActorDefinitionIdentifier("minecraft:zombie_pigman"),
                nullptr,
                _pos,
                false,
                true,
                false
            );
            return;
        }
    }
}

Tick-by-tick timing

By @8848yyds
By @8848yyds

The table lists exactly what the farm does on each game tick. After tick 8 the cycle restarts at tick 1.


Minecart fix

This behavior pack fixes pigmen being unable to enter minecarts. It is also from @8848yyds.

https://pan.baidu.com/s/1KJfuuUSXahqycpZWGnUxZQ?pwd=jumo

Original post » « Back to Entity Mechanics « Back to article list