Minecraftforge: [1.14][Feature] Forge "waterlogged" block state

[Alpvax]

Now that 1.13 is adding support for water inside the same block as other blocks via the "waterlogged" state, can we start a discussion about how to implement a similar system for forge-added fluids.

Hopefully by the time we have a rough idea of what we want to do (some interactions should not work, e.g. hot/burning fluids with wooden fences), and how we want to do it (blockstate containing another blockstate seems like a bad idea), there will be a working release of Forge to start implementing on.

Could someone with access flag this as [1.13] [feature] please?

[williewillus]

this subsystem is highly incomplete in 1.13. IFluidState exists but it basically just reads waterlogged off the blockstate and then returns water.

i would hold off on trying to do this in forge until mojang actually finishes fully separating fluids and blocks, which dinnerbone has shown attempts of.

[KingLemming]

So are we punting this to 1.13.1, or does this seem like more of a 1.14 feature?

I'd like to start in on a Fluid rewrite (proper registries, etc).

[Alpvax]

@williewillus I hadn't realised that Mojang were working on separating them, I assumed they were leaving it at water (as their other fluid is opaque and likely to destroy many of the non-full blocks). As this is the case I agree that waiting to see what they come up with is the best course of action.

[williewillus]

yeah, at least some time in 1.13 they were working on fully separated fluids/blocks, like Bedrock Ed.
See: https://twitter.com/Dinnerbone/status/988712909315493888

It got pushed out of 1.13.x but the way the code looks right now heavily implies that more is coming

[jjlrjjlr]

I would also add that at one point it appeared dinnerbone was testing "lavalogged" blocks.

https://twitter.com/Dinnerbone/status/988386661661925377

[Hypsellis]

Do you plan to add a support for waterlogged features to lava and all other fluids ?

[KingLemming]

This will likely need 1.14, from what I can tell as an uninformed observer.

[SkyHawkB]

Forge 1.13 might not even really take off, like 1.9 it's more of a stepping stone. I'd wait for 1.14 and focus more on that.

[Unnoen]

Fluid API solves this - https://github.com/MinecraftForge/MinecraftForge/pull/5983

[gigaherz]

5983 does in fact NOT solve this. A proper world fluid layer would need to be implemented to support blocks containing "any" liquid, instead of a predetermined subset of fluids.

[ExpensiveKoala]

If I understand it correctly, the reason for the difficulty in adding this is because we would need to know all added fluids beforehand as blockstate properties shouldn't be dynamic.
Does anyone know of a good way of getting around this?

[tterrag1098]

There is no easy way. The correct way is to separate fluids into their own data layer, entirely separate from blockstates. This is what vanilla planned/plans to do, and what we could maybe do ourselves. But it will never work within the blockstate system.

[ShadewEnder]

What if forge just hooks into the WATERLOGGED property? This property now takes true and false. If this property is made a special property that extends true and false with any other fluid registered, how would that work?
(I know this changes the generic type of the property, and thus requires some patches to change the boolean type to something else, but it makes many modders (at least me) happy - or change the type to Object, that's even better).

[diesieben07]

That is not how block states work, Shadew. You can only store properties with a fixed set of values.

[ShadewEnder]

It is a fixed set of values when all mods are loaded - isn't the fluid registry frozen by then? I have seen a Fabric mod actually doing this (or something similar at least) so it's possible...

[diesieben07]

It is not that simple.
Block state IDs are stored in the world, so need to be fixed. So when a new fluid is added you must take care to add it to the end so the previous IDs don't change. And if one is removed you better keep that ID free or the IDs will shift.
And you better not add too many fluids because then you just have an explosion of block states which are precomputed (especially for blocks which have more than just the waterlogged property, cartesian product is a b**).

tl;dr: No.

[ShadewEnder]

That's the only thing I forgot about - thanks for the reminder... I only doubt how that works with palettes now, afaik a palette maps ids to block state _NBT-compounds_, _per chunk_ (or I am very wrong - yes I am, not? - yes - don't answer - no I'm not)...

Ok I will research on this more before bothering anyone here again...