[CF-Devel] speculations about the floor

Fri Jun 27 01:47:26 CDT 2003

Todd Mitchell wrote:

<snip>

  I agree the current method for elevation is not very good.

>

     >

      So what about it?  Well I think it could be better with not a huge amount of

     >

      change.  a I would suggest that the elevation actually be generated from the

     >

      maps on demand when there are significant changes (something like running

     >

      './crossfire  -E' perhaps?) , and this be stored in a set of elevation maps

     >

      (just a set of 'maps' which store x,y coords and the elevation).  Each world

     >

      map would be assigned an average elevation (so if you created your own

     >

      worldmaps you would only have to plot the base elevation each map) and a

     >

      script would generate sensible elevation for each map tile based on the arch

     >

      information.  Fixing the map editor to generate intelligent elevation would

     >

      require an approach like this anyway, but this way you could generate

     >

      elevation for any set of maps given the map base elevations.

  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).

  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 ...)

  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.

>

      On a side note, it would be neat if the client could automatically run the

     >

      weather command every so often to let people know the temperature and stuff

     >

      is like - perhaps only when the player is outside and with a setting to turn

     >

      it off of course...

  It'd be much easier for the server to 'push' this information if it is 
desired.  The client requesting it is sure to get a bunch of bogus data 
(requesting it while indoors for example).  It'd be easy to have some record of 
last time server told this information to client, and if that time has elapsed, 
and the player is on an appropraite map, send the data.  This would have the 
other effect that if a player was indoor for a while and stepped outdoor, they'd 
get a near immediate update.

  One could easily see expanding this to be non textual, eg, client display a 
little weather symbol like found in newspapers (sunny, cloudy, rain, snow, etc), 
an icon representation of time (sun moves across the sky, then the moon) as well 
as other relevant data (moonphase?)

>

      Well the race field comes to mind here, it would be

     >

      neat to use race for ground (and for other arches possibly) to indicated it

     >

      belongs to *something*, this something would be of course an other object

     >

      with it's own arch.

  I have no issue with the race (or other text field not likely to be used for 
ground) to represent some form of belonging, which other objects/code may then 
check for various meaning (eg, player is on lythanders forest, and this script 
cares about it and does something special).

 >  An example would ge a forest where many or all the
>

      ground tiles belonged to a "Dark FOrest" arch and these arches would inherit

     >

      some properties form the dark forest arch (like slower movement, or damage

     >

      or faster mana renegeration...)

  I disagree about that - first, such a lookup would be very inefficient (have 
to translate name to an archetype, which is a relative costly operation).  But 
more to the point is I don't think it is a good approach - it would be confusing 
(why is my forest arch not getting the values I set in the editor?) and probably 
create other issues - someone changes the definition of that 'race' for his 
forest, and some other space someplace else was using it because it was 
convenient, and that now breaks.

  I can't see any good reason not to just put the relevant adjustments in the 
object.  If it would be used alot, conceivable to make an archetype out of it. 
I generally don't like a bunch of surplus archs that are used just one place, 
but this description doesn't match this - this would be an archetype used for a 
large swath of land.

>

      This could be an atlernative way (less

     >

      cluttered) to do no_magic and cursed ground as well, define then as an

     >

      property of the parent arch to be inherited.

  Not sure what you mean by 'less cluttered'.  If you are talking about needing 
to have 2 objects on a space to be non magic (ground + actual no magic arch), 
that isn't strictly true.  That is just the preferred map design method - it 
makes it abundantly clear where no magic areas exist.

  One could just as easily modify the appropriate ground and set the no_magic 
and other fields and have that space be no magic without need for another 
object.  But that makes it be a real pain if someone is trying to look at the 
map later - they now need to click on each object to see what its properties may be.

  For this reason, it is generally preferred not to overlay too many meanings on 
an object.  Eg, instead of changing the face of the 'exit' object to be a 
forest, just put an invis exit on that space - much easier to deal with than 
figuring otu that space that looks like all the other one actually has an exit.

  With the java editor, and the filters it has, this isn't so much an issue. 
One could obviously extend that to 'show no magic' and 'show unholy ground', as 
well as other 'common' things like that.

>

       It could be used to define the

     >

      area of a town by setting a 'town' object as the race of it's land (the town

     >

      object could also be put into NPC inventory...)

     >

      This belongingness concept doesn't necessarily have to be confined to ground

     >

      tiles, it would be a neat way to actually do player races (the races would

     >

      become arches in this case), but this would be a larger type of change than

     >

      I should be advocating at this time...

  Well, I have no problem with regions, and players belong to regions, and using 
some way to mark the region.  And based on that region, some things get adjusted 
(eg, if you don't belong to a region, you get higher prices - taht is actually 
easy to do, and doesn't actually care what the region is).

  I do have issues with region pulling in attributes of hte objects - if 
necessary, make regional archetypes for grass, forest, etc, but less not have 
normal arch's get changed based on the region they belong to.

  One thing which I would be willing to entertain is default map values.  Eg, a 
special object on the map (or map header) which says the defaults.  thus, you 
could put the object like:

object map_default
region scorn
slow_penalty 1
...
end

  Now the only issue would be what to do if an object already has an attribute 
set.   I'd think you'd have to keep with the one on the map object and not 
default - that is more narrowly defined (single object) vs a default.

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

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