From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27196 invoked by alias); 25 Sep 2004 14:04:20 -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 27187 invoked from network); 25 Sep 2004 14:04:19 -0000 Received: from unknown (HELO urk.execulink.net) (199.166.6.45) by sourceware.org with SMTP; 25 Sep 2004 14:04:19 -0000 Received: from diamond.ansuz.sooke.bc.ca (ppp119.ac2.56k.execulink.com [209.213.229.119]) by urk.execulink.net (8.11.6/8.11.6) with ESMTP id i8PE4GY10927; Sat, 25 Sep 2004 10:04:17 -0400 Received: from localhost (mskala@localhost) by diamond.ansuz.sooke.bc.ca (8.10.2/8.10.2) with ESMTP id i8PE0Ox18424; Sat, 25 Sep 2004 10:00:25 -0400 Date: Sat, 25 Sep 2004 16:16:00 -0000 From: mskala@ansuz.sooke.bc.ca To: Eric McDonald cc: cstevens@gencom.us, xconq7 Subject: Re: GIS Tutorial Online In-Reply-To: <4154FAA7.7020504@phy.cmich.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004/txt/msg01238.txt.bz2 On Fri, 24 Sep 2004, Eric McDonald wrote: > I'm not sure what Matthew (IIRC?) had in mind when he disagreed with the > 1 terrain type per hex image idea. Maybe we are all miscommunicating > what we really mean.... Just that it seems like it'll multiply terrain types unnecessarily, and terrain types are somewhat expensive. If I have two chunks of almost identical desert, but they have different images, then I have to duplicate the definition of "desert" throughout my game definition. Even if I define a list variable for "all desert hexes", that's only a syntactic convenience - the actual game definition still has two separate complete copies of the definition. It's especially a problem because "two" in this case is probably more like "hundreds". I don't want to look at the help menu that will result from having hundreds, or thousands, of defined terrain types... 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. On multidimensional "binning", that's a well-studied problem and relevant to my research, so I'd be happy to expound on the different standard algorithms for it if people would like. I did some of that (with just two dimensions) in defining terrain types on the Antarctica map, as described in the document about that which I posted on the Wiki; there, I wasn't doing it in an automated way but just by hand, manually examining the scatter plot and tweaking classification rules to get results I liked. By the way, has anyone tried playing the "standard game adapted for Antartica" module I posted? I'd be interested to hear how people liked it if they tried it. > I have no problem with multiple files in an intermediate processing > step, but all the terrain images for a given terrain image set should be > kept in one file, when all is said and done. See 'stdt44x48.gif', 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. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/