From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7842 invoked by alias); 21 Sep 2004 01:44:52 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 7816 invoked from network); 21 Sep 2004 01:44:51 -0000 Received: from unknown (HELO sccrmhc12.comcast.net) (204.127.202.56) by sourceware.org with SMTP; 21 Sep 2004 01:44:51 -0000 Received: from [192.168.181.128] (c-67-172-156-222.client.comcast.net[67.172.156.222]) by comcast.net (sccrmhc12) with ESMTP id <2004092101445001200cssmje>; Tue, 21 Sep 2004 01:44:51 +0000 Message-ID: <414F8790.80102@phy.cmich.edu> Date: Tue, 21 Sep 2004 02:09:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) MIME-Version: 1.0 To: Lincoln Peters CC: Xconq list Subject: Re: Coatings References: <1095632486.15989.24818.camel@localhost> <414E16D4.6070007@phy.cmich.edu> <1095640501.15989.25877.camel@localhost> In-Reply-To: <1095640501.15989.25877.camel@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01206.txt.bz2 Lincoln Peters wrote: > Interesting. However, I wanted to be able to track vegetation > separately from physical topography, since I suspect that the data from > the GIS would contain so many different combinations of those two > properties (as well as others) that implementing each combination as a > separate cell terrain type would be even more work. The whole point of binning the same cell into multiple categories is so that various aspects of that cell can be tracked separately. Assuming that the topographical data and the vegetation data can be aligned and scaled the same, then each cell cut out with a "hex cookie cutter" would have both of those layers, each of which could be used to bin the separately in the relevant category. >>A problem is that liquid terrain is special to Xconq in several ways. >>One of these is that the AI relies on a land-sea regions layer to >>determine whether a body of water is large enough to consider building >>naval units. If everything is a bare cell underneath, then the ability >>to make [designer-guided] intelligent naval construction decisions is >>impaired. > > Maybe it would instead be possible to make the cell terrain types land > and water, and the physical properties (sand, silt, clay) as Coating > Level 0. Or it may turn out that the physical properties I mentioned > are meaningless for 99% of all situations and so could be omitted from > the planned terrain module entirely. This could be a reasonable modification to address the liquid terrain concern. >>For a fantasy game, someone might wish to assume a world that truly is >>flat, and has spirits with chubby faces blowing across the face of the >>world, __you know, Boreus, Zephyrus, and that bunch.... > > In most cases, such fantasy is also based on a assumption that the Earth > is flat and the suns revolves around the Earth. This means that the > Earth would most likely *not* be rotating, in which case Coriolis force > is zero. That was my point. Eric