Here is a patch that defines overlapping climates on the same height level. Thus at the same level you can have more than one climate. The climates will start ellipsoidal, but due to overlapping etc. the real appearance is quite patchy, as intended. Thus also climate display was added to the minimap.
What is still missing is the conversion of the climate changes after raining or levelling mountains, which still use the height mapping. But the information is there, so this is relatively easy to fix.
Moreover, having a map file with climates and applying those to newly loaded maps is rather easy to add.
This is a nice idea!
I have already experimented with height map files, in which only the green color channel defines the height, red shows cities and blue shows rivers, lakes and the sea.
Blue
255 = sea
200 = lake
150 = great river
50 = small river.
The climatic region could be coded in the red channel.
red
255 = city
200 = road
0 = desert
30 =tropic
60 =mediterran
90 = temperate
120 = tundra
130 = rocky
150 = arctic
That would be quite useful for pak128german.
That would be great for making real world maps
You could have same climate on the same height since ages. Map generated with this patch can be loaded and displayed in older Simutrans versions as well.
Interesting proof of concept. I can see there being scope for various modules to be part of landscape generation - building on current relatively simple options with this as part of it.
Had to alter it slightly to compile on my linux system with gcc - I did observe one segmentation fault that I wasn't able to repeat.
This would be amazing! Does it mean that one could load a "climate map" in the same way that one can load a height map currently?
Not yet, but that is the idea. Actually one would best load them together.
Submitted in r9148
If this is intended ::-\
(https://makie.de/clima2.png)
Apparently I did not caught all cases of unassigned tiles yet. I will try with your settings.
Missing parentheses here:
gui/map_frame.cc:235:30: warning: & has lower precedence than !=; != will be evaluated first [-Wparentheses]
if( env_t::default_mapmode & minimap_t::MAP_CLIMATES != 0 ) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and also 3 lines below.
Thank you, I had the other way round in memory. But I find it really stupid, that + is above == but & is below. Well, even Ritchie said that this was an unfortunate design decision, so who am I to complain ...
No wonder I've never figured out operator precedence, beyond pluss/minus and multiplication from basic math. And I guess most other programming languages follow C, because it would be even more confusing if the didn't. I'll just stick with trowing parenthesis around everything just to be sure, and let the IDE correct me when I go to far.
Just an idea for further improvement.
Could it be optionally made so that the upper limit for a climate will apply to southern edge of the map, while lower limit to the northern edge (and a gradual lowering across the map? Thus we could get lower snowline (and no desert and tropical) in the north, and higher or none snowline in the south.
Quote from: Vladki on June 20, 2020, 08:20:31 PMust an idea for further improvement.
Could it be optionally made so that the upper limit for a climate will apply to southern edge of the map, while lower limit to the northern edge (and a gradual lowering across the map? Thus we could get lower snowline (and no desert and tropical) in the north, and higher or none snowline in the south.
I had proposed something similar to this several years ago. Maybe it's time has come; although I like the idea of being able to upload a "climate map" even more.
The snowline height is a global variable. Only the arctic climate is something that can be defined locally. And the guys down under will complain about snow in the north ...
Quote from: prissi on June 21, 2020, 11:58:15 AMAnd the guys down under will complain about snow in the north ...
Then we would need a switch like "drive on left" that will swap the behavior to move climates down in south and up in north.
Well, theoretically, there might be something like three options for that: cold-top/warm-bottom, warm-top/cold-bottom, cold-top+bottom/warm-middle. And a fourth option of "none of the above" lol.
To keep both sides of the equator happy an alternative would be to define northern and southern latitude of the map. From that you could calculate which direction the snowline should increase to, and also prevailing wind direction (0-35 degrees north/south = east, 35-65 degrees north/south = west, 65-90 degrees north/south = east). With that a moisture map can be calculated which could be used to simulate various affects on climate (and vegetation).
I think adding climate maps would be a more flexible option, which is now quite easy to do. Only the loading is missing, the rest of functionality is more or less there.
Even a latitude can have very different climates, from tundra to desert and the lot in between ... Also in Germany, the snowy mountains are in the south, despite being hotter there.
Simutrans always claimed to be about ecofreindliness (with those giant airports ... ) but trying to simulate real climate for a map creation is quite a challenge. Because most simutrans maps are not on earth, with the shape of the ladscape.
I used to be a proponent of a mixed latitude and height-based climate system, but I now tend to agree with Prissi that climate maps would be a better approach for Simutrans. Such a system has the potential to be flexible and intuitive, and leaves it up to the map creator as to how simple or complex he/she wants the climate picture to be.
In an effort to emulate a climate-mapping system, I recently built a crude "external" script that used the Simutrans climate painting feature to adjust the standard height-based climates. It is better than nothing, but is very slow (can take 2 hours to paint a large map) and creates harsh non-organic boundaries between climate zones. The ability to upload a climate-map would be far superior.
@Prissi - when you say the snowline is a global variable, are you referring to the winter snowline? Does that mean it's not possible to have the winter snowline vary across the map. I guess I had been hoping that one might be able to map the winter snowline too, so that snow would start at different heights in different parts of the map.
The current snowline is calculated from the difference between winter snowline and the highest level of arctic climates (former summer snowline). Having a winter snowline at different parts of the map is not so quite straight forward. This will probably require a flag for the planquadrat (or even the map) to remember the current season. Because also autumn and spring depend on the snowline difference on high climates (i.e. which saw winter while everywhere else was spring).
Got it. Hadn't thought about that. Essentially, whereas currently there is a single global interpolation between the winter and summer snowlines there would now need to be an interpolation for each tile.
So if climate-mapping is introduced, the encroachment/recession of snowlines would need to remain a global process?
Snowline on a flat ground would cause multi-tile buildings to be partly snowy, partly unsnowy. But they are not designed/cut in a way to support it - you'd generally get straight vertical/horizontal borders between snowy and nonsnowy (you can easily try that out by manually using the arctic climate tool on a multitile building) Same probably for all other seasons if they were to change differently.
I think for that to happen, multi-tile buildings require to have the same season in all parts.