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

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

whoa! there should be more people like you!

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.*

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.

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

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

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.

@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.

Affects 1.6.4.

Affects 1.7.2

Confirm 1.7.2

Affects 1.7.4.

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.

Yes, still in 14w08a.

Confirmed for 15w36d

Confirmed for 1.9-pre1

Confirmed for 1.10.

Confirmed for 1.10.1.

Confirmed for 1.10.2.

Nope, too late. 😉

Can confirm for MC 1.12.1.

Confirmed for 18w11a

Affects 18w14a

Affects 18w14b

Affects 18w15a

Affects Bedrock Edition, see MCPE-32639

Affects 18w16a

Affects 18w20a

Affects 18w20b

Affects 18w20c

Affects 18w21a

Affects 18w22a

Affects 18w22b