More height levels (in trunk since r27010)

[ic111]

And now MHL. I see the same happening, people claiming it is great and such, while to me, huh? We already had hills, right?

Just a small note: The maps I see here don´t exactly look like the ones for which I use MHL. I use MHL for simulating real-world mountainious areas. E.g., a game I played some time ago had about the extent Munich in the north, Milano in the south, Zurich in the west, Salzburg in the east.

Using MHL, it was possible to get the valleys in that region in great detail. E.g. you have a huge valley which in reality is at about 600m, you have a somewhat higher plateau near the valley at about 900m, you have a pass connecting the northern and the southern part of that area at about 1400m. In reality, all three points I refer to here have railway tracks, from 600m to 1400m the railway needs something between 30 and 40km. Near that locations, mountains of height > 3000m are situated.

Modeling something like this with just 15 heightlevels would have looked like, I start at heightlevel 4, the pass has maybe heightlevel 8, i.e. some small bridge near your station would already have a height difference in the order of 25% of the 800m between 600m to 1400m.

Sometimes, in mountainious areas railway tracks use side valleys to gain height, i.e. they head for some kilometers into some actually quite uninteresting (in terms of traffic) valley, make a 180 degree turn, go back at some slope, and come back to the main valley, but now maybe 100 or 200m higher - because the direct way was too steep for a railway.

Model such a situation with 15 heightlevels - it would consume a major part of the heightlevels you have.

I agree perfectly with your point that one cannot sensefully fill maps of 2048x2048 or even 4096x4096, yet I think heightlevel 15 is rather something like the old 256x256 map.

[oberhümer]

If you want to go for that kind of "inter city" style that's not all cramped between towns you'll need lots of free tiles in the beginning. If you on top want more than just a few towns, you'll need big maps.

And if you want stop distance scaled the same as vehicle size, even 4096 tiles only give you two to three high-speed line stops. * Granted, that might be a bit excessively realistic, but it nicely demonstrates how crowded OpenTTD maps often are.
With that in mind, it's definitely true that the "large empty map" style can be problematic. What would help a good deal is a density setting below Very Low for towns and industries ("minimal" doesn't really count), and/or more town/industry clustering; I think the rest is already NewGRF-adjustable.

*Assuming 1 px = 0.75 m diagonally (approx. scale of unshortened diagonal vehicles): 4096*32*0.75 = 98304 m. Assuming 1 px = 1 m (approx. scale of TTD-shortened diagonal vehicles): 4096*32 = 131072 m.

(edit: might be more appropriate in the map size thread)

And this:

That's what I said above in the quote, except in my usual very brief and direct techie style of writing.

While it may look angry or unwelcome to you, it's not intended as such. [...]
So I understand you got confused about my brief style of writing

could easily be (mis)read as "I know this post might confuse/annoy people, but I don't really care enough to rephrase it."

[Supercheese]

Recently we got a map increase from hideously useless 2048 to insanely useless 4096.

After 7 years being here I still have to find the first map of 2048x2048 (ie 1/4 of todays max map size), where someone manages to actually use that space instead of all empty and a small network in some tiny corner that would have easily fitted in 512x512.
The closest ones I have seen are the openttdcoop ones that manage to fill 1024x1024 in MP.

Yet after introducing 4096 as new max size, you see people jumping of joy, and actually using it. With 16 companies, each company can fill 1024x1024 without ever running into a neighbour (ie you need the cooperative power of openttdcoop to fill the space of one company!!, you need 16 coop groups for the entire map!!!). For MP, both cooperative and competitive, how is that useful???

What's worse, even in SP it is used. Why on earth does someone do that??

Well, not that I've ever done this, but a distinct advantage of an enormously large map that can be exploited the instant the game starts (in a late enough date anyway) is to build an airport by a large city on one side of the map and a second airport at another large city as far away as possible from the first city. Then, airline routes between these two cities should be insanely profitable due to the extreme distance. This tactic works in all map sizes, of course, but should scale up to more and more profit as the map size increases.

Not the best argument for an enormous map, I know, but it is a use case.

[Kogut]

It seems to me that r27008 was the missing piece of the puzzle to finish (*) MHL.

Congratulations ic111 and thank you everyone else for the continued support and feedback over the past years.

Is it hard for people involved in mhl to produce version that would allow tuning of relevant parameters without compilation and later recompilation (via config file or GUI)? I would happily test it (on Win7 or Lubuntu 14.04), maybe also somebody else.

I am working on my custom smoothness settings patch, It has a gui to mess about with the parameters without the need for re-compilation.
I could post what I have so far if you're interested in messing about and helping me improve usability.
Note that this may be a crude experience still as there are options missing, you will have 2 guis open at times. Also I noticed that with some combinations of noise parameters the mapgeneration tends to freeze for a bit and I do not want to fry everyone's CPUs ...

I am interested.

[Kogut]

Edit: Yep, as you can read I am apparently failing to understand some fundamental thing here. The problem is I have no clue what that thing is, and I'd like to know.

Without MHL player needs to control himself - otherwise the biggest mountains will be flattened just to slightly enlarge train station. I did things like this by accident. Now it is possible to have large-scale landscsape.

You claimed you can now build a zig-zag up

It is more about that there may be now reasons to builds zig-zags other than "I want to have realistic trac layout". Before MHL at certain point of game the most effective way of building in mountainous areas was to raze mountains (cost multipliers just postpone this moment, adding undestructible objects protects just small areas).

We already had hills, right?

Now we can have mountains.

Also, I remember when I long, long time ago discovered OpenTTD and I was disappointed that my plan for building huge mountain from all my earned money needs to be downscaled as the highest what I can make is a hill. Maybe it is only my family, but my sister did the same thing (without any encouraging, I just explained how to build bus routes - and she was soon later trying to build mountain and was asking why it is refusing to get bigger).

[romazoon]

Citer:
We already had hills, right?

Now we can have mountains.

oh my gawd. 2X5 words and it s saying it all about MHL !

[Alberth]

Thank you guys, you've been giving me quite a few useful answers to ponder about!

[Espee]

What's so good about increased map sizes or height levels? It allows me more freedom to decide what kind of game I want to play, and how I want to play it. Anything that gives me more choice is a huge gain, in my opinion. Whether I use it all or don't use it all, whether I use it "right" or waste it.

My preferences are that I like large maps (2048 or 4896), I like lots of height levels so that I can create wide, interesting and complex landscapes. I typically watch scenery more than I try to fill every square on a map.

Hear, hear! My impression is that due to the fact that most OTTD players/developers are from places where the terrain ranges from somewhat hilly (UK) to "plat als een pannenkoek" (NL), there is not the same appreciation for multiple height levels as those of us who live (or prefer to play scenarios) in central Europe, North America or Japan. Although the vast efforts to develop NewGRF sets are quite commendable and have made quantum contributions to make OTTD far more enjoyable, the interest in creating more interesting/challenging terrain seems to be found in only a small minority (kamnet, SwissFan91, el koeno, pyoro, bad hair day). I would look forward to playing in multiplayer games with scenarios or heightmaps that required some real routing challenges instead of looking like I'm laying snap-track across a billiard table...

[Espee]

.... More Heightlevels are in trunk since r27010.

Pardon my ignorance here, but am I correct in assuming that since this is well past the 1.4x release branch, we will finally see this in the 1.5x series of stable releases?

[Sylf]

.... More Heightlevels are in trunk since r27010.

Pardon my ignorance here, but am I correct in assuming that since this is well past the 1.4x release branch, we will finally see this in the 1.5x series of stable releases?

That is correct. 1.4.x was branched from trunk in December of 2013. A new feature such as this will be included in the next major release. Assuming the release cycle will hold the same pattern as the past, 1.5 beta test should begin in about 2 months, with a goal of 1.5.0 release in April of 2015.

[Espee]

.... More Heightlevels are in trunk since r27010.

Pardon my ignorance here, but am I correct in assuming that since this is well past the 1.4x release branch, we will finally see this in the 1.5x series of stable releases?

That is correct. 1.4.x was branched from trunk in December of 2013. A new feature such as this will be included in the next major release. Assuming the release cycle will hold the same pattern as the past, 1.5 beta test should begin in about 2 months, with a goal of 1.5.0 release in April of 2015.

Wow, that was a quick reply! Talk about great customer service... Just a dumb question: how will this be implemented? The current 0-15 height range appears to be determined by dividing the (average) heightmap pixel brightness (8-bit value) by 16 and rounding down to the nearest integer value. Will be be able to change that dividing value of 16 to other values (8,4,2) and get 32, 64, 128 height levels respectively?

[Sylf]

Wow, that was a quick reply! Talk about great customer service...

I'm not playing a customer support - I'm just another player who happen to know the answer to that particular question, and I just happened to read your post at the right time!

how will this be implemented? The current 0-15 height range appears to be determined by dividing the (average) heightmap pixel brightness (8-bit value) by 16 and rounding down to the nearest integer value. Will be be able to change that dividing value of 16 to other values (8,4,2) and get 32, 64, 128 height levels respectively?

When you're loading the heightmap, the World Generation window asks you what you want as the maximum map height to be. You can select any number between 15 and 255. Then the map generator will scale the terrain from sea level to the max height you specified.

[Baldy's Boss]

Wow, that was a quick reply! Talk about great customer service...

I'm not playing a customer support - I'm just another player who happen to know the answer to that particular question, and I just happened to read your post at the right time!

how will this be implemented? The current 0-15 height range appears to be determined by dividing the (average) heightmap pixel brightness (8-bit value) by 16 and rounding down to the nearest integer value. Will be be able to change that dividing value of 16 to other values (8,4,2) and get 32, 64, 128 height levels respectively?

When you're loading the heightmap, the World Generation window asks you what you want as the maximum map height to be. You can select any number between 15 and 255. Then the map generator will scale the terrain from sea level to the max height you specified.

So all the new possibilities are "on top" of the existing available heights,rather than making existing slopes more fine-grained?
Right now map generation options include Very Flat,Flat,Hilly,and Mountainous.Are these going to be redefined as at similar proportional levels along an expanded range,or are we now going to get the same options with the same values with the additional options of Quite Mountainous,Very Mountainous,Extremely Mountainous,Absurdly Mountainous,Insanely Mountainous,and Inconceivably Mountainous all tacked onto the high end?

[kamnet]

• Terrain type
• Very Flat
• Flat
• Hilly
• Mountainous
• Alpinist

• Smoothness
• Very Smooth
• Smooth
• Rough
• Very Rough

[Sylf]

You guys should download a copy of nightly and play around with it - you'll get your answers much faster than asking questions here.

With more height levels, your map can look like this. Are we in the Himalayas yet?

[oberhümer]

Is that really a good example? it looks barely playable. On the other hand, it shouldn't be viable to build tracks straight over the Himalayas either...

[Tafidis]

Last weekend I downloaded nightly after more than 2 years just to see this on my machine! Wonderful job!

I played a map with mountains at height 60, minimal industries, took me a LONG time to connect two industries.

I have some questions re map generation (to anyone that knows)

• Is the maximum height of a map somehow a function of the other dimensions? E.g. can I have height 100 on a 256x256 map? Is the maximum height I insert in the box guaranteed to exist somewhere on the map (highest peak)?
• I don't understand what the "variety distribution" does (or if it is doing what it is supposed to do). I like mountainous maps, but I would like some variety, too. When I set it to "None" the whole map is just mountains, so it's really hard to connect anything to anything. When I use any of the other options, I invariably get only one or two low mountains (less than half the maximum height I selected) and the rest 80% of the map is just flat. How can I get a good balance with mountain ranges and some flat areas around them?

[Pingaware]

Is that really a good example? it looks barely playable. On the other hand, it shouldn't be viable to build tracks straight over the Himalayas either...

To me, it looks like exactly what I'd want from MHL - true mountains that you have to skirt with very busy valleys to serve.

[Eddi]

Is the maximum height of a map somehow a function of the other dimensions?

yes

E.g. can I have height 100 on a 256x256 map? Is the maximum height I insert in the box guaranteed to exist somewhere on the map (highest peak)?

no, although you can then manually adjust heights up in the scenario editor or game.

I don't understand what the "variety distribution" does (or if it is doing what it is supposed to do). I like mountainous maps, but I would like some variety, too. When I set it to "None" the whole map is just mountains, so it's really hard to connect anything to anything. When I use any of the other options, I invariably get only one or two low mountains (less than half the maximum height I selected) and the rest 80% of the map is just flat. How can I get a good balance with mountain ranges and some flat areas around them?

variety distribution is supposed to give a map with mountaneous bits and flat bits, but it's not optimal. may need a few tries until you find a map that fits your expectations.

[Sylf]

Is that really a good example? it looks barely playable.

It may be a good example to some, it may only scare some people away. I personally have no desire to play in such landscape. But it shows what "more height levels" look like in the game when someone had an impression like

rather than making existing slopes more fine-grained