[1.10.2] Custom Liquid Deletes Water Sources

[Malkierian]

So, most parts of my liquids are working properly now, thanks to my other thread, but that thread is long gone now, so no necro here.

 

Anyway, my new problem is that when I place my custom liquid (which is made with MaterialLiquid), when it flows into a water source block, it deletes it.  This is default behavior, I commented out all references to onBlockAdded or onNeighborChanged.  It must be behavior in the water block itself, which means I can't change it by normal means.  This throws all of my intended interactions for a loop (when I have them enabled), causing any of my fluids' interactions with water to checkerboard (for example, when I have acid flow over water, it's supposed to turn the source blocks to clay.  This interaction works for the first time a flow is calculated, but on the next one, the water source block gets deleted, causing the acid flow to go under the surface of the water, which then causes the next one down to be hardened, and then the next ones out from there horizontally get deleted, etc).  Is this a problem with my liquid implementation that I can fix, or is this merely a known bug that cannot be remedied?  I get the feeling that this is because of the instantaneous change that happens from a static block to a flowing block before it sees that the source that was turned to clay is a solid block, and my code (which only compares to Blocks.WATER) doesn't account for that change, and thus the water source interaction is allowed to happen, but I can't find out how to check for a flowing source block in 1.10.

[Malkierian]

So I guess people need more information, so here's a video (gif) showing what I'm talking about:

Spoiler

(https://i.gyazo.com/e628bd839a3a87c1dea93b88ec1dddbc.mp4)

This happens even if I don't have my own custom class and just use BlockFluidClassic for my fluids, so there's no custom code to worry about interfering.  They are all of MaterialLiquid with varying map colors.  But, even if I completely disable my custom blocks' onNeghborChange methods by not calling the superclass's method, it still does it, so it must be in water's code.  And it doesn't check my liquid's stuff first, so it ends up doing this, if I have my interactions enabled:

Spoiler

(https://i.gyazo.com/8504690ac6718c8fb81367a47af50657.mp4)

And this was the result on the other side:

Spoiler

When it should have done this:

Spoiler

Please tell me this isn't intended behavior...

Edited June 2, 2017 by Malkierian

[V0idWa1k3r]

If your fluid block extends forge's BlockFluidClassic there are canFlowInto and flowIntoBlock methods you can override to define custom flow behaviour and have a chance of setting your 'interaction result' block instead of flowing into water, replacing it with your block and having it replaced by water next update.

Apart from that - yeah, water likes to replace stuff by itself. So do forge fluids. That can produce all sorts of behaviour if unhandled and even if handled... If the water flows over your block, for example, it will be replaced by water. As will most things that have blocksMovement returning false in their material. Not much that can be done here, vanilla behaviour. In this case your only chance is the neighborChanged method.

20 minutes ago, Malkierian said:

They are all of MaterialLiquid with varying map colors

If that is the reason for custom materials then you are doing it wrong, as there is Block::getMapColor.

 

20 minutes ago, Malkierian said:

onNeghborChange

Is not fired upon neighbor block updates. It only has something to do with comparator logic (it is only fired at World::updateComparatorOutputLevel which is fired by some blocks when their comparator level changes, itemframes, tile entities which have their default markDirty method called, ender eyes placed in frames, tileentities being removed and apparently when a blockstate is set that returns true at hasComparatorInputOverride)... So not fired when water flows into a block.

Edited June 2, 2017 by V0idWa1k3r
brackets

[Malkierian]

9 hours ago, V0idWa1k3r said:

If that is the reason for custom materials then you are doing it wrong, as there is Block::getMapColor.

Well, they're not water, so I wouldn't want them to be handled in that way.  What other reasons would you use MaterialLiquid than to make it something other than water?  I'm not trying to be belligerent or anything, I honestly want to know.  Why would you want to set a fluid's material to water when it isn't water?  Or, what other way is there to handle that without making its material water?

 

But thanks for the information about canFlowInto and flowIntoBlock, I'll look into those.

[Malkierian]

Alright, so I changed canFlowInto and even displaceIfPossible to only return true when the block it's flowing into is air or replaceable (check by Material::isReplaceable()), and I still get the checkerboard problem, but at the very least I don't get that constant back and forth shown in the first gif/video.  I didn't see any reason to override flowIntoBlock, since it only used displaceIfPossible anyway.

 

23 hours ago, V0idWa1k3r said:

If that is the reason for custom materials then you are doing it wrong, as there is Block::getMapColor.

Also, Block::getMapColor() is deprecated in 1.10, meaning it's likely to be removed soon, so your point about using that instead of MaterialLiquid to customize map colors seems invalid.

 

[V0idWa1k3r]

A lot of deprecations that currently exist don't necessarily mean that it will get deleted. Currently Mojang moves to blockstates system and those methods may move to there respectively(and they have, they just callback the methods in the Block currently). Or they may not move there. 

1.11.2 - those methods are still there.

neighborChanged is one such example. There is no non-deprecated alternative apart from one in IBlockState. It may get deleted. Or it may not. Same goes to the MapColor. You may create your own IBlockState implementation to be safe as methods there are not marked as deprecated.

13 minutes ago, Malkierian said:

I still get the checkerboard problem

 

23 hours ago, V0idWa1k3r said:

water likes to replace stuff by itself. So do forge fluids. That can produce all sorts of behaviour if unhandled and even if handled... If the water flows over your block, for example, it will be replaced by water. As will most things that have blocksMovement returning false in their material. Not much that can be done here, vanilla behaviour. In this case your only chance is the neighborChanged method.

 

13 minutes ago, Malkierian said:

to only return true when the block it's flowing into is air or replaceable (check by Material::isReplaceable())

Conviniently, Material.WATER returns true at Material::isReplaceable(). You might want to handle that too by replacing the water block with your interaction block using the flowIntoBlock method?

Edited June 3, 2017 by V0idWa1k3r

[Malkierian]

Little bit more information, if I set the viscosity of my caustic fluid to a certain level, then the interactions manage to keep up (with how I've set flowInto et al), but below that level, it's like the block change events can't keep up with the speed of the fluid, and it still flows into the water sources.  Now THAT sounds like a bug in Forge, I may just have to work around it and not have super fast liquids.