mojira.dev
MC-1390

Upper slabs with water/lava on top makes midair dripping water/lava

If you have an upper slab with water on top, the water will drip in midair. Looks silly. Same goes with dripping lava, I am guessing.

Related issues

Attachments

Comments

migrated
[media][media]
migrated

Makes sense, as the water drop effects are on the bottom of the block beneath the water, but certainly looks weird.

migrated

Confirmed in 1.4.5.

migrated

Added lava to title.

migrated

Confirmed as well. This started when top slabs/stairs gained the ability to spawn mobs.

migrated

confirmed

bugi74

This is pretty tough one to fix; the droplets are separate entities falling down. If they are created at the bottom of a upper half-slab (or similar blocks), they are "born" inside a block and consider themselves to be on ground, and thus end their travel just as immediately.

So two parts to the fix, one to calculate the starting height more accurately, and another part to let the droplet survive through its first block.

Fixes

BlockFluid.randomDisplayTick()

...
        if (random.nextInt(10) == 0
                //&& world.doesBlockHaveSolidTopSurface(x, y - 1, z)
                && world.getBlockMaterial(x, y - 1, z).blocksMovement()  // MC-9186
                && !world.getBlockMaterial(x, y - 2, z).blocksMovement()) {
            var21 = (double) ((float) x + random.nextFloat());
            // FIX: Adjust by block's lower bound:
            int blockId = world.getBlockId(x, y - 1, z);
            Block block = Block.blocksList[blockId];
            block.setBlockBoundsBasedOnState(world, x, y - 1, z);
            // var22 = (double) y - 1.05D;
            var22 = (double) y - 1.05D + block.getBlockBoundsMinY(); // FIX
            var23 = (double) ((float) z + random.nextFloat());
            ...

EntityDropParticleFX

private double firstY; // ADDED to record the height of start.

    public EntityDropParticleFX(World world, double x, double y, double z, Material material) {
        ...
        this.firstY = MathHelper.floor_double(y); // ADDED record the height of start.
    }

    public void onUpdate() {
        ...
        //if (this.onGround) {
        if (this.onGround && this.posY < this.firstY) {
            if (this.materialType == Material.water) {
                this.setDead();
        ...
        if (this.posY < this.firstY) {  // FIX
            Material var1 = this.worldObj.getBlockMaterial(MathHelper.floor_double(this.posX), MathHelper.floor_double(this.posY), MathHelper.floor_double(this.posZ));
            if (var1.isLiquid() || var1.isSolid()) {
                double var2 = // snipped for clarity, not part of fix.
                if (this.posY < var2) {
                    this.setDead();
                }
            }
        }  // FIX
    }

Tested on 1.4.7. Half-slabs seem to work ok. Unfortunately, for some reason, the normal stairs tries to confuse things by claiming to have its boundsMinY() at 0.5, which causes the drops to start half-way through it, too. It shows as not having the slow start, but the droplets come out at full speed immediately at the blocks bottom. Its a cosmetic thing, but since we're trying to fix a cosmetic thing in the first place...

However, both changes "make sense" and should improve the situation overall, so I'll provide those fixes for now. Will try to find out the reason for the stupid stairs..

Edit: Found part of the reason for the stairs. As soon as the aiming reticle is moved on top of any stairs block, the bounds minY will be changed for all stairs to have minY 0.5 for the rest of running. Sigh.
Edit2: That seems to be another bug, now with a fix too: MC-10806

migrated

whoa! there should be more people like you!

bugi74

Indeed. I can apparently do only about 5-10 fixes a week, and that is mostly relatively easy ones. There's only several hundred more to go, and many of them are not easy... (And I avoid redstone/lighting/client-server related issues.)

Luckily those awesome coders from Mojang help occasionally a bit 😃 Hmm, but then again, I've heard rumors that they also make more bugs šŸ˜› Kinky.

Okay, enough joking, this isn't a "social" website-thing. Back to bugfixing. *Continues talks with Estonian "consultants" about "persuading" some stubborn village traders to start selling some goods.*

CubeTheThird

Is this still a concern in the current Minecraft version 1.6.4 / Launcher version 1.2.5 ? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

migrated

yes I don't see why it isn't fixed yet. The fix is right there ^

Torabi

Apparently modifications to the code produced by MCP isn't particularly useful to them.

migrated

oh wow, that sucks. Someone should tell him, though the fact that the code is different doesn't mean that stuff that gets added isn't useful. But I don't know anything about that.

bugi74

@Torabi
While the MCP code doesn't look the same as the original, the fact of proving it fixable with just minor code changes is a very nice (and big) step towards fixing it. It'll handle finding the root cause, tests/debugs the solution, and provides directly readable fix. While the code is different, the basic structures are typically 99% the same, so it should only take couple minutes to find the corresponding piece of code in the Mojang's version, and couple more minutes to adapt the fix, and then few more to test/confirm it works.

The code differences makes it harder to bring whole mods or larger code changes from MCP-derived sources, but that is why I have been working hard to make my fixes with as small changes as possible, leading often to coding-wise awkward solutions. But even the awkward ones can give a nice starting point for better solutions.

bugi74

Affects 1.6.4.

migrated

Affects 1.7.2

migrated

Confirm 1.7.2

bugi74

Affects 1.7.4.

Ezekiel

Is this still a concern in the latest Minecraft version 14w08a? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

migrated

Yes, still in 14w08a.

qmagnet

Confirmed for 15w36d

migrated

Confirmed for 1.9-pre1

FaRo1

Confirmed for 1.10.

FaRo1

Confirmed for 1.10.1.

migrated

Confirmed for 1.10.2.

FaRo1

Nope, too late. šŸ˜‰

bemoty

Can confirm for MC 1.12.1.

Asteraoth

Confirmed for 18w11a

muzikbike

Affects 18w14a

muzikbike

Affects 18w14b

muzikbike

Affects 18w15a

muzikbike

Affects Bedrock Edition, see MCPE-32639

muzikbike

Affects 18w16a

muzikbike

Affects 18w20a

muzikbike

Affects 18w20b

muzikbike

Affects 18w20c

muzikbike

Affects 18w21a

muzikbike

Affects 18w22a

muzikbike

Affects 18w22b

wobst.michael

@unknown, ticket is yours now

muzikbike

Fixed in 1.13-pre7 (!!!!!)

migrated

Confirmed fixed.

migrated

Sorry that I’m a bit late, but please reopen this issue, perhaps with the vanilla-parity tag.

bugi74

Did this bug come back in the Java edition?

If it came back (or the dripping of liquids through blocks/slabs -"feature" was added) in Bedrock edition instead (and apparently needs to be after version 1.14/Buzzy Bees, according to https://feedback.minecraft.net/hc/en-us/articles/360015877192-Parity-Requests-and-You-A-Guide), it should be reported in the bedrock edition tracker. (https://bugs.mojang.com/browse/MCPE-32639).

muzikbike

(Unassigned)

Confirmed

dripping, lava, rendering, slab, water

Minecraft 1.4.2, Minecraft 1.4.5, Minecraft 1.4.6, Minecraft 1.4.7, Snapshot 13w03a, ..., Minecraft 1.13-pre2, Minecraft 1.13-pre3, Minecraft 1.13-pre4, Minecraft 1.13-pre5, Minecraft 1.13-pre6

Minecraft 1.13-pre7

Retrieved