Re: GIS Tutorial Online

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

sales@gencom.us wrote:

> Quoting mskala@ansuz.sooke.bc.ca:

> > I'd much rather be able to define images per-hex instead
> > of per-terrain-type; that seems like it would serve the same goal and be
> > much nicer.
>
> To me this makes sense. This would mean that map attributes are defined in a
> uniform array per tile. The _tile_ is the object. It then carries with it a
> number of attributes such as terrain type, elevation, climate, etc. 

An individual hex only has certain attributes that can be associated 
with. Among them, terrain type and elevation. As it stands now, images 
are only associated with terrain types, and not directly with hexes. An 
hex acquires an image via its terrain type. As far as other attributes 
such as climate, terrain ruggedness, vegetation, etc... go, you must 
find some way of artificially simulating those attributes. I suggested 
one way (creating defined groupings in the game definition file), and 
Lincoln suggested another (using coatings as sort of customizable 
"attribute layers").

It should be noted that Xconq has the concept of layers, which were 
mentioned in a references I sent you a while back ago. Layers track 
things such as terrain, winds, coatings, connectors, borders, land or 
sea, etc.... One can argue about what a Xconq map hex is, but one way to 
look at it is something that has a coordinate position and has "depth" 
into one or more layers. All hexes have depth into the terrain layer, as 
this tracks terrain type and how is an hex is able to "know" what it 
looks like.

> Does this mean major changes to the Xconq code, Eric? Would we have to change
> the Xconq kernel or could we get away with doing this on the module side?

I have made no attempt to quantify how much work will be involved. In 
the reply I sent you last night (to your "cstevens" address and not the 
"sales" address), I outlined some of the areas you will probably want to 
look at. I think it is reasonable to assume that you will have at least 
some coding that needs to be done in the kernel and the user interfaces.

> > It would be really nice, too, if that one file could be just the direct
> > image (possibly scaled to size), and then XConq smart enough to clip out
> > hexagonal chunks in the right places.  That would mean changing the
> > read-from-image code to use a hex grid corresponding to the map instead of
> > the current square grid, but it would mean eliminating an especially nasty
> > cut-and-rearrange step in creating the file.
>
> I agree. This way if Eligah wanted to create his "Lord of the Rings" map, he
> could simply do so starting with a Middle Earth map

If people want to try doing things this way, it could probably be done 
by creating two new layers (x-pixel-coords and y-pixel-coords), which 
would contain the pixel coords within the map image that are associated 
with each hex. Then, instead of indirectly accessing an hex image 
through terrain type, it would be pulled from this layer instead. I 
haven't thought through the details; _just throwing out an idea....

Eric