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

[crossfire-devel-admin at archives.real-time.com]

>
     
       I recall right now you have to click on an object/space to see the 
     
     >
     
      elevation, correct?
     
     >
     
     
     >
     
       If so, I wouldn't really call that clearly visible.  Imagine you want 
     
     >
     
      to look at a map and quickly see what the elevation is doing - that's 
     
     >
     
      a lot of pain there.
     
     
well not so much pain as entering a good value.  It isn't having the 
value that is the issue, it is having a good value.  I can't come up 
with enough good pseudo slopeing numbers for a 10x10 map.  Now if you 
want to do something in the editor, make a elevation fill command where 
you set the eleavtion for two points and it 'fills' in values on 
selected squares in between...  Even then it will be choppy and 
unnatural values, but better than some other methods.

>
     
     
     >
     
       Your point of massive map changes is valid.  How often is that likely 
     
     >
     
      to happen?  (honest question).  And we are talking about the existing 
     
     >
     
      bigworld maps here - if someone scratch builds a new world, that is a 
     
     >
     
      different can of worms I'm not trying to solve, and I don't think 
     
     >
     
      there is a good way to solve that (I think any automatic elevation 
     
     >
     
      generation system is likely to have problems/issues also that would 
     
     >
     
      make it less than ideal).
     
     >
     
     
     Often.  Almost any change to the worldmap (and it's empty right now...) 
I've done it a few times in the last few months since I seem to be the 
only one making the attempt.  The change does not have to be that large 
at all to cause a large number of changes - adding a small town or a 
road of any length or a lake or cutting away at a bit of mountain 
happens all the time and is a royal pain to fix the elevation.  I have 
used the backfil script  when the changes didnt really *have to* address 
the elevation (re-arranging hills and forest a bit adding of swamp, 
although I wonder aboutthe swamp)  and I wrote a script that would 
assign likely ranges when the changes were entirely elevation specific 
(Andy's mountains arounf Brest, adding a lake, mountains around 
Scorn...).  Both ways are not really sustainable for reasons I have 
mentioned.
What good is having the weahter code look up the elevation if the value 
has no relation to the map (like if you add some lakes to a mountain but 
do not smoooth out the lake elevation or if you change so9me ocean to an 
island).  Retaining the existing elevaiotn is usually pointless except 
for the most minor changes (even roads should be smoother then 
surrounding areas).

This is double if you start talking about using elevaition for LOS or 
other game value.

I agree that how it is generated (initailly or ongoing) is really a 
seperate issue than how it is stored.
One thing that just keeps coming back to me (the more I read too...) 
however is that elevation can still be *in* an object even if it is 
stored in a seperate file...   I just thought if it was in a seperate 
file it would be easier to slice, dice, generate or ignore.


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