liquidlogged nodes

[metmj]

Problem

it is not possible to create a 1:1 equivalent for liquidlogged MC nodes at this time:

• block.minecraft.kelp_plant & block.minecraft.kelp,
• block.minecraft.bubble_column.

This block can looks like MC with some tricks, but other things is not available:

• block.minecraft.seagrass & block.minecraft.tall_seagrass,

Plantlike_rooted height only works at small range (API says param2/16 so 16m). MC kelp have 26m as default limit, but you just get unlimited height if you know how to use it (this is not an MC bug). So this means in MC kelp can be around 380m high - param2 only offers 256 possible values ​​:(

Solutions

In my opinion, the easiest way will be to change the liquid rules and use liquid nodes (combined function - as liquid source and plant etc.) instead plantlike_rooted.

• change API
  • actually you can use only source or source and flow, add shared flow option (2 or more sources and 1 flow), grouped by liquid_alternative_flowing_id,
  • flowing can create only source defined in shared flow. liquid_alternative_source_id should be also defined as:
    key (info about possible sources),
    value (function to determine when place this node).
• change the logic to satisfy this option

Alternatives

Use Minecraft instead Minetest 👎

Additional context

No response

[metmj]

@appgurueu

[cx384]

Related to #3074 and #14103 (and closed #13388)

[AlexKurisu]

IMHO implementing a proper generic multipart-like API will be more useful (and could also be used for fluidlogging)

[appgurueu]

Sorry for the late reply. I think "waterlogged" / more generally "liquidlogged" nodes are a sensible feature request. I have some rough ideas for how this could look but these still need to be fleshed out.

Plantlike_rooted height only works at small range (API says param2/16 so 16m).

Yes, that's true. It's also not really feasible to go over / extend this limit due to our selection box & collision box logic. Nodes getting too large breaks too many invariants too strongly. plantlike_rooted plants are ultimately limited to staying somewhat close to the ocean floor. (And I agree that this complicates mod code and impedes performance along with limiting height and structure of underwater plants.)

There are also other things players may want underwater: Underwater torches, mesh nodes - not just plants.

So yes, we need something better than plantlike_rooted for better "waterlogging".

In my opinion, the easiest way will be to change the liquid rules and use liquid nodes (combined function - as liquid source and plant etc.) instead plantlike_rooted.

Yes, it makes sense to have nodes that are both a "liquid" (flowing or source) node and some other drawtype. For all liquid logic purposes, these nodes could be treated as if they were the appropriate liquid, though we need to be careful when updating nodes. For drawing, we would have to draw both the node and the water. This means that param2 won't be usable for flowingliquid + something else nodes.

API-wise, there could be a new node definition field, something like inside = nodename, where nodename is that of a flowing or source node. We would only allow drawtypes that don't need param2 if nodename is a flowing liquid, and would enforce that param2 be used to store the flowingliquid information. Thoughts?

[metmj]

@appgurueu I don't know if it will be necessary to use it with a floating liquid (param2 is 8 bits unsigned integer but flowingliquid use only 4 bits - so maybe another 4 bits use as rotation?), certainly for the source param2 must be adaptative as it is now