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

Sat Jun 28 18:13:38 CDT 2003

>

     >

     >

     Maybe a question to consider in that case is: can't the weather be computed 

     >

     using larger grid elements, for example 10x10 squares ? The weather would 

     >

     still be precise enough, but computing time would be reduced somewhat. I 

     >

     doubt a square-level granularity is really needed given the apparent scale of 

     >

     the bigworld map.

     >

I don't advocate changing the resolution or the way the weather actually 
runs in game.  I think having an elevation value for each tile is 
reasonable, but just should not be stored in the arch so that map makers 
don't have to deal with it.  Computing time wouldn't really be an issue 
here since this computing would not be done while the server (game part 
anyway) is running.  The weather map generation is already a long 
routine since it must examine each arch anyway to generate humidity and 
pressure maps.

>>

     I understand some people don't like fully random maps.  Thats perfectly

     >>

     fine. I have no intention of forcing anyone to use them.  But I would like

     >>

     to be able to set a setting and have them occur.  

     >>

     >>

     >

     >

     I don't understand the goal of doing this for the worldmap. The worldmap by 

     >

     itself is just a way to bind all quests and locations together in a coherent 

     >

     way. The worldmap isn't seen as a quest by itself. What would be the purpose 

     >

     of such a system ? Is it worth sacrificing speed on commonly used parts of 

     >

     the code for it ?

     >

     >

     I would like the weather to work with any set of world maps - no matter 
how they were generated.  I just don't think it's a good idea to tie in 
the elevation generation for weather with the map creation.  You can 
create a world map any way you like (generated by a fractal program, by 
hand, from a digitized map of France or a photocopy of your butt...) and 
hopefully build an elevation map for weather for it with just a per/map 
base elevation value and a table for elevation ranges for arches.  
Having to plot a base elevation per map is a reasonable comprimise 
(compared to somehow generating a value for every tile on the map) I think.
Also, I suspect a working elevation map for good weather can be a bit 
chunkier along the z axis than than an elevation map for generating and 
placing landscape.
I brought this up as a possible answer to Andi's remarks on preserving 
elevation with the map editor (bad idea IMHO) not to have Tim or anyone 
rewrite the weather system.  If someone comes up with a suitable script 
to do this then I am suggestin we use it is all.

>

      Anyways, to me, the ideal solution would seem to be to keep in the 

     >

      object itself.  We apparantly have scripts that will backfill 

     >

      elevation data - presumably, these scripts can be/are smart enough to 

     >

      only fill in spaces where elevation has been removed, and not to write 

     >

      over elevation for spaces player explicity sets.

     >

     >

       What's the problem of using these?  It seems much simpler than 

     >

      writing a new system to deal with this, especially because the tool is 

     >

      already in place. Presumably, it wouldn't be hard to also make these 

     >

      have a little bit of logic (eg, the area on this map in spaces x,y -> 

     >

      x1, y1 shouldn't be backfilled, but instead of an elevation of 1200 ± 

     >

      200 ft, to mimic variation in landscape. 

The problem is that it is really hard to keep this information in the 
arches and if you manage to preserve it when you make changes, the 
information is really meaningless anyway.   Right now you can screw up 
the weather system by adding a little town to the worldmap.  Or the 
roads - this is way too fragile. Case in point - when Andi put a ring of 
mountains around Brest I could not just use the backfill script since 
the old elevation wouldn't match the fact that there were mountains 
there now (and then what's the point right?).  For this I ran a script 
to lay elevation values based on the arches (like a mountain was 
5000-11000 ft, a snowy mountain was 16001 - 25000 ft...) but this 
produces a choppy, not smoothly landscaped.  The tiles that were added 
and the old tiles that didn't change could easily have huge elevation 
gaps between them.  You would see a nicely sloped mountain range, but 
the elevation is jagged cliffs (the alternative however was no elevation 
which is like a pit.) 
Over time storing the elevation in the arches and filling it in with 
scripts will cause choppy and non-representative elevation data.  If you 
can come up with a logical script to fill in the elevations, then it 
would make more sense to run it only when the maps changed anyway - 
which is my what I am saying.  The only thing is that if you save the 
elevations in the arch you have to run this script every change or you 
have these dead cells, where if you save it as a elevation map itself 
you only have to run it when there are substanial changes (you don't 
need to run it when you build a road or forest an area, only when you 
add a lake or a mountainn or something...)  There isn't a need to change 
the weather code drastically to do this either, just come up with a 
logical way to generate elevation from the existing maps and store the 
elevation differently, and you could get by with just copying out the 
existing elevation for now.

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel