[CF-Devel] speculations about the floor (elevation)

crossfire-devel-admin at archives.real-time.com crossfire-devel-admin at archives.real-time.com
Fri Jun 27 22:30:27 CDT 2003


Mark said:
>
     
     
     >
     
        It would be trivial to add a field to the map header like
     
     'map_elevation'.  It
>
     
      would also be easy to populate the archetypes with 'sane' elevation values
     
     >
     
      (mountains are 5000 feet or whatever).
     
     
Putting set elevations for arches isn't optimal IMHO (besides then you
wouldn't it be better to set up a list of values to look up rather then
carry the value in the arch (mountain: 5000).  The thing is this method
ignores relativity - a forest or a lake or a desert on an map with an
elevation of 15000 ft should be possible even desirable. Also, I can't see
setting a default elevation for arches like floors and stuff.
I can picture a routine similar to the way the maps were generated but
inside out, where the map base elevations are loaded plotting out a
wireframe of the world, then the script finds large groups of arches, plots
the middle elevation values of these groups based on the wireframe base
elevations and size of the groupings and type of arch and then does this
with smaller groups of arches then again with smaller groups ... then builds
up more detailed slope informain for the points in between based on the
remaining differences.
You could use this routine for any world map you like, you could generate
another map like bigworld was generated then calculate the average
elevations per map and run this script to make the landscape more relative
or you could design a world by hand with a rough elevation model (one point
per map) and run this to generate a detailed elevatons for you...

Also this way you wouldn't have small changes like adding roads or other
'human made changes' (remove the forest arch add a flagstone arch...)
require a elevation be changed at all.

>
     
     
     >
     
        I'm unclear on the idea of dumping the elevation to a file - why dump it
     
     at
>
     
      all then - if this is automatically generated, which is likely to
     
     overwrite
>
     
      existing data, why not just have the weather system itself say 'map
     
     elevation
>
     
      1234, this is forest, so I should ...)
     
     
Well i thought that that would be too labour intensive to constantly
generate this informaion since it does not change during play - I don't see
a need to run the elevation generation routine very often, only when there
are major changes to the world map (a new mountain pass, a new lake...large
forest or desert created.)  The running weather code merely needs to check
the elevation of a tile, not modify it.
Putting the elevation in a file is just to seperate the per tile elevation
from the map to make it mainatainable.  I assumed it would be wasteful to
store these values in memory and thought it would be pretty easy to have a
file or set of files to reference instead (these weather maps could be
generated every release or so and shipped out with the worldmaps
incidentally to avoid people having to generate them unless they make
changes).  Really this isn't so much a change to the weather system as it is
a change to the initial weather map build routine.  It also makes it easy to
generate new elevation maps for other areas (perhaps you want to generate an
elevation map for the eighth plane of hell map set you are working on...)

Also all the other weather maps are generated and stored (humidity,
pressure, average elevation), so this would follow with that idea - there is
not much use in regeneratin these if the maps havent changed and they should
be regenerated if it has changed significantly.

>
     
     
     >
     
        If these other elevation files are supposed to be maintained, I then
     
     really
>
     
      wonder how likely that is to happen.  Map makers making changes may not be
     
     aware
>
     
      of them.  And as said, if this is just holding generated data, why not
     
     have the
>
     
      weather system itself generate that data?  Maybe I'm missing something
     
     there.
>
     
     
     
That is the point of doing this in the firstplace so that that mapmakers
don't have to be concerned/aware of this at all.
The weahter system can run almost as it does now except that instead of
reading elevation from the worldmaps it can read them from it's elevation
map.  There would be no changes to the editor and mapmaking procedure at all
and little change to the existing weather code.   The only difference is
that when the world maps are changed enough to warrent a fresh set of data
the serveradmin could run the command (script?) to regenerate the elevations
so that the wetaher map can reflect these changes.  This should be done now
anyway now to pickup other arch information such as water percentages for
the humidity maps so it is just an extention of existing methods.




_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel
     
     
    


More information about the crossfire mailing list