Lava decay fails to schedule block update

This is the correct behaviour (see wiki here)

Is it intended?

A bit of clarification: It is user-documented behaviour, not necessarily correct or intended. The wiki page for lava didn't seem to contain references to any credible sources for this issue.

Minecraftwiki is not a specification, it is a mixed collection of documentation about observed, sometimes confirmed, and quite a few misunderstood behaviours.

Definitions and documentation on the wiki are (in most cases) generally accepted and intended behaviour. Because of a lack of contradicting documentation, there is nothing that suggests this is not the intended behaviour (unless you should find such documentation). For this reason the issue is currently deemed as working as intended. If you feel that the behaviour should be changed, you may make a feature request on the MC forums here.

After analyzing the decompiled source code, I came to conclusion that lava flow's decrease is specifically coded to have a random slowdown effect (as considered intended). But there is also an additional much greater slowdown effect (order of hundred time greater, iirc the parameters correctly), which I think is not intended. If the latter was intended, there would be no need to add the explicit code for the minor extra slowdown, the greater effect would already make the lava flow decay so slow.

Specifically, using MCP decompilation with my own parameter name interpretations, notice that "par5Random.next(4) != 0", which skips the decay 75% of times it would normally happen:

BlockFlowing.updateTick()

...
// If lava flow is decreasing in this block, but a random chance is 75% true, cancel the decrease
if (this.blockMaterial == Material.lava && currentFlowDecay < 8 && newFlowDecay < 8 && newFlowDecay > currentFlowDecay && par5Random.nextInt(4) != 0) {
    newFlowDecay = currentFlowDecay;
    allowUpdateFlag = false;
}

if (newFlowDecay == currentFlowDecay) {
    if (allowUpdateFlag) {
        this.updateFlow(world, horX, verZ, horY);
    }
} else {
    ...

Unfortunately, when that skipping happens, it will forget to schedule to do the next update to the block. (For water flow changes and for lava's increasing flow change, the update is always scheduled.) This lack of scheduling makes the call for updates to drop to happen only with the generic random world updates (the same things that make leaves decay etc.), which is already very slow, but will then still be applied that random 75% skipping.

For a player, the smaller slowdown means that a medium sized lava stream would dry up in several minutes (instead of less than a minute). The drop to generic world updates (plus the random chance slowdown) means it can take hours. I can not see any sane reason to enforce the player to wait that long, the is no game play benefits, no thematic reason, nor anything fun about it.

IMHO, the fix is to add an 'else' with update scheduling to the latter 'if', like this:

BlockFlowing.updateTick()

...
if (newFlowDecay == currentFlowDecay) {
    if (allowUpdateFlag) {
        this.updateFlow(world, horX, verZ, horY);
    } else {
        // Ensure that even if the flow decay was skipped, it will retry at the material's natural flow period.
        world.scheduleBlockUpdate(horX, verZ, horY, this.blockID, this.tickRate());
    }
} else {
    ...

I tried how that fix works on a recompiled client, visiting Nether, and I have to say, "perfect". The lava flow decay would still be slow, sometimes taking tens of seconds to notice even one block decreasing the flow by one level, but overall in couple minutes the flow had withdrawn from about 5 blocks distance. A much more sensible rate than the current "takes the greater part of an eternity" rate.

I'll add a thread in that Suggestion-forum suggested, and link this issue to it (and copy the explanation above). (EDIT: http://www.minecraftforum.net/topic/1643780-make-the-lava-flow-decay-less-slow-a-bugfix-really-with-fix-included/)

(And hopefully the analysis of the source code now counts as "contradicting documentation".)

I think it is intended, but it is in 13w17a anyway.

The only ones now who can say whether it's intended or not are the Mojang devs.

Solid code analysis Markku. I thought I had seen them decay once in a blue moon, but it seemed too slow even for random world updates. The 75% reduction on top of that makes sense.

They finally fixed this, huh? It was so annoying.

And everyone thought it was intended. 😛

But it was reported during 1.4. You can't add previous versions as affected, which wouldn't have a point. :/