More height levels (in trunk since r27010)

[ChillCore]

Also, dont forget attach the new limit for height, its possible to "warp" the height level at the noment.
When one raises a flat terrain at 255 height to 256, it "raises" to the 0th height level, resulting a 0th height tiles on the top of the 255 height land.
Then raising again to the 1th level, this generates wierd effects, such as slopes like Locomotion.

Hello thgergo,

Thank you for your kind words and thank you for exploring the limits of this patch.
I have two possible solutions for this problem.

1. In tile_type.h :
Reduce MAX_TILE_HEIGHT_EXTENDED to 255, which will trow the usual warning that terrain becomes to high if you try to raise terrain to level 256.

2. In map_type.h :
In struct TileHeightData{}
Change byte heightlevel to int heightlevel allowing higher levels then 255.

Imho solution 2 is the most future proof.
But I would like to ask ic111 what he thinks is best, before deciding.

I have tested both. For me it does not matter which solution we pick.

ps:
I never played Locomotion.
Would you mind directing me to some screenies to what you mean.(or post some here...)

[thgergo]

The 2. option also not sufficent, becouse one might fill the land to 65536 too, if he enable freeform map edges
Here is some screenies what have you requested. the first is a highland with height level 255, with an extra "256" leveling. The second is the effect raising again, some floating tiles... much like ones in locomotion, but OTTD cant handle this behaviour.

[ChillCore]

While doing the second option the first option limit is still valid, 511 at the moment.

Thank you for those screenies.
Glitches. We had those before.
I will do some testing and post a new patch soon.

[2007Alain2007]

It would be great to see cliffs but i know that openttd would proble mess up

[planetmaker]

It would be great to see cliffs but i know that openttd would proble mess up

That's out of scope of this patch and a completely new topic.

[ic111]

1. In tile_type.h :
Reduce MAX_TILE_HEIGHT_EXTENDED to 255, which will trow the usual warning that terrain becomes to high if you try to raise terrain to level 256.

2. In map_type.h :
In struct TileHeightData{}
Change byte heightlevel to int heightlevel allowing higher levels then 255.

Imho solution 2 is the most future proof.
But I would like to ask ic111 what he thinks is best, before deciding.

Well, a test for overflow should be done in both cases, as actually someone can have the weird idea of generating a landscape at height 65535.

So, concerning the decision wether the limit should be 255 or 65535:

In the first case, one has a limit which in theory is not needed. And, in the first case one may limit heightlevel data in the savegame to one byte per tile (to be honest, I would have to take a look in the code to decide wether we save a one byte or a two byte value here currently).

However, in the second case, one definitely needs 2 bytes per tile. And maybe some bugs concerning things coded as uint8 or similar show up if we switch to 65535. But in general, this should be no big problem, I personally made all variables at least 16 bit.

So, it's the decision between those arguments. And, even if we switch to 255 now, writing another patch removing that limitation lateron would be now big problem, since it basically would involve only altering the heightlevel limit constant, altering the constant defining the format for the savegame and testing for unkown 8 bit values causing problems. So, I can live with both variants

[oklmernok]

I try to create a small but height scenario manually, while I zoomed in and out.. and then the right corner shows some trash.
The trash changes every zoom movement... (the original Openttd never did it)
BN

[ic111]

Ok, I didn't yet fix those glitches, but I got an idea where I will have to search. GetRowAtTile in viewport.cpp, called from ViewportAddLandscape seems to return a too big row for at least fields north of the map. Probably, this is something we missed when we introduced support for freeform edges, I designed those algorithm before freeform edges where supported.

[oklmernok]

When I create a new scenario in the Scenario Editor I can change the Snow Line Height fine (up to 125) by mouse.
But:
If I would like to play directly in the "Play Heightmap"... the snow line height is maximum 13 in the box and the UPPER arrow is "grey" when I reach the 13.
This is the same bug as you wrote in the ToDoList for the "NewGame", but it is in the "Play Heightmap" window too.
the fast solution: change the openttd.cfg: Snow_line_heigh value as you would like to play and don't touch the button in the game!
BN

[ChillCore]

Thank you once more for testing, olkmernok.

If you do accidentally touch the snowline height button.
You can also create a scenario with the desired height.(Even on 64 *64 maps for speed).
Exit the scenario editor after map generation and create a new game or heightmap, without touching the button.
That way you dont have to exit the game ...

Please continue reporting bugs, I read all of your posts but I have been too busy to do some serious work on the patch.
I am testing and updating the logfile and I will be posting a new patch once I have the logfile a bit more up to date.

Changed so far:

Terraforming at borders.
Max tile height 255, to match struct heightlevel and to prevent those glitches with high peaks.

[ic111]

Hello,

I just finished version 17 of the patch. All known problems related to the map border (zooming, glitches, not being able to scroll north enough) should be fixed now.

Notes:
(1) I simply removed the condition which prevented one from scrolling outside the map. It doesn't cause any problems I know about. If one likes, he can implement a more sophisticated solution concerning limits where one may scroll to and where not. (the problem is that if you place a huge mountain at the map border, you need to scroll that far into the otherwise black area, that some fixed limit would need to be far outside the map border if one uses flat land). Using the minimap, you always can find the map again, so there is no danger of getting lost outside the map.

(2) Someone noted the bug that industry is concentrated in low areas, along coasts. To be honest, at least for non-raw-industries, I would call this a feature and not a bug, it's just a rather realistic distribution of industries. I mean, if you consider a mountain of height 100 some 3000m high peak in reality, it's quite realistic that there is no factory on top, isn't it? So, I suggest not touching this in this patch, leaving it for a possible later finetuning patch. For now, in my opinion industry generation works in a reasonable way.

Conclusion: I think, almost all problems outside map generation are fixed. And map generation is also in a state where it works in a reasonable way. So, I think we now should have a look on the remaining bugs and decide wether we fix them in this patch, or leave the issues open for separate finetuning patches. I mean, some patch "I want my mountains look this way and not the other" can be made separatly without any problems.

So, happy testing

[ic111]

Ok, next version.

Only fixed bug: The old height generation algorithm should work now. (up to now, it still had references to the old type_height field - so during generation, it filled a datastructure which isn't read for displaying the landscape...). I fixed this.

Note: I wouldn't say that the landscape this algorithm produces looks good - it rather doesn't. But I suspect that this is also the case in an unpatched game, however, I'm not completely sure.

So, if no one objects, I will consider the old landscape generation algorithm fixed in terms of the more heightlevels patch.

[ic111]

Hello,

just a short notice without extra release: The bug related to high things at position (0,0) being not on giant screenshots is also gone. Fixing it was quite easy, I just needed to play a bit with the offsets in MakeWorldScreenshot in screenshot.cpp.

I only needed to change that file, I have attached it. I (or someone other) will put that adjusted version into the next release.

[ic111]

I just found out why some small maps were water only, and will now fine tune landscape generation.

[ic111]

Version 19, nearly all bugs are fixed

I tuned TerraGenesis for use with the heightlevel patch. Beside many adjustions to the values especially in the frequencies-array, I changed the following things:

(1) _max_height now also depends on the map size. Reason: Make more finetuning possible, and avoid water only maps (a value of 48 on a 64x64 map up to now caused a water only map, since 64/48 = 1, and this fraction then was multiplied with some other fraction < 1 for determining the max. allowed height. So I had to lower this value for small maps.

(2) For very rough and cereally rough maps, I disabled smoothing coasts and the sine transformation also smoothing the map. This way, one can get actually rough maps, with really steep coasts. Actually, the frequency values for rough and very rough are very similar, the main difference is that for very rough maps you don't have that flat areas along the coasts. I know, such maps are hard, but for me, generating a hard map is just the reason for introducing settings like very rough. And yes, I like such maps for playing

(3) If one introduces (2), this will end up in very few industries being generated, just because the generator doesn't find sufficient locations. In detail, it accepted (among several other conditions) a location if it doesn't need to rise/lower any piece of land by more than one heightlevel. For very rough and cereally rough, I introduced new constants, currently set to three heightlevels. For the other settings, I left the bound of one unchanged.

(4) Furthermore, (3) is active only for heightlevels below 20 (also being a constant in industry.h). This way, I want to avoid too much industries being founded somewhere up in the mountains. Maybe this could be extended to some separate switch, giving the decision to the player. For industries founded later in the game, or founded at places where rising/lowering by one heightlevel is sufficient, this limit doesn't apply.

Now, I don't know of any further actual bugs. However, some things might need further improvement:
(a) When the patch is disabled (i.e. max heightlevel 15), generating rough maps 512x512 or bigger is almost impossible. The reason is, that the frequency values don't depend on the max. allowed heightlevel. In other words, the frequency values especially for the rough settings are optimized for much higher maps.

(b) What should we do with the two terrain types CommanderZ and Go for the flows? Currently, in may opinion they don't look really optimal (of course, if someone likes them, I will not object ). My ideas for additional map types include:
(b1) An additional setting optimized for rough maps with low max. allowed height, solving problem (a)
(b2) A setting producing many relatively small islands
(b3) A setting producing a rough map with many fjords.

To summarize, I personally am now content with the generated maps.

And now, happy testing again

[HackaLittleBit]

Found you a bug.

Generate map with following settings

hbg2.png (19.56 KiB) Viewed 2936 times

Very slow generation
then abort

hbg1.png (9.53 KiB) Viewed 2926 times

Or game is in loop or one time got assert
and following msg.
inconsistent to reproduce

regerds

[ic111]

Just a short notice, I don't have enough time for a deeper look right now:

I tried the settings below, and it works for me. (beside of the fact that in terms of game balance there are far too much industries on that map ).

Does the error shown below happen after you get that "do you want to abort"-message, or does this happen independently of the abort-message?

What I see is that generation is fairly slow, which is not surprising since on such a map, only relatively few locations are suitable for industries. So maybe somewhere in the generation is some condition "if map generation runs for more than ... present that message"?

If you like, you can have a look on the code and try to find out where this message comes from.

On what machine do you run OpenTTD?

And, you tried this several times, I personally just once - at what stages of generation does it abort - always during industries generation, or one time during industry generation, the other time during tree generation, and so on...

[ChillCore]

Hi ic111,
Nice to see so many bugs fixed.

I have done some quick testing and found two more bugs.
- With the patch disabled and terraingenerator set to original the game crashes in tile_map.h line 123.
- Aircraft leaving the south-east or north east-border will crash the game in tile_map.h line 53.
Both occasions happen with airport build at the border and aircraft going into their holding pattern.

For comments on the terraingeneration i need to take a better look first.

Changed in the patch:
MAX_TILE_HEIGHT_EXTENDED = 255
MAX_SNOWLINE_HEIGHT_EXTENDED = MAX_TILE_HEIGHT_EXTENDED - 2

Attached the patch, the logfile and win32 binaries updated to r16937.




Edit: binaries removed. Newer are available further in the thread.

[ic111]

Hello,

thanks for the new version.

Just a short notice: I will not be able to do anything with the patch before about August 10th. So, if anyone feels free to have a look on those crashes reported by ChillCore, do so

[oklmernok]

the new patch is great!
R16973M
but: if I use a 1024x1024 pixel heightmap for the PLAY ON HEIGHTMAP function,
and try to use it as little as 128x128 or 64x64 scenario: the program crashed. (there is no crash.dmp file).
It works well (resize it) if I use the heightmap in the Scenario Editor (128x128).
The original openttd warned ("Resizing source map too much is not recommended") and resize it well in the Play On Heightmap too.

holiday-holiday-holiday