From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15714 invoked by alias); 8 Jan 2004 16:46:09 -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 15707 invoked from network); 8 Jan 2004 16:46:08 -0000 Received: from unknown (HELO garm.central.cmich.local) (141.209.15.48) by sources.redhat.com with SMTP; 8 Jan 2004 16:46:08 -0000 Received: from leon.phy.cmich.edu ([141.209.165.20]) by egate1.central.cmich.local with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Jan 2004 11:44:21 -0500 Received: from localhost (unknown [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id 5C1667000B; Thu, 8 Jan 2004 11:44:18 -0500 (EST) Date: Thu, 08 Jan 2004 16:46:00 -0000 From: Eric McDonald To: Hans Ronne Cc: xconq7@sources.redhat.com Subject: Re: New Action: change-type In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 08 Jan 2004 16:44:21.0664 (UTC) FILETIME=[AA967200:01C3D606] X-SW-Source: 2004/txt/msg00045.txt.bz2 Hi Hans, On Thu, 8 Jan 2004, Hans Ronne wrote: > acp-dependent case. Except, of course, that the corresponding ai code will > be more difficult to write. So. Bring it on. :-) I'll deal with it. >This is a problem right now, there are too many > features in the game that are not supported in the ai. I hope to change some of that in the future. > I'm not sure I follow you here. Why would downgrades require multiple > options? Not that it would be impossible to implement, but I see no > difference in principle between upgrades and downgrades. Sorry. I wasn't very clear here, and I realized that after I went to bed. A downgrade would require one utype field and an upgrade would require another one. That is where the two came from. But I will concede that two is lot less than a whole table (unless you only have one unit type defined). > I didn't notice you had tried it out. I think the docs are somewhat > misleading. I believe that is why some game designers have used these > tables in the wrong way. I don't believe that I am using them in the wrong way. They are there to prevent actions from occuring if a minimum amount of certain materials are not present, but those certain materials need not be consumed by an action. I believe I do (or did) that with the Supplies (s) material in Bellum: a unit must have at least 1 to act, but consumes none by acting. I also include the consumable supplies for the previously mentioned reason/superstition that actions could still take place even if not enough of the consumable was present. Eric