(Not a new bug; tested with Pak64; couldn't find a matching topic)
- find a city building that is built onto a natural slope (using a basement)
- delete this building => basement remains (<-actual bug? separate bug?)
- use tool "restore natural slope" on the tile => natural slope is one level too high
This bug was introduced by r2544. By reverting the changes in this case, one can fix this bug:
Index: simwerkz.cc
===================================================================
--- simwerkz.cc (revision 2614)
+++ simwerkz.cc (working copy)
@@ -915,8 +915,9 @@
if(new_slope == RESTORE_SLOPE) {
// prissi: special action: set to natural slope
- new_pos = pos;
- slope_this = welt->calc_natural_slope(pos.get_2d());
+ koord pos2d = pos.get_2d();
+ new_pos = koord3d( pos2d ,welt->min_hgt( pos2d ));
+ slope_this = welt->calc_natural_slope( pos2d );
DBG_MESSAGE("natural_slope","%i",slope_this);
}
else {
[off-topic]
Root problem for restore natural slope is that we can use many layers artificial slope.
For example, if we build a big mountain with raise land tool, and dig with only artificial slope, all tile still remember the mountain height and want to restore it.
I made a test case.
- Load saved game
- Select lower land tool
- Move cursor to (43,30,5)
- Click
This makes strange.
:award: really awesome bug :P no idea how to fix this.
Wouldn't it be more logical to "restore" terrain to closest smooth shape rather than to old configuration? The picture shows rather clearly how wrong it can be.
Just my 2c. I'm not coding :D
Testing with r2645 nightly (pak64 and pak128): the described bug also occurs with self-made artificial slopes and those from curiosity buildings etc..
Furthermore: when I use the artificial slope tools to lower or heighten flat land by one level, it cannot be undone with "restore natural slope". If the underlying level is water, the error message is "No suitable ground!", otherwise no message occurs.
EDIT:
Restoring after replacing a slope - that resides above other slopes - by a higher artificial one is also not possible. The error message is about maximum height difference.
The problems with restoring in case of increased height may be due to impossible selection of the tile with the cursor.
The problem with this bug (and other bug reports for this issue) is that there are two (independent to some degree) ways of handling slopes. One that stores the height of each grid point and is made for the use with for raise / lower tool. Another one that stores the height of the tile and the slope of the tile. This is made for artificial slopes.
Ofcourse there is a lot of logic inside two keep the two height representations consistent. However, large terraforming with artificial slopes leeds to inconsistencies, since the grid heightfield is not updated right.
Imho, I would prefer a solution where the grid-heightfield is removed from the code. This need however m****ive patching.
au contraire, i would suggest storing _only_ the four gridpoints, also for slope tools, the tool altering the position of each single point.
gridpoints, in perspective, could be reused one remote day for 3D terrain :::)
But then you have to store the height of all 4 corners of a tile to allow artificial slopes. Which at the end is the same as storing the height of the tile and the slope ;)
yes, all four. but it would give more flexibility, if one day we'll have double height slopes, as well as half slopes. Also in future we could think of grid+texturing and we shouldn't paint/code all the possible new slopes, but only the changes in the grid
In v102.0, "Restore nature tool" worked for on flat artificial tile and flat artificial hole.
But in current nightly, "Restore nature tool" workes only for 4 slopes.
It means that we don't need to save nature height anymore.
We already know the nature height of slopes.
This should be fixed in revision 2700.
However, the restore-natural-slope does not work perfect. The situation has changed since z9999's post, but this tool is still awaiting a fix or a rewrite.
I think calc_natural_slope should just use the avarage of each of the four adjascent corner to calculate the correct slope.
EDIT: Work in progress: This way could also work; but it gives other problem, when deling many houses. Probably old was better ....
I did not test your patch, but I also thought about this. My idea was to use the median of the three adjacent corners (rather than the mean value).
This make a new bug.
How to reproduce:
1. Build artificial slope on deep sea.
2. Build an attraction on it.
3. Remove the attraction.
Result:
A hole appears onto sea.
Should I make a new bug report topic ?
Is this a consequence of the bug you posted on the previous page? If not then please describe what you have done. Otherwise, the bug is known ;)
This can easily be fixed. However, there are two different places in the code, where the natural slope is restored: the tool itself and in the building remover code. I would prefer to have only one place that take care of this.
Another related question is: what should happen to player's buildings on artificial slopes? Currently, after removing the building also the natural slope is restored.
But, very ugly
natural slope.
Perhaps, please check the attached patch. It seems to work in most situations now.
I like this. In many cases, "restores nature slope" tool works as I expected.
There is one bug, see attachment. The same can happen for the reverse situation: tunnel (slope) in the middle then restore the tile above the tunnel, suddenly the ground is below the tunnel.
Ok, checking for empty ground above/below could be added easily, since it is already there in wkz_set_slope ... Ok, I hope this version geven even more a shape closer to an expected one. Restore will now fail, if at one corner all three edges are of different height, since this can result in some weird slopes.
It works well. However, I like the real median more: if one has a artificial hill it takes a little bit longer until restoring all tiles will not change anything more. With your original implementation the tool sometimes gives up, even if double slopes are nearby, which are highly unnatural.
Here is a updated patch.
Nach länerem Rumprobieren finde ich, d****
return (3*128+2 + a+b+c)/3-128;
am besten funktioniert ....
Ooops wrong language? ;)
I'll translate that (not because you couldn't, but just so you don't have to bother again, prissi)
EN:
After prolonged testing I think that
return (3*128+2 + a+b+c)/3-128;
works best...
Sorry, today I send also Knightly a german pm ... If I switch languages too often, I forget what I was supposed to use.
I guess we were lucky you did not use japanese ;D
Tested in r2733.
This version is very strange again.
Thank you, it looks fine in r2742.
One problem which remained is we can still dig on water.
Thank you: Hausbauer was not realizing that this tile is not water and made it ground with water graphic ...
Thank you problem above was solved in r2748.
But there is a new problem.
When I remove 2 tile building, slope image will remain.