[MC-4631] Lava decay fails to schedule block update Created: 14/Dec/12  Updated: 22/Aug/20  Resolved: 02/May/13

Status: Resolved
Project: Minecraft: Java Edition
Component/s: None
Affects Version/s: Minecraft 1.4.5, Minecraft 1.4.6, Minecraft 1.4.7, Snapshot 13w09a, Snapshot 13w09b, Minecraft 1.5, Snapshot 13w11a, Minecraft 1.5.1
Fix Version/s: Snapshot 13w18a

Type: Bug
Reporter: mike loeven Assignee: EvilSeph (Warren Loo)
Resolution: Fixed Votes: 31
Labels: None

Attachments: PNG File 2013-03-13_08.38.20.png     PNG File 2013-03-13_08.41.09.png     PNG File 2013-03-13_08.41.17.png     PNG File 2013-03-13_08.47.56.png     PNG File 2013-03-13_08.48.10.png    
Issue Links:
Cloners
is cloned by MC-198704 Lava doesn't go away Resolved
Duplicate
is duplicated by MC-9090 Lava flows after source block is removed Resolved
is duplicated by MC-9544 Lava not disappearing properly. Resolved
is duplicated by MC-11647 Lava behaves like there is a source b... Resolved
is duplicated by MC-14033 Lava will not disapear after removing... Resolved
is duplicated by MC-14985 Lava flow does not dissipate after re... Resolved
is duplicated by MC-1942 Lava remnants not dissipating after r... Resolved
Relates
relates to MC-93468 Water and lava flow affected by rando... Resolved
relates to MC-120709 Lava and water updates do not resolve... Resolved
CHK:
Confirmation Status: Plausible

 Description   

I think this is an old issue that was never revisited but it has started causing issues with my obsidian farm.

when you remove the top layer of source blocks from a lava pool the adjacent source blocks will back-fill the pool. after all the source blocks are removed this residue lava remains indefinitely and does not drain to the pools new level making it difficult to get to the source blocks underneath. also some lava pools will remain for days and weeks with no source blocks at all. the draining mechanics for lava seem to need revisiting.



 Comments   
Comment by Roadsguy [ 05/May/13 ]

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

Comment by Roadsguy [ 03/May/13 ]

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

And everyone thought it was intended.

Comment by Phillip Susi [ 01/May/13 ]

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.

Comment by NightKev [ 01/May/13 ]

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

Comment by fake fakes [ 30/Apr/13 ]

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

Comment by Eric R [ 10/Apr/13 ]

Confirmed, 1.5.1.

Comment by mike loeven [ 04/Apr/13 ]

The only reason i can think of that people are still arguing about this issue and saying Works as Intended is because those are the lazy greifers who like to be able to ruin someones house with lava flows knowing it is difficult to clear. Ugg they make me sick.

actually on a side note this would reduce the headache of lava greifing making it a bit easier to clean up on SMP servers.

Comment by Orthotope [ 04/Apr/13 ]

Speaking as a longtime contributor to the wiki, it primarily documents observed behavior of the game. On the rare occasion that we do document intended behavior, there will always be a link to a statement by a Mojang employee confirming it. In the absence of any such statement, do not make assumptions about what is or is not intended.

Speaking as a programmer, Markku's code analysis looks solid to me. This appears to be a simple case of a missing 'else' clause, which definitely qualifies it as a bug.

Comment by Alex Campbell [ 17/Mar/13 ]

@NightKev: I didn't say it was a feature request, I said feature requests don't belong on the tracker, and that's why people are arguing about whether it's a feature request or not.

Comment by mike loeven [ 15/Mar/13 ]

would be nice if someone other than the mod team weighed in on this like you know.... an actual mojang developer :/ that would settle the works as intended dispute once and for all

Comment by NightKev [ 15/Mar/13 ]

Except it's not a feature request, it's a bug (as demonstrated above...).

Comment by Alex Campbell [ 14/Mar/13 ]

Perhaps people are arguing it because feature requests don't belong on this tracker.

Comment by Bodo Eggert [ 13/Mar/13 ]

Why do you think lava not going away for days might be intentional? Did anybody from mojang officially state that?

And even if they did, that would still be insane, therefore changing that behavior is at least a valid feature request. (As you can read above, it is an obvious programming error, but you need to understand code in order to recognize that.)

Comment by pci [ 13/Mar/13 ]

Well seemingly not always.. at the server where I play this happens:
https://mojang.atlassian.net/browse/MC-9544

Lava does go away eventually, but extremely slow, like hours/days, before it all fell to the ground. but on my post I also got the "intended" reply, wich makes no sense whatsoever.

Comment by FireHunterX [ 13/Mar/13 ]

Oh I see the problem now, they create extra "sources" but way too often.

Comment by Markku [ 13/Mar/13 ]

Xavier, the lava's flow down does work well; it is possible to toggle that part.. But why don't actually read my earlier comments: the real problem is with the horizontal flow which does not decay properly.

Comment by FireHunterX [ 13/Mar/13 ]

It IS possible to make a toggling lava fall.
See the attached screenshots.

Comment by Markku [ 13/Mar/13 ]

Xavier, please read my previous source code analysis with thought. There is indeed a 75% chance of extra delay (per update/check) in the code. But there is also another, orders of magnitude larger delay, which looks like it was not intended.

The reason people keep saying this is intended, is because they have only read about the addition of a slowdown, but they blindly think all possible delays are intended. Even ones that do not make sense.

As I already wrote before, if the larger delay is intended, the 75%-one is so insignificant that there would have been no point in adding that to the code. And the larger delay has no other game-play effects than a very large nuisance; the 75%-delay does work somewhat well (though I do not know if it should be adjusted in Nether/End a bit, now that lava flows faster in there).

Comment by pci [ 13/Mar/13 ]

Xavier, then how are we supposed to make lava waterfalls that you can turn on and off?

Please stop saying "intended" also.

Comment by [Mod] CubeTheThird [ 13/Mar/13 ]

Sorry I can't add those versions, as they are no longer available.

Comment by FireHunterX [ 13/Mar/13 ]

This is intended, there is a 1 in 4 chance for lava to remain after the source is removed.

Possibly to make it not as easy to remove by just removing the source block?

Comment by Markku [ 28/Feb/13 ]

Could a moderator add "affects" (from MC-9090) 1.4.6, 1.4.7, 13w04b, 13w05b, 13w05b, and my latest check of 13w09b. Kinda annoying watching a lava flow to decay at rapid pace (apparently same as flowing in!) when its just vertical flow, but then stay "forever" when flowing horizontally.

For those who still think this is somehow "intended", just watch what happens when you let flow a few blocks long stream of lava down to a flat surface. E.g. 10 blocks above in the air, place a lava source, wait only a second or two, and remove that lava source. See how the down fall behaves, and then curse the mess below that is not going anywhere.

Comment by Markku [ 12/Feb/13 ]

As per suggested on the forums, could some moderator change the summary/title of this issue to something like "Lava decay fails to schedule block update", which describes the actual issue/bug better.

Comment by Markku [ 12/Jan/13 ]

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

Comment by [Mod] CubeTheThird [ 12/Jan/13 ]

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.

Comment by Markku [ 12/Jan/13 ]

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.

Comment by Alex Campbell [ 07/Jan/13 ]

Is it intended?

Comment by [Mod] CubeTheThird [ 14/Dec/12 ]

This is the correct behaviour (see wiki here)

Generated at Sun Jan 12 12:05:13 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.