News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Minimap doesn't display terrain above a certain altitude

Started by AP, January 06, 2013, 04:50:43 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

AP

I was just trying to generate a decent mountain map to play, and discovered that simutrans minimap, which shows terrain contours very clearly for flat and hilly maps (shades of green) - can't show terrain contours above a certain height. The below map is clearly not helpful in planning routes through the mountains...



I believe this is the case generally, not restricted to the pakset I was playing (pak-gb-ex) as i've noticed it before, usually just on odd mountaintop regions however.


kierongreen

I don't think you'd be able to generate maps like this in standard?

AP

Really? All i did was set sea level to the lowest (-10) - hence large mountains.

Sarlock

I've had the same occur.  It happens on that Vancouver map I released a few weeks ago.  When you set the water level to -9, the top countours all come out at the same colour.
Current projects: Pak128 Trees, blender graphics

Fabio

If color gradients number is limited, I would fix this associating lowest color to one level above sea and highest color to highest peak and calculating how many levels to step up to next color dynamically.

Dwachs

We could more colors, but the colors are restricted to a certain palette. I do not know whether this
http://www.simutrans-germany.com/wiki/wiki/de_FactoryDef#mapcolor
is up-to-date.

In the code, these color numbers are used:

160, 161, 162, 163, 164, 165, 166, 167, 205, 206, 207, 173, 175, 214

There is an out-of-bounds access for the highest levels, which yields most of the time this purple color

106


If anyone could come up with a suitable suggestion, it will be realized very quickly.
Parsley, sage, rosemary, and maggikraut.

Sarlock

Is the map restricted to using the 224 colour palette?  If so, that doesn't leave much for options as the rest of the colours are likely already used for other map items and would make them not visible on the map.  If colours can be added (0 to 255, I assume?) then new greens with hues in between the other greens can be inserted to add the 6 additional height steps.
My suggestion would be to insert the grey range in between 175 and 214.  We would need to add 6 colours (needs 20 colours total for a -10 height map):
175, 208, 209, 210, 211, 212, 213, 214

This will likely conflict with map items in paksets that are set to use the grey colours though.
Current projects: Pak128 Trees, blender graphics

VS

Not the global palette again :-/

Solution? Use separate table for minimap terrain.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

AP

Could it be drawn such that the sloping tiles display in a colour, say brown, and the flat tiles white. This would essentially yield a contour map, in the same fashion as a UK Ordnance Survey map.



Or, perhaps a less ideal solution, if a fixed colour palette can't be avoided, would be for it to work up through the colour scale, then back down again, then back up again, etc. This would at least allow all terrain to be depicted (although if colouring, unique colour shades are clearer).

prissi

Maximum elevation differences of more than 14 may result in tile/objects not drawn at all. Thus the minimap was not extended to handle this.

IgorEliezer

Neh! We don't need to be so accurate to this extreme. Say, we have only 8 colors available, but whole map has 24 height levels, ranging from z=0 to z=+23. We don't need a color per level. We could allocate 3 levels per color:

color 1 = +0 - +2m
color 2 = +3 - +5m
color 3 = +6 - +8m
...
color 7 = +18 - +20m
color 8 = +21 - +23m

We also could consider that the player can zoom in and out the minimap if he or she wants to see a rough or sharp detailed map. Simutrans could check how many height levels exist at a certain zoom (or minimap view) and allocate an integer number of levels per color (number_of_levels_in_the_view / 8 = levels_per_color).  With a 1:1 zoom, there would be 24 levels in the map view, then 3 levels per color; with 4:1, 16, then 2 levels per color in the legend. If zooming in even more, 8:1, there would be 8 levels, then 1 level per color.

If we keep things this way (don't need to display everything at once) we would have more room for a multi-themed mini map, why not? It's possible to represent the same region in various maps. Each theme has its own map instead of all themes in only one map. I faced the same problem with limitation of colors when I worked for a cityhall in 2004 (in Portuguese, sorry):
- Elevation map (1 color = 100m)
- Declivity map (1 color =  percentage range)
- Hydrography map (rivers and lakes)
- Land use (1 color = a use: industrial, residential, rural etc)
- Transportation and road/rail system
... whole work is here, if you want to poke around.

prissi

Actually, nowadays climate would be as much needed as heights ...

You idea is nice, but it would require two passes over the landscape => opening the minimap with delay further.

Dwachs

Here is some proposal. Patch and screenshot attached. Now with 31 different height level colors.

Does anybody have a developed save with extreme height-level differences? Then one can test whether everything is still visible...
Parsley, sage, rosemary, and maggikraut.

Fabio



prissi


Sarlock

Current projects: Pak128 Trees, blender graphics

kierongreen


VS

I like this! The very high altitudes are mostly useless for anything, so there is little point in having the colours distinguishable. If that need comes, they can be always changed to something softer.

On the other hand, a situation with lowland and plateau somewhere up could be interesting... RT2 had Tanzania and South America that way, I think.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

AP

Quote from: VS on January 10, 2013, 05:54:18 PMThe very high altitudes are mostly useless for anything

I disagree - if you have a continuous mountain range, it's much cheaper to engineer an incline plane at each side and a railway across at high altitude than it is to build a route that goes around it or crosses it at low level.

I'd love an extension which allowed raw-material-industries to only appear in the highest 25% of terrain on the map - make the mountains devoid of settlement but rich in resources.

greenling

Dwachs
the Photo from your patch looks very good out.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

IgorEliezer

Quote from: Dwachs on January 09, 2013, 08:10:09 PM
Here is some proposal. Patch and screenshot attached. Now with 31 different height level colors.
It. Is. Just. Awesome. :0

But I think the colors are a bit....umm... intense, eh? I'm afraid that it would be hard for the player to distinguish the other layers over it. Have you tried to use this map with other elements, such as cities and factories?

I don't know if there's an international or widely-accepted standard of how elevations are shown in cartography. That's one we use:



The highest levels are shown with light pinks instead of dark maroons/browns.

prissi

As mentioned before: Skycrapers on level>14 will probably lead to other drawing errors (sudden appearances and so on). I failed to generate a map with more than 16 differences. This may change with half level heights from kierongreen. But so far the extreme elevations are unlikely to be seen at all.

AP

Quote from: prissi on January 10, 2013, 10:36:46 PM
As mentioned before: Skycrapers on level>14 will probably lead to other drawing errors (sudden appearances and so on). I failed to generate a map with more than 16 differences.
Is that 14+ a relative or absolute? I.e. if sea level is down at -10, are there 24 'good' levels, or is +4 the last 'good' level?

In experimental, to create a map such as the inital one I posted, combining the water level at -10 with a mountain height of 250+ gives a significant number of levels - I just had a map with cities varying from -9 to +12 altitude - but in 1800 so no skyscrapers! I don't know if that's possible via Standard map creator, I don't have a version installed to try with.

ӔO

try this save: http://dl.dropbox.com/u/17111233/height_test.sve

I started it in pak128 2.2.0, but there are no objects so it should load in any pakset.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Dwachs

Parsley, sage, rosemary, and maggikraut.

kierongreen

Just posting to confirm that Dwach's new colours work great with double heights :) Very extreme heights  do still break but these are only generated with height 320 and roughness 10!

boriselperro

I agree with all the comments about the minimap, but for me the greater problem is that there seems no way to build anything at maximum heights. It wont let you establish a new city, or build  road or rail - or anything. The relevant cursors just disappear. (I am in Britain experimental 128. I have just started with the latest version, which I think is terrific, apart from this particular issue.). Am I doing something wrong or is this a recognised problem? Is there something in the settings you can do to avoid this?

The other part of the problem is that when moving about the terrain at maximum altitudes, I kind of "lose" half the ladscape, it disappears.

Thanks in advance for any helpful suggestions.