This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Adapting GIS data to Xconq
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Lincoln Peters <sampln at sbcglobal dot net>
- Cc: Xconq list <xconq7 at sources dot redhat dot com>
- Date: Sun, 31 Oct 2004 11:39:22 -0700
- Subject: Re: Adapting GIS data to Xconq
- References: <1099208327.26829.5395.camel@localhost>
Lincoln Peters wrote:
1. I don't think it's possible to un-define a terrain type once it has
been defined, so if, for example, a terrain module supported the use of
coatings to represent soil composition, there would be no way to disable
it (and thus free up some memory) in a game that doesn't need to deal
with soil composition. How difficult would it be to implement such a
thing?
Rather than attempting to deallocate something, I think it would be
better to conditionally allocate it according to need. There is an "if"
conditional GDL, but I have not attempted to use it. There is support
for it in the code. I would suggest you try something like:
mygame.g:
...
(define USE_SOIL_COMP false)
...
omniterr.g:
...
(if USE_SOILCOMP
(terrain-type soilcomp-k-lvl-0)
...
)
...
2. The NLCD system of classification used by the USGS treats developed
areas as a terrain type, whereas Xconq usually treats them as units. In
scenarios such as Beirut and Gettysburg, I can see the advantages of
defining developed areas as terrain type(s), but games on a larger
scale, such as the Standard game, would not work if towns and cities
were treated as terrain types. Perhaps the best solution would be to
define developed areas as terrain coating types, and allow developers to
make units that go on that terrain? I'm really not sure.
Interesting issue.
Eric