From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31374 invoked by alias); 24 May 2004 19:04:57 -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 31362 invoked from network); 24 May 2004 19:04:55 -0000 Received: from unknown (HELO urk.execulink.net) (199.166.6.45) by sourceware.org with SMTP; 24 May 2004 19:04:55 -0000 Received: from diamond.ansuz.sooke.bc.ca (ppp200.ac2.56k.execulink.com [209.213.229.200]) by urk.execulink.net (8.11.6/8.11.6) with ESMTP id i4OJ4oZ11487 for ; Mon, 24 May 2004 15:04:50 -0400 Received: from localhost (mskala@localhost) by diamond.ansuz.sooke.bc.ca (8.10.2/8.10.2) with ESMTP id i4ODpMi02307 for ; Mon, 24 May 2004 09:51:22 -0400 Date: Mon, 24 May 2004 19:04:00 -0000 From: mskala@ansuz.sooke.bc.ca To: xconq7@sources.redhat.com Subject: Random terrain changes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004/txt/msg00407.txt.bz2 I'd like to be able to do random terrain changes with the terrain-density table, without using the rest of the fractal terrain generator, so that the result is basically a constant map I specified, but with a few random surprises. One way to implement that (not sure if it's the best) would be to separate random terrain changes into a separate synthesis method which can run independently of make-fractal-terrain. Then it could be run not only with a designer-specified map, but also with any of the other synthesis methods. Actually, that's how I thought it already worked based on the way the documentation is laid out (each synthesis method in its own subsection, and random terrain changes in a subsection of its own), but from the code it's clear that at the moment random changes are actually an inseperable part of the fractal generator. I might try to write a patch to do this, but it's not my top priority right now. One disadvantage to moving it into a new synthesis method would be that if someone was currently using terrain-density and also specifying an explicit synthesis method list, then they'd have to add the new method to the list. As far as I can tell, Bellum Aeternum is the only currently-shipped game that would be affected. Presumably it would be part of the default and so not require any changes to games that used the default list. A slightly less elegant solution would be to leave random terrain changes in the fractal-terrain method, but also add a synthesis method not part of the default to only do the random changes. Then no changes to existing games would be needed at all, but the result might be confusing to designers because you'd get random terrain changes always with fractal terrain, but only when explicitly requested with other synthesis methods. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/