Lava and water updates do not resolve completely when random ticking is disabled

ehm this is unrelated to random ticks. it's caused by faulty world generation and has been in the game for years. here's it happening in 1.12.2:

https://imgur.com/a/PNk9P

Are you sure? This report does not describe fluid bugs caused by world generation.

It's not caused by random ticks, but it used to be fixed by them. It has been in the game for a long time, that is true.

It's only linked as related so that developers looking at the bug can find the other one. The actual cause is almost definitely unrelated (unchecked, though - fluids are not fun) (and probably linking will be changed now that the other one has been reopened).

Ilmango is right. I was the one who posted this bug for the 1.12.2 issue.
These issues happened from water sources already set in the world.

That's irrelevant, it's not a mistake in the generation, and can happen also with manually played water/lava.

Reopening and marking as postponed (since, technically, no fix was made to this, and once the fix for MC-93468 is re-added, it'll be necessary to actually fix this). MC-93468 has also been linked as blocked by this bug.

This bug is also not fixed because of the reversion of MC-93468.
Just do /gamerule randomTickSpeed 0 before you remove the source.

The fix of MC-93468 just made it more apparent that it is in the game, but it is not fixed by 1.12.2

(edit: Started writing this comment before @unknown reopend)

And, good point about it being reproducible in 1.12.2 if randomTickSpeed is set to 0. I had the same thought - I've reopened the issue again from postponed since it can still be tested in current versions (and also updated the title and description to reflect how to reproduce it now).

I think it is ca used by inconsistency of block updates. In very specific locations block updates doesn't work properly. If you want to confirm this, then place piston where lava left unupdated and power it.

In the image "fixed water image.png" is a proposed fix for this bug.
Random ticks are set to zero and the lava + water generated as per normal.

The fix can be found in WorldServer.java
There is a code that is used for instantly updating or rather instantly running scheduled updates in the code. When its used it generates water instantly when a chunk is populated. The instant updates have a check to see if an area around 8 blocks in all directions is loaded. This check prevents the water to flow naturally and causes the water to stop spreading towards unloaded chunks. When this happens the water stops spreading and looks like it's been stopped by a invisible barrier. In other instances it sporadically spreads, most likely because more neighbouring chunk loaded in while it was spreading and randomly selected water blocks had already spread while the neighbouring chunk loaded giving a sporadic shape.

The simple fix to this is to remove the check where a loaded chunk is needed for the scheduled updates to happen instantly. Removing it will give water the naturally generated shape, the same goes for lava. After removing the if statement that prevents instant updates near unloaded chunks the water generation stopped creating error waters. The picture is of the seed and the coordinate of where error water have been spotted.

A picture of what was changed in the code:
https://i.imgur.com/7jiNzbW.png

An hour of flying in spectator mode into newly generated chunk gave good results with no noticeable error water generation. But as of writing this there was no noticeable errors caused by this change. If anyone else can test this fix and report any other issues caused by removing this check. It's pointing towards having no side effects removing this particular loaded chunks check during instant scheduled updates.

My guess of why this check is in the code is so that no chunks get generated when they are to be generated anyways by the world generator.
However, I honestly don't understand why this change would fix it (not saying that it doesn't). If the check fails in vanilla code, the delay is set to 1 and it schedules the block tick like it would do it in the usual scheduleBlockUpdate, just with the delay set to 1. So it should just run the tile tick in the next game tick.
When I have time I might look into why the tick does not get executed in the next tick properly. I'll go on vacation shortly tho, so don't expect anything soon from me. Maybe someone else also wants to try investigating further 🙂

Actually, nevermind. I missed a brecket, the return statement is after that isAreaLoaded check.
So if the check is there to prevent chunks to try to generate when they shouldn't, an alternate way of fixing it is to just move the return statement up one bracket.

You are correct, I assumed that the check was taxing an already strained chunk generation and should have been removed. It didn't hit me that the return statement could be moved up one line. Doing so will fix the issue. It seams if water stops flowing in odd shapes it will continue after the area is loaded by the player.

It seams it only was a miss placed return statement. More then likely this news will get to them a bit late. They probably found this fix on there own. But if not, hope this comes in handy.

I can confirm that moving the "return" statement one bracket up fixes the issue on a 1.12.2 server.

This is the diff for a CraftBukkit-Server:

--- a/src/main/java/net/minecraft/server/WorldServer.java
+++ b/src/main/java/net/minecraft/server/WorldServer.java
@@ -630,9 +630,10 @@ public class WorldServer extends World implements IAsyncTaskHandler {
                     if (iblockdata.getMaterial() != Material.AIR && iblockdata.getBlock() == block) {
                         iblockdata.getBlock().b((World) this, blockposition, iblockdata, this.random);
                     }
+
+                    return; // Fix MC-120709
                 }
 
-                return;
             }
 
             i = 1;
--

I can confirm that changing it so that a tick is queued when the area isn't loaded (i.e. moving the return statement up) fixes generation for the test case above.

It does not solve the actual problem that causes liquids to get stuck. Worlds that were generated before the fix (with random ticks disabled) will still have the issue afterwards. That probably would be fine for a minor update (and, the way it's currently generated is bad in other ways, so it's still a good fix).

If someone wants to look at what actually is causing the water/lava to get stuck, here's a tip: there's a debug renderer that displays the current state of liquids, including whether they are in the flowing variant or not. This renderer is designed for water, but it can be fairly trivially modified to support lava instead. The renderer itself is (mcp naming) net.minecraft.client.renderer.debug.DebugRendererWater (to use lava, case-sensitive replace the 5 occurrences of WATER with LAVA), and it can be enabled by setting waterEnabled to true in net.minecraft.client.renderer.debug.DebugRenderer (there is no hotkey to toggle this ingame in vanilla). Note that this is a debug renderer and there are some visual issues with it.

Here's some screenshots of the flows both before and after the source block is removed with that renderer enabled. These screenshots are without the fix given above.

The thing to look out for in testing seems to be blocks stuck in the flowing state - those are the ones that don't ever dissipate.

I'm currently not investigating this myself - this is just information that may be useful to others.

Seems like block updates should force liquids to go in stationary state. Random ticks shouldn't influence liquid flowing speed, so it won't affect cobblestone generators. In this example liquid will go back in flowing state, hopefully restarting the timer.

I guess you could technically fix it by scheduling a tile tick for every water and lava block in the world when converting a world to 1.13 and fix the return statement as described before.
If it is water or lava in an illegal state, I honestly see no other way besides refactoring liquid code entirely.

Can confirm for 17w47b