Make grass, flowers, fire, crops and torches floodable.

[red-001]

No description provided.

[PilzAdam]

👍

[tenplus1]

Great idea, would it be possible to have grass / flowers / crops drop as an item when it gets flooded though ??

[red-001]

@tenplus1 that would need an engine change.

[ghost]

Could possibly register an ABM, such that the node gets the level of any adjacent liquid and drops itself if that level is greater than one.

That's just a guess, I have no clue how well that would work in practice -- or even whether it's possible. I only did a cursory look at lua_api.txt and saw minetest.get_node_level().

[red-001]

@everamzah That would be very slow. It would be a lot better to fix the engine.

[ghost]

I think you mean that it would cause considerable strain or overhead. Would it be slow if the ABM's interval and chance were 1 and 1.0?

If this were an engine change, would it be a hard coded behavior to drop? Or would it be an on_flood callback in the node def?

[paramat]

Indeed floodable destroys the node and doesn't drop it, we wouldn't want to lose flowers, crops and torches, but fire could perhaps be destroyed. However we already have an ABM for extinguishing fire with water and it causes a hissing sound, making fire floodable would extinguish faster but without a sound, therefore inconsistent.
So 👎 as it is but let's discuss further.

[tenplus1]

Adding an on_flood callback would be a good idea as it would solve most problems by allowing the item to be dropped and adding a sound.

[red-001]

So should I add an on_flood callback?

[C1ffisme]

@red-001 I was thinking the same thing.

If not an on_flood callback, then just change the engine to drop items when they are hit by water.

[est31]

Griefers will enjoy this. Perhaps slow down the spreading speed of water to one node per minute, similar to fire?

[est31]

reducing water spread would also reduce processing.

[tenplus1]

Wouldn't one node per minute be too slow ? What is it currently set to ?

[red-001]

@tenplus1 one node per second?

[C1ffisme]

No... Please... Not one node per minute. That would mean people not trying to cause grief are waiting 15 full minutes for water to spread fully.

@red-001 It seems like the current water is a bit slower than that.

[paramat]

So should I add an on_flood callback?

Not sure about this, as this is in liquid flow code which needs to be simple and fast.
Remember that 'floodable' is intended to be for vacuum, atmosphere and fog nodes to allow liquids to flow in, it is meant for generalising liquid flow in airlike nodes instead of expecting "air" only, it is not a feature intended for dropping certain nodes, obviously we wouldn't want to drop vacuum and atmosphere nodes.
So i don't think there's much need for 'on_flood'.

I'm not sure about destroying long grass nodes, i wouldn't expect these to be destroyed by water. Accidental floods of water would cause ugly bare patches in biomes. Also it's not good to encourage players to use water floods to clear grasses.

As it is this PR would be griefer's paradise and would destroy valuable torches, crops and flowers.

[tenplus1]

It would only drop a node if the on_flood callback says it should, so airlike or vacuum would have nothing to drop, but flowers and crops would be very important so they wouldn't be lost... Also, having water flow into lava could easily call the on_flood to replace flowing water with cobble and lava_source with obsidian, having a greater purpose and reducing the abm's for this function, this would also allow water and lava to flow downwards beside one another.

[C1ffisme]

@paramat If a griefer can spread water into an area, then he can spread lava as well, so we really aren't adding anything any more harmful. It would be like denying a store the ability to sell fireworks when it contains TNT.

True, water is a lot more common and easier to get than lava, but if you really wanted to cause damage, and not just make people have to re-wait for their crops to grow, then lava will do more destruction.

Plus, why not use fences?

EDIT : And for modded users, this means the water wheel has a use now:

[paramat]

tenplus1 good points, on_flood should be considered then.

[paramat]

@PilzAdam PilzAdam did you +1 this thinking the nodes would be dropped?

[PilzAdam]

@paramat I have 👍'd this because I think these nodes should be floodable. I haven't considered dropping back then.

Of course you are right that these nodes shouldn't be simply destroyed by water. Maybe an additional flag is needed in the engine, that specifies what happens with nodes flushed away by water?

[paramat]

An 'on flood' callback would perhaps be best for dropping nodes, see tenplus1's comment.

EDIT But on_flood would have to be called from the engine liquid code, not sure if this is possible or allowed. Maybe the node could be dropped if not airlike, or whatever.

[sofar]

maybe

floodable - node is destroyed and replace with liquid
flushable - node drops and is replaced with liquid

?

[sofar]

Actually protocol wise floodable is a u8. We could use 0, 1 and 2 to signify "not floodable", "floodable" and "floodable+drops"

[tenplus1]

+1 to u8 specific setting, flood or flood+drops.

[paramat]

👎 I'm not keen on the idea of water flushing and dropping certain nodes, it's not much needed and would cause a mess with accidental or griefing floods of water. It would encourage the use of water for harvesting or clearing certain nodes, meaning more mess made by water.
This would slow down speed-critical liquid flow code.

[C1ffisme]

@paramat Yes, it could be used for griefing, but even then it can be used for good purposes too, such as auto-farming or "mowing" lawns.

[tenplus1]

+1000 we need this feature in the game engine, it can be used for so many things... It will also HELP to clear up water griefing by dropping grass/flowers instead of getting stuck inbetween those nodes and having to place blocks to tidy it all up.

[Ekdohibs]

👍 for an on_flood() callback and adding this (with drops)

[paramat]

I'm not sure the slowdown is worth it. With 'on flood' it would be called every time a liquid flows into air or any other floodable node. Liquid flow is already performance-critical.

It will also HELP to clear up water griefing by dropping grass/flowers instead of getting stuck inbetween those nodes and having to place blocks to tidy it all up.

Whether those nodes are dropped or not makes no difference, the cleanup is the same either way, just remove the source nodes. The extra dropped nodes mean more mess to sort out.

I wouldn't expect water to wash away grasses, flowers and crops, only damage. The Minecraft habit of using water to clear areas or harvest is crude and should not be encouraged. What's nice about current water is that once it's gone things are as they were.

[tenplus1]

If adding an on_flood function slows things down too much then how about using sofar's option of having floodable node either disappear or drop, that simplified things a lot and it stops wanted nodes from disappearing.

[sofar]

I'd rather see an actual fact-based experiment to see how bad on_flood actually would be. I have my doubts that it actually is bad.

This is highly related to minetest/minetest#3805.

experiment, measure, discuss. In that order.

[Ekdohibs]

@paramat An on_flood function would only be called for nodes that define it, so there would be no slowdown...

[paramat]

Yes i know, i'm just thinking about the act of searching for registered 'on flood' functions, i agree this will be lightweight, but just not sure there is enough need.

[paramat]

👎 In reality water damages crops more than it pulls them out of the ground, making water drop crops means Minecraft type water-harvesting which pulls crops out of the ground without damaging them.
Clearing an area of grasses using a flood of water is also a bad behaviour i dislike seeing in MC videos.

Water would extinguish torches but not necessarily pull them off the wall.

The usage for extinguishing fire is valid, the advantage being faster action, but i don't think it's enough justification.

For the moment, i will not work on a callback, and will vote against it.

[red-001]

How else would you fix the problem of being able to stop water with grass?

[paramat]

That may not be realistic, but it's not a problem and the alternative is worse.

[C1ffisme]

@paramat Ummm... This allows for the slightest amount of automation in vanilla Minetest, something that most people need mesecons, combined with other mods to get right now.

Whether or not the way Minecraft does it is unrealistic or not, the way Minetest does it right now looks really terrible.

If we want to go for any kind of realism, then water would flow through plants, but this is not possible since only one node can exist in one position. (Using entities in this situation would be really bad, since a griefer would only have to pour water onto large fields of grass to cause lag.)

Speaking of Griefers, we already have locked chests and locked doors in the game, which implies that we have some level of security for multiplayer.

(This would be in a protected/claimed area, so the fences would not be diggable. And the fences prevent water from entering the farm.)

[est31]

@C1ffisme what about water from coming above? You can easily get above the protection and then place water right above.

[paramat]

A cell of water held in place by plants looks a little odd, but would very rarely happen.
It's fairly acceptable, in Minetest a node is impassable whether it's a full cube or not, think about nodeboxes or fences, are we then going to make them floodable?

Speaking of Griefers, we already have locked chests and locked doors in the game, which implies that we have some level of security for multiplayer.

That's not the issue, the griefing issue is a mess of other items easily created by water, once the water is gone an ugly bare patch would be left in grassland and i doubt players would have the patience to recreate the long grass distribution.
Enabling clearing of plants and harvesting of crops by water (which is lazy, ridiculous and crude behaviour, a big mistake in MC) would encourage more use of water, resultng in more accidental floods and griefing and more mess.

[C1ffisme]

@est31 True. Not every security system is perfect. You could also surround it in glass, greenhouse style.

@paramat

A cell of water held in place by plants looks a little odd, but would very rarely happen.

No, but this might:

It's fairly acceptable, in Minetest a node is impassable whether it's a full cube or not, think about nodeboxes or fences, are we then going to make them floodable?

No. There is some level of game balance involved here. Nobody wants to spend 30 seconds doing something easily done in 2 seconds. Not only that, but unless you choose to pull the grass out with your hands, you are going to waste durability on your sword that could be used for fighting things instead.

Enabling clearing of plants and harvesting of crops by water (which is lazy, ridiculous and crude behaviour, a big mistake in MC)

I'm sorry to pull out this card, but this statement is just pure opinion.

Nobody on this earth wants to preform an action repeatedly (which is already a problem in Minetest or Minecraft, or other 'Mining' games, although caves and monsters can sometimes make this a bit more interesting). Like mining, digging through areas of grass means walking and digging, but now with the slight extra mental effort of knowing where to dig.

That's not the issue, the griefing issue is a mess of other items easily created by water, once the water is gone an ugly bare patch would be left in grassland and i doubt players would have the patience to recreate the long grass distribution.

Before I dug some grass:

After :

It doesn't look too bad either way. Sure, some items would be left behind, but this could be solved with adding auto-pickup items, or a script that deletes items if they have been out for too long.

[paramat]

Nobody wants to spend 30 seconds doing something easily done in 2 seconds. Not only that, but unless you choose to pull the grass out with your hands [...]

Nobody on this earth wants to preform an action repeatedly [...] Like mining, digging through areas of grass means walking and digging, but now with the slight extra mental effort of knowing where to dig.

This is ridiculous, let's make water drop all nodes then as no one wants to mine blocks.
You're promoting a bad feature of MC through assuming everyone is too lazy to do anything, players will just have to do the work, as currently.

It doesn't look too bad either way

Not too bad because it's low-density grassland, now consider the effect on crops or gardens.

Sure, some items would be left behind, but this could be solved with adding auto-pickup items

That's not going to happen in default MTGame as explained in the relevant thread, something so complex is for a mod.

[paramat]

So we've agreed on an on_flood callback, which needs work in engine.
Once that's done i will still -1 flooding grasses, flowers, crops. Fire is ok if the extinguish sound is played. Torches maybe still not sure.

[est31]

Remember to keep the on_flood callback generic from the liquid type, water shouldn't be something special.

[C1ffisme]

@paramat

This is ridiculous, let's make water drop all nodes then as no one wants to mine blocks.

There is a certain amount of gameplay balance put in place. (As well as realism, but this is irrelevant in a voxel game.)

Digging through grass returns you very little reward. (Seeds, which require growing to get anything good.)

Digging through stone takes a bit less mental effort, and gives much quicker rewards. (Diamonds or Coal, or Ores which do not require randomly based timers to produce reward.)

[0-afflatus]

An on_flood callback seems like the WTG - it makes it mod-able.

[paramat]

We're agreed on an on_flood callback, and this PR can't be merged, best that a new PR is opened once the callback is added on the engine side.

[rubenwardy]

Once that's done i will still -1 flooding grasses, flowers, crops

I personally think that it should destroy land plants rather than drop them

As for the griefing issue, servers could always disable this if they wish to