I have a couple of points to make regarding customizing this feature:

1. Could you add a way to disable, lessen, (or even increase) the cost multiplier of clearing water tiles?
2. Could you add a way to disable the water depth check when building ship depots?
3. Could you add a way to reduce the max water depth from level 15 (even all the way to 0 to disable this feature)?

@James103 Point 1 and 2, maybe. For cost of clearing water, the setting could be between "no multiplier", "more expensive by depth" and "much more expensive by depth" with the last being my current square-of-depth multiplier.

Point 3 I don't think is a good idea. NewGRF support will be more complex if depth levels can be arbitrarily limited.

We cannot add options to disable every single change to the game.

This, along with the earlier "neutral stations only serve their owning industry" change are support for changing the long-standing TT tradition of filling in the ocean. With deep ocean being expensive to fill in, building bridges crossing large water bodies as short segments with intermediate islands for signals, is also much less viable, making transfer to ships or longer routes around the water body more attractive. In all, I think this change will make for much more interesting gameplay.

This, along with the earlier "neutral stations only serve their owning industry" change are support for changing the long-standing TT tradition of filling in the ocean. With deep ocean being expensive to fill in, building bridges crossing large water bodies as short segments with intermediate islands for signals, is also much less viable, making transfer to ships or longer routes around the water body more attractive. In all, I think this change will make for much more interesting gameplay.

I sense this would also imply the need for more vessel types for navigating diff depths and balancing ships overall, meaning new vehicle graphics of some sort would be necessary as well. It would also make canals for bigger ships much more expensive, privileging small-ship networks for inland canals. So many interesting options!

With this change, clearing a large enough body of water will cause the total cost to roll past 64 bits, resulting in an overflow and possibly gaining money.

• Cost to clear water tile of depth 0: 7,500
• Cost multiplier from depth 15: x225
• Maximum map size: x16,777,216 tiles
• Max NewGRF cost multiplier: x65,536
• Max inflation multiplier: x887
• Total Cost to clear All-Water 4k map: 1,855,425,871,872,000,000
• Total Cost to clear All-Water 4k map after inflation: 1,647,156,981,589,051,266,457
• Maximum Tiles before 64-bit Overflow (after inflation): 93,945 tiles
• MAX_INT64 (signed): 9,223,372,036,854,775,807

Therefore: there is a risk of a 64-bit overflow after this change, but it only applies when estimating the cost in the Scenario Editor. If the cost multiplier per unit of depth were just 0.5-1 higher than what it is now (depth^2.5 or depth^3), then said risk would become real as the number of tiles required to be demolished to trigger a 64-bit overflow would now fit within the maximum tile clearing limits.

I'm glad to hear that the cost of filling in the ocean is finally getting reasonable. I don't think the above shows a problem with this PR, rather if an underflow can occur that's a bug in the Money class. Also, wouldn't you generally hit the landscaping limit throttle before the underflow?

Looks like the regression tests are failing (as of 8f59276). Can you please check where the regression tests are failing and why they are failing?

they fail because it cannot place a ship depot

What @SamuXarick says. I'm looking into a bug with how water depth is restored when a ship depot gets cleared, the problem is that it doesn't. (So you can glitch depth by filling a deep area with depots, clearing them, and then filling in the sea to avoid a few millions in cost.)

The regression tests are still failing. Why? Is it because of not enough money? Additionally, the macOS regression test timed out after 1 hour. The logs say that the regression test AI "script died unexpectedly".

The regression is failing because the program crashes. The program crashes because of an assertion error. The assertion error is that a tile that was expected to be water was not water. The assertion happens during destruction of a ship depot.

The macOS build hangs because it does not handle crashes in the regressions tests.

With this change, clearing a large enough body of water will cause the total cost to roll past 64 bits, resulting in an overflow and possibly gaining money.

There are multiple ways to handle such a situation. One is to brute-force compute the sum by using a bignum accumulator that grows by adding additional words as needed. This requires an additional check for wrapping on each operation, once per additional N-bit word. Such bignum implementations already exist and their costs are known.

Alternatively it's possible to ensure within the known context that wrapping can never occur. Noting that only nonlinear operations like square/log/exp are noncommutative while multiplication is; if the sum is minimized by computing the sum of the squares of the height multiplier before computing the product:

(depth 0 == x1, therefore 15 == x16 ?)
Maximum cost multiplier from depth 16: 16^2 == 256 (2^8)
Maximum map size: 4096^2 == 16777216 tiles (2^24)
Maximum multiplicand/sum: 256 x 16777216 = 4294967296 (== 2^32)

This sum can then be used to compute the product via the bignum code (128 bit or otherwise) including the coefficient for Cost x Inflation. This means the overhead of the bignum product would only apply to a single step at the end of the summation stage and the sum itself would fit well within a 64 bit accumulator.

OTTD already uses a Money type which is supposed to be safe against overflow (by saturating at INT64_MAX), but does not check for underflow. That needs to be fixed in src/core/overflowsafe_type.hpp and is not a discussion for this PR.

Right, that was going to be my first suggestion to use saturating arithmetic, but that can't possibly compute the correct sum and it's generally less efficient without hardware support. So I thought, the only way to actually compute the accurate sum+product is to use a multi-step process where the sum and product are handled separately with adequate precision for each.

Regarding the actual cost scaling:

Assuming the surrounding vertices are equal height, at depth:

1. = 1
2. = 3^2 + 1 == 10
3. = 5^2 + 3^2 + 1 == 35
4. = 7^2 + 5^2 + 3^2 + 1 == 84

To get the accurate scaling I can't see any way other than actually iterating through every vertex and summing the difference in height. x^2 seems ... I'm blanking out on the terms here, but what was the rationale for x-squared?

(Blanking out: the difference isn't merely polynomial but rather ... ? Making application of a polynomial "severely underestimate the growth of the cost with increasing magnitude of x." = word I'm looking for.)

Sure took me long enough to bother to remember: Factorial, hyper-(exponentiation, ...), tetration, pentation, ...

I don't think having a fully correct arithmetic for pathological cases that are only possible on gigantic maps with inflation and landscaping costs maxed out is important. As long as it results in the player being refused the action because they would go into negative it's good enough. Even in the extreme case of the player having INT64_MAX cash on hand, and performing an action that should cost more than INT64_MAX, the action succeeding and the playing ending up at zero is also acceptable.

My reason for using quadratic growth on sea clearing cost is that it's easy to implement and does a lot to make filling in the sea unattractive, not that it models anything resembling the real world.

I'd need to look at whether the existing landscaping cost computation uses correct iteration and computation of height differences given the "1 per tile" rule. Computing the accurate cost if it isn't yet implemented may very well "solve" the need for limitations on landscaping by making them bear more realistic cost and scaling. On the other hand, it may also make more than very minor tweaks very cost prohibitive as they become way higher order than a polynomial.

edit to add:
I suppose the volume of a rectangular pyramid is the proper volume. In the square case the area would indeed be quadratic with the product of height in addition to that if I'm not mistaken, shouldn't the accurate maximum value then be height^2*height/3 ? If so my thinking x^^n was wrong since it's only (n*2+1)^2+((n-1)*2+1)^2+... == n^2*n/3, apparently.
Then:

1. = 1/3, 2. = 8/3, 3. = 27/3, 4. = 64/3
   So n^2 would be ... (sub- ... that word I'm looking for?) but only very slightly so and close to accurate.

edit again: (or isn't that then supposed to be n^3/3?)
Still can't recall this one: hypographic (underestimating) vs. epigraphic (overestimating) (?).

This change feels wrong to me, unless it comes with an option to make clearing of water tiles cost the same amount regardless of depth. This would allow marriage of new mechanics, like limiting ability to build depots, with classic gameplay without turning the game into one of those "hard-mode" patchpacks (I don't play on the latter for a reason).

Here's two NewGRFs with deep water sprites, drawn by TT-Forums users wallyweb and Andrew350, and the NFO files adjusted by me.
water-depth-newgrfs.zip

The WaterCycleTest GRF is 8bpp and based on original baseset, uses palette animation. The darkwater GRF is 32bpp and based on OpenGFX, does not have palette animation but covers all 16 depth levels.

Added a NewGRF variable to get the water depth for industry callbacks, although I'm not sure this is the best way to do it. The variable will probably not be any use after the industry's construction since the tiles are now all industry instead of water, so it should perhaps only be available during the location check callback, in which case it could override one of the variable numbers currently occupied by various cargo statuses that are useless during location check.

Rebased so it builds again, and added the preview label. Right now the preview builds won't have any graphics for deep water, so and the fallback of printing a depth number on each tile is only used in debug builds. You can view the depth with the query tool.
I see there's a couple integer sign and width issues to fix.