| Type: | Bug | ||
| Reporter: | Connor Steppie | Assignee: | Unassigned |
| Resolution: | Fixed | Votes: | 45 |
| Labels: | dripping, lava, rendering, slab, water | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||||||||||||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
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. |
| Comments |
| Comment by Markku [ 24/Aug/20 ] |
|
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). |
| Comment by Lloyd Spee [ 24/Aug/20 ] |
|
Sorry that I’m a bit late, but please reopen this issue, perhaps with the vanilla-parity tag. |
| Comment by user-f2760 (Inactive) [ 10/Jul/18 ] |
|
Confirmed fixed. |
| Comment by Connor Steppie [ 10/Jul/18 ] |
|
Fixed in 1.13-pre7 (!!!!!) |
| Comment by [Mod] Michael Wobst [ 31/May/18 ] |
|
Awesoman3000, ticket is yours now |
| Comment by Connor Steppie [ 31/May/18 ] |
|
Affects 18w22b |
| Comment by Connor Steppie [ 30/May/18 ] |
|
Affects 18w22a |
| Comment by Connor Steppie [ 23/May/18 ] |
|
Affects 18w21a |
| Comment by Connor Steppie [ 18/May/18 ] |
|
Affects 18w20c |
| Comment by Connor Steppie [ 16/May/18 ] |
|
Affects 18w20b |
| Comment by Connor Steppie [ 15/May/18 ] |
|
Affects 18w20a |
| Comment by Connor Steppie [ 19/Apr/18 ] |
|
Affects 18w16a |
| Comment by Connor Steppie [ 16/Apr/18 ] |
|
Affects Bedrock Edition, see |
| Comment by Connor Steppie [ 11/Apr/18 ] |
|
Affects 18w15a |
| Comment by Connor Steppie [ 05/Apr/18 ] |
|
Affects 18w14b |
| Comment by Connor Steppie [ 04/Apr/18 ] |
|
Affects 18w14a |
| Comment by [Mod] Asteraoth [ 14/Mar/18 ] |
|
Confirmed for 18w11a |
| Comment by [Mod] bemoty [ 12/Aug/17 ] |
|
Can confirm for MC 1.12.1. |
| Comment by Fabian Röling [ 23/Jun/16 ] |
|
Nope, too late. |
| Comment by null (Inactive) [ 23/Jun/16 ] |
|
Confirmed for 1.10.2. |
| Comment by Fabian Röling [ 22/Jun/16 ] |
|
Confirmed for 1.10.1. |
| Comment by Fabian Röling [ 10/Jun/16 ] |
|
Confirmed for 1.10. |
| Comment by Immaterialise [ 17/Feb/16 ] |
|
Confirmed for 1.9-pre1 |
| Comment by qmagnet [ 10/Sep/15 ] |
|
Confirmed for 15w36d |
| Comment by Jonathan Haas [ 22/Feb/14 ] |
|
Yes, still in 14w08a. |
| Comment by [Mod] Ezekiel (ezfe) [ 21/Feb/14 ] |
|
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. |
| Comment by Markku [ 21/Dec/13 ] |
|
Affects 1.7.4. |
| Comment by Stéphane Lamarche [ 27/Oct/13 ] |
|
Confirm 1.7.2 |
| Comment by Stéphane Lamarche [ 27/Oct/13 ] |
|
Affects 1.7.2 |
| Comment by Markku [ 30/Sep/13 ] |
|
Affects 1.6.4. |
| Comment by Markku [ 29/Sep/13 ] |
|
@Torabi 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. |
| Comment by Jesper the End [ 27/Sep/13 ] |
|
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. |
| Comment by [Mod] Torabi [ 27/Sep/13 ] |
|
Apparently modifications to the code produced by MCP isn't particularly useful to them. |
| Comment by Jesper the End [ 26/Sep/13 ] |
|
yes I don't see why it isn't fixed yet. The fix is right there ^ |
| Comment by [Mod] CubeTheThird [ 26/Sep/13 ] |
|
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. |
| Comment by Markku [ 02/Mar/13 ] |
|
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 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.* |
| Comment by Jesper the End [ 02/Mar/13 ] |
|
whoa! there should be more people like you! |
| Comment by Markku [ 02/Mar/13 ] |
|
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. |
| Comment by Jesper the End [ 22/Jan/13 ] |
|
confirmed |
| Comment by DarkWolff [ 17/Dec/12 ] |
|
Confirmed as well. This started when top slabs/stairs gained the ability to spawn mobs. |
| Comment by Tails [ 17/Dec/12 ] |
|
Added lava to title. |
| Comment by Tails [ 01/Dec/12 ] |
|
Confirmed in 1.4.5. |
| Comment by Anon Ymus [ 30/Oct/12 ] |
|
Makes sense, as the water drop effects are on the bottom of the block beneath the water, but certainly looks weird. |