For worldmappers: You _must_ set elevation on worldmapground

[Mikeeusa22]

For worldmappers: You _must_ set elevation on worldmap ground tiles. If you do not the server crashes (with weather code on)... this is not acceptable just because MF dosn't use weather.

What I do is c+p set world tiles to create my areas etc.
Perhapse make a pickmap for yourself with diff elevations etc?

[Mith]

how do you handle a huge set of world tiles?

i've been working on some project, but i (temporarely) cancelled it because i didnt want to modify say 10000 map tiles by hand...

by the way, when i modify a mountain to grassland, i guess i should also modify the elevation. Is there a list of elevation/map tile relations?

e.g.
elevation < -10000 deap see
...
...
elevation 0-100: beach, grassland, desert, ...
elevation 100-1000
...
...
elevation > 17000 very high mountain

[Mikeeusa22]

I guess. I just CP a few tiles from the world to get the elevations.
Make a pick map and it will be easy.

[bort]

There should be default elevation set for the default objects/.

[Mith]

there should be a elevation grid that is independent of the map tiles above them. (look at it as where the map file a texture, wrapping around the grid)

and there should be an option to auto-adapt the elevation grid, so if you change very high mountains into swallow sea, the elevation should drop slightly

[cavesomething]

if you change very high mountains into swallow sea, the elevation should drop slightly

Slightly? surely 'massively'.

As it is I am inclined to think it would be nicer to set the elevation algorithmithly (determine the height at runtime based on the land nearby, defining mountains to form a gaussian or some such, water is always lower than surrounding land, so are rivers, etc....)

However to determine how to do this in a consistant manner could prove to be somewhat tricky.[/quote]

[Mith]

As it is I am inclined to think it would be nicer to set the elevation algorithmithly (determine the height at runtime based on the land nearby, defining mountains to form a gaussian or some such, water is always lower than surrounding land, so are rivers, etc....)

However to determine how to do this in a consistant manner could prove to be somewhat tricky.

We do not disagree much this time

I only think there is no reason to do this runtime once it is incorporated in the map editor(s) I have no idea how cpu-intensive this calculation would be, but not to overload the servers, i think it would be wise to store this data together with the map files

I spoke about a elevation grid without mentioning how to form it, you wrote about how to form it, without mentioning what to form. If we combine these ideas, we'll get an algorithm that determines the elevation grid.

It would not be very hard to extract the current grid from the existing map files and then only adopt when needed. (maybe scorn's elevation has to be altered too, its on top of a high mountain - hence the rain, i think)

note: swallow sea does not necessarily have an elevation < 0 -- there are many lakes high in the mountain. this might be one of the tricks...

[cavesomething]

We do not disagree much this time

I only think there is no reason to do this runtime once it is incorporated in the map editor(s) I have no idea how cpu-intensive this calculation would be, but not to overload the servers, i think it would be wise to store this data together with the map files

danger, it should belong with the weathermap, which is generated from the mapfiles but stored seperately. The map files are edited and replaced, storing generated data there will break diffing against maps.

I spoke about a elevation grid without mentioning how to form it, you wrote about how to form it, without mentioning what to form. If we combine these ideas, we'll get an algorithm that determines the elevation grid.

It would not be very hard to extract the current grid from the existing map files and then only adopt when needed. (maybe scorn's elevation has to be altered too, its on top of a high mountain - hence the rain, i think)

note: swallow sea does not necessarily have an elevation < 0 -- there are many lakes high in the mountain. this might be one of the tricks...

well for a start try this as an initial approximation. Mountains ranges should have a base plane (for big mountain ranges this is probably sea level). This plane may be sloped. it will be defined by water level around the outside of the mountain range.

Above the plain mountains should have a maximum single square height rise of 200m, hills a maximum of 100m, plains maybe 20m, etc.

where mountains butt onto plains, and surround them, then the plains are a plateau, this plateau should have less, but not vastly less elevation than the surrounding mountains, it may be sloped consistant with mountain heights, but not more than 20m a square (if the rise is too high it goes to the lower value).

Water is always lower in elevation than any non-water squares around it (read my previous post, I said lower height, not negative height, there too)

water defines distance to watershed. If there is lots of water (lake/river, not sea if it is connected outside the map) in an area then any mountains must slowly rise in height over many miles. If it is very dry, then it must be a steep rise.

Any water body that isn't a river and that is continous to the edge of a map has sea level less than zero. (this being sea level).

bodies of water slope down, and always hit zero in the square adjacent to shore, shallow water is not deeper than 50m.

Roads do not slope by more than 40m in any square. (they wouldn't be roads otherwise). Mountain paths can be added as a new archtype if the geography fails miserably this way.

It is 'shallow' sea, not swallow sea, a swallow is a bird (african or european?), or an action that you make when you drink liquid. Neither is likely to have much effect on a sea-sized body of water (though the later in sufficiant quantity will kill you, as your cells dehydrate due to osmosis).

[Mith]

i think it would be wise to store this data together with the map files

danger, it should belong with the weathermap, which is generated from the mapfiles but stored seperately. The map files are edited and replaced, storing generated data there will break diffing against maps.

with =/= within...
i thought of something like world_111_111 and grid_111_111, this wont break diffs
maybe have the server check the last_modified data for these files. when they differ, regenerate the grid, otherwise use the stored grid file
(this also eliminates the problem of old editors that do not have a grid routine)

well for a start try this as an initial approximation. Mountains ranges should have a base plane (for big mountain ranges this is probably sea level). This plane may be sloped. it will be defined by water level around the outside of the mountain range
[....]

i should reread this section to understand it - but i better read my study books right now... i'll skip the section and have a second look next tuesday

i would like to see it possible to overrule the algoritms guesses with explicit altitude definitions in the worldmap files. (the algoritm should takes these values as base values)

about the roads: this should only apply to paved roads. (the new arch 'foodpath' shouldnt be limited this way - its limited by its green background color)
also, bridges could be used to pass a ravine or a canyon

[Casper]

I assume then that walking uphill would be slower than walking downhill, shoting downlill should hurt more, and falling off something should hurt unless you can fly.