liquids (water, lava) vanish when placed under y-level 0

[BigDaddyRichard]

sorry for posting two in the same day but lava in the overworld seems to just vanish whenever in range

[BigDaddyRichard]

found out what the issue is, lava doesn't vanish but all liquids vanish whenever under Y level 0

[Felicis]

that is odd indeed...

actually that might be a hardcoded value somwhere I did not notice... I'll have a look around :eyes:

[Felicis]

Also right now I am trying to fix the waterlogging of all blocks (which breaks most modded blocks, things disappear if you pour water on it, etc etc), and maybe that will fix the lava already. Otherwise I'll have to look into it afterwards

[djmrFunnyMan]

actually that might be a hardcoded value somwhere I did not notice... I'll have a look around 👀

Pretty sure that's it. In the original, water was deleted when it reached Y = 0 so you could drain oceans into the void (was pretty cool) so I suppose that's hardcoded.

This will need to a bit more complicated now since the void is at -64 in the overworld but 0 in end and nether but also you can set the "min_y" to anything you want using datapacks and custom dimensions.

[Felicis]

I'll have to check in the 1.18 game code, but in 1.16 World.java I found this, which could replace the hardcoding:

public static boolean isOutsideBuildHeight(int p_217405_0_) {
   return p_217405_0_ < 0 || p_217405_0_ >= 256;
}

[djmrFunnyMan]

I actually have no idea how to code but I don't think this would replace the hardcoding? This seems to only say that anything below 0 and above or equal to 256 is outside the build height which is not true in 1.18

[Felicis]

oh, the code I posted is original minecraft code (by mojang), it is not by me. If there is something similar in the mojang minecraft code of 1.18 (which I assume), it would probably contain dimension checks and different numbers depending on the dimension. Using this function in the mod means you dont have to "hardcode" the numbers yourself; or to put it in another way: someone has to hardcode the numbers somewhere, and it's more elegent (and more maintainable) if you dont put the numbers in your mod :)

[Felicis]

this is probably going to get fixed because the bug was in skds-core, which is being ditched. But we won't know before I pull the changes to 1.18 :sweat_smile:

[djmrFunnyMan]

also fyi this isn't exclusive to 1.18 because you can already enable negative world height in 1.17 with datapacks

[Modog500000]

I'll have to check in the 1.18 game code, but in 1.16 World.java I found this, which could replace the hardcoding:

public static boolean isOutsideBuildHeight(int p_217405_0_) {
   return p_217405_0_ < 0 || p_217405_0_ >= 256;
}

Not sure when this was introduced but in 1.19+ there is a method in Level for this. (Level.getMinBuildHeight();)

[Modog500000]

Solution:

public static boolean isOutsideBuildHeight(int p_217405_0_, ServerLevel level) {
   return p_217405_0_ < level.getMinBuildHeight() || p_217405_0_ >= level.getMaxBuildHeight();
} 

[SKWID011]

I don't expect to get any reply soon but where is this 1.18 World.java file? Was going to see if Modog's solution works at all, Unless there is a fixed version somewhere? Also wouldnt the

for (int index = 0; index < 4; ++index) { if (level <= 0) { break; } if (cancel) { return; } Direction dir = Direction.from2DDataValue((index + i0) % 4); equalizeLine(dir, false, dist);

Inside the FFluidEQ.java be a problem as well or does something overwrite it? There is also similar code inside the FFluidDefault and V2 files that look to be telling the same thing.

[Felicis]

The whole 1.18 code is a mess and I won't use it anymore. I'll upgrade the new 1.16 version to 1.18, and then everything will make more sense and I'll be able to fix bugs more easily :)

-------- Original Message -------- On 4/20/24 15:45, SKWID011 - notifications at github.com wrote:

I don't expect to get any reply soon but where is this 1.18 World.java file? Was going to see if Modog's solution works at all, Unless there is a fixed version somewhere? Also wouldnt the

for (int index = 0; index < 4; ++index) { if (level <= 0) { break; } if (cancel) { return; } Direction dir = Direction.from2DDataValue((index + i0) % 4); equalizeLine(dir, false, dist);

Inside the FFluidEQ.java be a problem as well or does something overwrite it? There is also similar code inside the FFluidDefault and V2 files that look to be telling the same thing.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>