This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adapting GIS data to Xconq


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]