JGR: Could you post the compiler output of the warnings you refer to? It should contain the gcc flags that triggers them.
The only difference between our settings was that you additionally had -DFORTIFY_SOURCE=2, but adding this on my side didn´t change anything. Maybe Debian has another notion of Wall?
I found another artefact:
- this pit appear just before and of map creation.
You mean that tile going downwards without any continuation, three tiles to the northeast from the position of the selected tile?
Yes, this happens sometimes, and I don´t regard it exactly nice either. It happens, because some part of my algorithm decided "this tile should become river", in this case probably the wider river generation, and because none of my algorithms detect the problem so far.
I still have a feeling, that "Fine tune terrain to make slopes valid against rivers, while keeping them connected" is very volatile - too much cases.
The most important part of it uses the strategies defined near the end of river_rainfall.cpp, e.g.
The strategy which fixes most tiles is taken.
Therefore, maybe erosion model of valleys carving is better solution than all these fine terrain adjustments?
The problem with only lowering tiles is that it can alter landscape significantly. For example, in my test heightmap, I prepared a lake of height 4, and about 20 tiles away a lake of height 8, Through both, a big river flows. Before I implemented the above strategy, the algorithm usually lowered the former lake to height 1 or 2, and the latter to height e.g. 4. Additionally, it often left a stair in the middle of the lake. Only with those strategies, and some additional cases, I succeeded to generate a terrain that (a) keeps the height of the lakes, and (b) is friendly to the river in that it only removes a few tiles from it that cannot be terraformed to a correct slope (e.g. because a series of NW slopes meets a series of NE slopes in a ENW corner).
And here, I regard correct landscape in the large scale as more important than avoiding the last flaw in small scale. I.e., when I prepare such a heightmap in scenario editor, then I simply expect that the lake is at the height I want it to have, and not 4 tiles lower.
At least, my experience of the last weeks teached me that changing less tiles is the better strategy.
In terms of source code, those different strategies are implemented in a way that makes them easily exchangable. E.g.
this->FixByLocalTerraforming(problem_tiles, water_flow, water_info, define_lakes_iterator); // slope_to_schemes
this->FixByMovingProblemTiles(problem_tiles, water_flow, water_info, define_lakes_iterator);
this->DeriveRivers(river_map, river_iteration, id_to_river, water_flow, water_info);
this->ConnectRivers(river_map, river_iteration, id_to_river);
this->FixUpwardsRivers(river_map, river_iteration, id_to_river, water_flow, water_info);
this->TryLinkRiversWithOcean(river_map, river_iteration, id_to_river, water_flow, water_info);
so, one can throw away them and implement something different without needing to refactor the remaining code. I mean, if someone can implement something better for some of those aspects, this is not forbidden. Just I tend to regard this as a (in terms of correctness of the algorithms) 99% finished project that in some details can be fine tuned to improve it further, and not as a project where I want to exchange fundamental parts of my algorithms or strategies. In a project of this size, IMHO you at some point in time need to live with the infrastructure you have.
I.e. it took me two or three weeks of frequent OpenTTD coding (in October, we had pretty wet weather which was good for OpenTTD, this changed towards November
) for coming from the situation where it all the time damaged my lakes, to the current situation. And speaking from my experience, I doubt that what you call carving would be done significantly quicker. And I doubt that it would really help at all, after all at some point, rivers need to make the height difference, and if that point (on a heightmap) is diagonal, you somehow need to deal with the situation.
To summarize, we have:
- Rivers flowing upwards: I (not yet released) connect logical rivers now. On this basis, maybe one could improve that. (Un)fortunately, I just wasn´t able to find a single testcase for the problem on a 1024x1024 map, so in my experience, it seems to be rather seldom. So I currently tend to leave this at least for now.
- What you show as in the screenshot above
- Rivers, where the fine tuning step leaves a situation where the river more or less flows on a dam for a short distance.