Lava decay fails to schedule block update
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.
Linked Issues
is cloned by1
is duplicated by6
MC-9090Lava flows after source block is removedDuplicateMC-9544Lava not disappearing properly.DuplicateMC-11647Lava behaves like there is a source block, even if the source are goneDuplicateMC-14033Lava will not disapear after removing the source blockDuplicateMC-14985Lava flow does not dissipate after removing lava source blockDuplicateMC-1942Lava remnants not dissipating after removing source blockDuplicate
Created Issue:
lava pools do not decrease in level when top layer of source blocks are removed.
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.
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
is duplicated by
lavapools do not decrease in level when top layer ofsource blocks areremoved.Lava flows after source block is removed
is duplicated by
Lavaflows after source block is removedLava decay fails to schedule block update
is duplicated by
is duplicated by
is duplicated by
EvilSeph (Warren Loo)![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
relates to
relates to
is cloned by
In the other issue, the comment refers to the wiki (which is community-run and not a 100% reliable source of information), which mentions that lava will eventually disappear when there are no source blocks - I do not doubt that.
What we are seeing instead is that the lava creates new source blocks in certain circumstances (further down the lava stream) that were not created by the player and which obviously don't disappear by themselves and must be manually removed.
That's what happens in the attached Sandbox savegame and it's also what I see a lot in my games.
Anyway, we will probably not get any attention here, since this issue is marked as "Resolved". And I'm not 100% sure if the other issue (MC-4631) is exactly the same, as its description seems a little vague to me.
@Yamaraj maybe - as original reporter of the issue - you can reopen it and clarify that what we're experiencing isn't explained by the wiki?
If this is intended, then perhaps take a closer look at MC-4631, too. Sounds really stupid if lava now flows super-fast (in Nether and End), but decays super-slow (everywhere). (Since the issue is marked resolved by moderators, there is not much hope it will ever get into Mojang's attention without some "spamming"..)
A bit of a repeat, sorry, but since this is definitely confirmed as "lava flows faster in Nether because Mojang thinks it should", how is the status of MC-4631 considered by Mojang? Is it fixed (but not told about)? Or is it really intended, i.e. does Mojang think that while lava flows faster, it should still decay super-slow (as if in cold place)?
Considering the technical findings behind the issue, I have a reason to think the decay had become even slower than what had been really intended, and now that lava flow rate in nether has been (or will be) increased, it might be an idea to remove that slow down of decay in Nether (and End if it flows faster there, too).
Actually, as argued (by me) in the MC-4631, while there is an intention to have slower decay than flowing in, there seems to be also a bug that makes to decay multiple orders slower than probably was intended. Details in that other issue's comments.
Duplicate of MC-4631. Please use the search function to check before posting in the future.
Please do not mark issues as private, unless your bug report is a security issue containing information that may compromise your server/client.
Duplicate of MC-4631, please use the search function to see if your bug has already been submitted. Currently over 54% of tickets are being closed as duplicate.
Duplicate of MC-4631, please use the search function to see if your bug has already been submitted. Currently over 55% of tickets are being closed as duplicate.
This may be a duplicate, but all the old (fixed) 'MC-4631' and related issues are flooding my search results. After placing and removing lava, I found a single ghost lava block that persisted, made sounds and particles, and added the flame effect but did not burn me when I stepped into it.
Hard to reproduce; suspect a server/client glitch. I think I saw the same with water once, but I wasn't paying proper attention and didn't capture it
Regression of MC-4631
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:
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:
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".)
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.
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.
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?
Sorry I can't add those versions, as they are no longer available.
Xavier, then how are we supposed to make lava waterfalls that you can turn on and off?
Please stop saying "intended" also.
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).
It IS possible to make a toggling lava fall.
See the attached screenshots.
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.
Oh I see the problem now, they create extra "sources" but way too often.
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.
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.)
Perhaps people are arguing it because feature requests don't belong on this tracker.
Except it's not a feature request, it's a bug (as demonstrated above...).
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
@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.
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.
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.
Confirmed, 1.5.1.
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. :/