Water changes including #618

[rdebath]

These three commits

• Fix the "flashing water" issue (Where alternate ticks can toggle large volumes of ActiveWater) with a Water faucet hitting ActiveWater with AirFloodDown.
• Fix the CPU issue with finitewater not removing Physics entries #618
• Add a new feature to have finite water above the EdgeLevel and ActiveWater below.

With the last one I note that EdgeWater is a bit lame when combined with FiniteLiquids. So If both of these flags are set on a map the FiniteLiquids applies always to ActiveLava and to ActiveWater above the edge level. Below the Edge level ActiveWater ignores the FiniteLiquids flag and goes with Flood semantics. This allows flooding of underwater/underground bases but prevents flooding of the overworld.

(Not withstanding my opinion on finite EdgeWater you may want to put this on a distinct Option/property)

The *Faucet fix might make the WaterFaucet suitable for guest access as the block now appears to have no difficult to reverse effects.

Note these commit's can be merged individually if you prefer.

[UnknownShadow200]

Not fond of having finite water sometimes behave in an infinite manner, will do proper review tomorrow though

[rdebath]

Okay, just to be clear, "Finite_Water" is always finite, this is for the "Active_Water" block.

IMO the combinations of the options do make sense for Active_Water and the new one makes for a nice middle way.

• Finite=off Edge=* -- Water comes in from the ocean and floods always the whole map is under sealevel.
• Finite=on Edge=off -- No ocean, water makes piles like physical sand does.
• Finite=on Edge=on -- Above sealevel water doesn't flood. Below the edge the ocean floods everything.

[UnknownShadow200]

My mistake for being vague - I mean finite water in general, not just the finite water block

This change does seem to make it harder to trigger finite water to automatically flow (although that's also partly the fault of manual block changes only activating direct neighbours) , although not sure how much users depend on that

[rdebath]

This is the "eating CPU" commit.

With the old version, what you're seeing there is one result of the continuous polling from the finite water blocks. The physics on that gets stuck polling for changes all around the water block and so sees your deletion.

However, if you left the level (let it unload) and go back the physics items for those don't get restarted and the physics works as the new version not seeing the block deletions. Basically, it was inconsistent across a level reload.

Because of this I don't think the users could really "depend" on either way.

As we don't want that polling, the question becomes which way do we want the triggers to run, either inline with the current triggers on block deletion or adding more triggering to emulate the buggy polling?

Neither method feels "better" for me and I think I could make "realism" arguments either way (surface tension, sloping/flat surfaces, crumbling vs hard blocks).

[rdebath]

In response to you "not fond" comment, I've added an explicit option for water above the ocean level being finite and infinite below that level.

[rdebath]

As we don't want that polling, the question becomes which way do we want the triggers to run, either inline with the current triggers on block deletion or adding more triggering to emulate the buggy polling?

So which do you prefer? Extending the Air block place to emulate the effect of the Finite water polling or leaving as now to keep the "how finite water works after restarting the level"?

[UnknownShadow200]

The issues raised here made me think that some things about block physics in general need to be properly looked at and potentially redone, I just haven't found the time to do so