More height levels (in trunk since r27010)

[ChillCore]

From a user's point of view, it's way better explainable that if X and Y spread cannot be changed, Z spread cannot be changed either. Even if that has totally different internal reasons.

I really do not see how it is different from any other server setting eg. the terraform limit or using a base cost grf.

They can simply state: "On in this server we limit the terraforming height to level x" and that is it. Just like "we use no aircraft here" or "there shall be no terraforming at all" and so on ...
Why should I be limited if I play singleplayer? If I make a single pyramid of height 255 on a 512 * 512 map than that is my problem. Completely unplayable, I agree, but who cares ... other than me?

That is just my opinion and I will go by whatever is decided by who gets to choose.
If I do not like it I know how to get around it.

Edit: New page, added quote.

Edit2:
To better reply to your point, Eddi ...
If someone asks why z and not x and y ... x and y are surrounded by void tiles and this can not be changed without starting a new game, period (or they should write a patch just like ic111 has done to get past level 16).

[ic111]

But where is the benefit of this? I don´t see any harm if a player generates a map with max. height 32, e.g. from a heightmap, goes to some piece of land with height 32, uses the "terraforming up" tool, and the piece of land has height 33. IMHO, this is exactly the expected result.

What if someone generates a quite flat map, e.g. from a heightmap using max. height 5. Now he wants a junction-free crossing of two railway lines and thus builds one of them on a rail embankment of height 6. Would forbidding this make any sense?

IMHO, those parameters to both random map generation and map generation from a heightmap are / should be just tools to get some particular expected results (a map with a certain shape, with certain properties) - not hard limits for the whole game.

[planetmaker]

But where is the benefit of this? I don´t see any harm if a player generates a map with max. height 32, e.g. from a heightmap, goes to some piece of land with height 32, uses the "terraforming up" tool, and the piece of land has height 33. IMHO, this is exactly the expected result.

The benefit is the automatic scaling of the snowline - which scales the snowline height from the "percent" given (0..255) to the actual max height of the map. This has the advantage that existing NewGRFs which define a snowline remain operational and don't break. At the same time writing snow line NewGRFs is then MUCH easier as you only define the percentage of height levels which will become snowy - a way which will work for every height range.defined for a map.

[ic111]

Ok, but then scaling the snowline should do its job, shouldn´t it? I.e. determining the height of the highest peak at new game startup, storing that information, and setting the snowline to <snowline fraction> * height of the highest peak, where snowline fraction can be defined by the grf.

And if the height of the highest peak changes afterwards, not changing the snowline (at least not immediately) would be no harm IMHO.

A bit of extra logic maybe would be required anyway: Setting a snowline of 2 because you have generated a very flat map is not what you would want IMHO.

[planetmaker]

Yes. But for that reason the max heightlevel might be a good setting to be set in the NewGame window - to a choice like 16, 32, 64, 128 or so. Then it's clear to the player where s/he can expect snow. Just picking the highest mountain peak might be a bit... undeterministically

[ic111]

Well, if you define 50 percent snow, then you will expect a landscape with no snow at low heights, and snow at high heights. And this you will get. If you say 90 percent snow line height, then you will expect hardly any snow - you will get it either.

One can describe in the tooltip for the snow-height variable what actually happens.

[planetmaker]

Well, if you define 50 percent snow, then you will expect a landscape with no snow at low heights, and snow at high heights. And this you will get. If you say 90 percent snow line height, then you will expect hardly any snow - you will get it either.

One can describe in the tooltip for the snow-height variable what actually happens.

And if I say 50% of the height levels snow I know exactly where to expect snow when I set a max height of the map to 64

The definition is already done: http://newgrf-specs.tt-wiki.net/wiki/Ac ... e_.2810.29

[ic111]

Ok if you *really* insist on it, then I have to implement this also.

I would not regard it necessary.

What about the scenario editor? Do you also want to forbid someone forming higher mountains after generating a world with max. height 32?

(and I have thought I could start with other things now...)

[planetmaker]

Ok if you *really* insist on it, then I have to implement this also.

I would not regard it necessary.

What about the scenario editor? Do you also want to forbid someone forming higher mountains after generating a world with max. height 32?

(and I have thought I could start with other things now...)

Forbidding terraforming to heights higher than the current MAX_HEIGHT should not make any difference - except that it's not a define but a (global)? variable. I'd have assumed you have the code to limit stuff to MAX_HEIGHT anyway (does it need changing at all?) The only thing I assume is "missing", that is a max height selector in the game generation window(s).

[Eddi]

(and I have thought I could start with other things now...)

come on... 90% of the work is done... now you only need to finish the other 90%

[ic111]

Well, now I have to tune the map generation algorithm to never generate a map higher than the given maximum height level.

I know how much time it took to fine-tune its parameters in a way that gives senseful results with more heightlevels.

[Alberth]

Ok if you *really* insist on it, then I have to implement this also.

I would not regard it necessary.

You could use this to cheat.
Say I hate the 50%, it is too low for that farm/city/whatever.

So I terraform one big peak, et voila, the snowline nicely shifts up, out of the way.

[ic111]

Ok if you *really* insist on it, then I have to implement this also.

I would not regard it necessary.

What about the scenario editor? Do you also want to forbid someone forming higher mountains after generating a world with max. height 32?

(and I have thought I could start with other things now...)

Forbidding terraforming to heights higher than the current MAX_HEIGHT should not make any difference - except that it's not a define but a (global)? variable. I'd have assumed you have the code to limit stuff to MAX_HEIGHT anyway (does it need changing at all?) The only thing I assume is "missing", that is a max height selector in the game generation window(s).

Ok, what needs to be done?

- Defining a variable max_heigth in the advanced settings
===> Reason: I don´t want to restrict a game forever in this sense, IMHO there needs to be some way to change it afterwards. Furthermore, by doing so I don´t have to think about the question what happens if someone changes landscape in scenario editor (no, I don´t want to forbid people loading a max_height = 32 map in scenario editor and building a high mountain on it).
- Include it in the map generation settings
- Adjust the Terrragenesis map generator to never generate too high maps while generating senseful maps with not just a huge plateau on top
===> I will have to look how this can be done, perhaps it´s trivial, perhaps it costs several days to do so
- Make sure that the variable is ignored in the old map generator
- Make sure that the variable is used in heightmap generation
===> I.e. replace the newly introduced max_height for heightmap variable by the one I will now introduce
- Introduce terraforming condition
===> Easy
- Replace MAX_HEIGHTLEVEL in snowline code
===> Easy

Corrections to the list welcome.

If TerraGenesis can be adjusted easily, its a job for the next one or two days (in fact, I wanted to start today in the evening with working on a timetable patch, making them much better managable).

If TerraGenesis becomes a major problem, it´s a job for a week or so.

And concerning your 90-percent-rule: For me, there is a big difference between
(a) bugs, problems, etc. that obviously have to be fixed (we had a lot of them in the last months), and
(b) change requests referring to how it works

Here we have an instance of the latter, *you* want to have a proportional snowline instead of a fixed one as already implemented, have decided this at some place I do not or cannot read/discuss, and expect me to adjust the patch to the corresponding specification.

[Alberth]

Here we have an instance of the latter, *you* want to have a proportional snowline instead of a fixed one as already implemented, have decided this at some place I do not or cannot read/discuss, and expect me to adjust the patch to the corresponding specification.

I know the feeling, I have had the pleasure of Rubidium requiring fundamental changes to some patches before I became a developer.
It really ruins your day (at least it did for me).

After doing it as requested however, I has to conclude that he had been right all along. The patch was a lot better afterwards.

Your situation is the same I think. By making a proportional snowline, 'snowy' newgrfs will continue to work when the absolute height changes.
In other words, such a newgrf will work with all heights, rather than just one.

[ic111]

Here we have an instance of the latter, *you* want to have a proportional snowline instead of a fixed one as already implemented, have decided this at some place I do not or cannot read/discuss, and expect me to adjust the patch to the corresponding specification.

I know the feeling, I have had the pleasure of Rubidium requiring fundamental changes to some patches before I became a developer.
It really ruins your day (at least it did for me).

To be honest: I hope it doesn´t ruin a week :-/

(all changes except to Terragenesis are more or less straightforward, but I had hoped I will not have to tune Terragenesis again, while not fully understanding its algorithmic details)

[bokkie]

It seems that many patches only go into trunk after serious changes requested by devs. If they don't have many comments, either they are not interested or the patch is so far away from trunk quality that they don't bother commenting. It's very understandable that you just want to be done with it, but the hard way often seems to be the only way.

Of course, many thanks for you and all devs for your efforts from the people playing OpenTTD

[planetmaker]

Here we have an instance of the latter, *you* want to have a proportional snowline instead of a fixed one as already implemented, have decided this at some place I do not or cannot read/discuss, and expect me to adjust the patch to the corresponding specification.

You've no idea how often we do that with our own patches when we review it among us. Our life is not easier in this respect - the feedback just does not run through this forum (and if this off-the-scene review is only in order to avoid rising high expectations of a feature which might not yet be ready or not even feasible in the way presented initially).

So what Alberth said above is also still true to some extend for those who are an "official" dev. It sometimes helps to discuss things in advance - but not even that is a guarantee. It's much easier to review an implementation with its implications when it's actually there. Yes, these change requests can spoil the day. But there's always another day And this keeps the code base in a good and extensible and yet still well backward compatible way. Which is to the benefit of all who play the game.

[HackaLittleBit]

- Adjust the Terrragenesis map generator to never generate too high maps while generating senseful maps with not just a huge plateau on top

What about using the Terrragenesis map generator 'always' for 256 height.
After creating that map you right shift » the whole map according to the height option (16, 32, 64, 128, 256 )
maybe that would do the trick?

ic111 keep on truckin there are more people than you think that really would like to see you succeed.

Regards and thanks

[ic111]

- Adjust the Terrragenesis map generator to never generate too high maps while generating senseful maps with not just a huge plateau on top

What about using the Terrragenesis map generator 'always' for 256 height.
After creating that map you right shift » the whole map according to the height option (16, 32, 64, 128, 256 )
maybe that would do the trick?

Scaling would alter the steepness of the map significantly. A map that is steep for 256 heightlevels is totally flat on 16 heightlevels (division by 16!).

For illustration: This currently controls heightlevel depending on the map size in the patch. I.e. it is basically a map from map size and map kind (Flat, ..., Alpinist) to max. heightlevel. Now, if someone chooses max. heightlevel 16 and e.g. Mountainious, he will expect a quite rough map, but with mountains of height <= 16. So, I will have to find a way of constructing appropriate sine wave parameters for all combinations of map size, heightlevel and map kind.

Code: Select all

/**
 * Desired maximum height - indexed by _settings_game.difficulty.terrain_type and the map size.
 *
 * Sense of indexing by mapsize too:
 * Below, h_max_new is calculated as min(map_size_x, map_size_y) / the constant defined here.
 * Later, for calculating the height of some individual tile, the formula:
 *  h_max_new * (h - h_waterlevel) / (h_max - h_waterlevel), where h_max is the maximal heightlevel
 * existing anywhere on the map at the time of that computation step.
 * So, to summarize:
 * For mapsize 64x64, the above division gives 1. And, h - h_waterlevel is always
 * smaller than h_max - h_waterlevel. So, the result is a map consisting just of water 
 * - i.e. at heightlevel 0 :-/.
 * My conclusion was: 
 * Indexing this setting by the mapsize is a good thing, as one gains much more
 * control on the heightlevel distribution of maps now and small maps work at all. 
 * The n-th value of the second component is for log(min(map_size_x, map_size_y)) - 6, so
 * index 0 is for map size 64, whereas index 8 is for map size 8192.
 */
static const int _max_height[7][9] = {   
	{32, 48, 72, 170, 340, 680, 1360, 2720, 5440}, ///< Extremely flat
	{21, 40, 50,  64, 128, 380,  760, 1520, 3040}, ///< Very flat
	{16, 27, 38,  51, 102, 204,  408,  916, 1832}, ///< Flat
	{12, 21, 30,  39,  60, 120,  240,  480,  960}, ///< Bumpy
	{10, 13, 17,  20,  33,  66,  132,  264,  528}, ///< Hilly
	{9,  10, 11,  12,  13,  24,   48,   96,  192}, ///< Mountainous
	{5,   6,  7,   7,   7,  12,   24,   48,   96}  ///< Alpinist
};

[ic111]

A somewhat intermediate version, as I can´t do anything for this patch before Sunday evening anyway.

Changes: The new parameter max_heightlevel. Can be controlled from (1) advanced settings, (2) map generation dialog, (3) heightmap generation dialog. When changed in (1), there is a consistency check for too high heightlevels on map when decreasing the parameter. (1) also assures that one can do anything with a map when loading it in scenario editor. If one fears cheating (I personally do not), one might add a line to the cheating dialog, marking the fact that this parameter was changed.

Regarding heightmaps, I simply exchanged the max. generated heightlevel parameter by the new max. allowed heightlevel parameter. I first thought about including both, but I think that would be overcomplicate, and one can get any combination of max. generated heightlevel / max. allowed heightlevel (where of course the latter is higher than the former) by simply first generating the map for some particular value, and later adjusting the parameter in the advanced settings. This will e.g. be necessary if you initialize a scenario from a heightmap in scenario editor, and want to alter it before playing, introducing higher mountains.

In tgp, I only adjusted scaling so that no too high maps can be generated. The drawback of this is that the generated maps for some of the settings simply don´t have the expected characteristics. Example for what I mean here:

Generate a 1024x1024 map, landscape type Alpinist, max. allowed heightlevel 30. You can with no doubt generate quite mountainious maps using 30 heightlevels. However, in this case, the algorithm will generate something that can at most be called hilly - simply because all mountains are scaled by some factor compared to the originally intended height of an Alpinist map on a 1024x1024 map.

So, I think the question is how could we change this, and how important is changing this? On the one hand, by setting the max. allowed heightlevel high enough, you can get senseful results for any combination of map size and landscape type, on the other hand by setting it too low you can get unexpected results.

As I will not even have internet access before Sunday evening, feel free to think about this, or even implementing improvements to tgp regarding this. If you do so, please post a forum notice in this thread before Sunday 5 pm. GMT.

EDIT: Forgot a qrefresh and some qpush, use mhl_v19_2.