From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3393 invoked by alias); 10 Sep 2004 04:03:26 -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 3362 invoked from network); 10 Sep 2004 04:03:25 -0000 Received: from unknown (HELO smtp807.mail.sc5.yahoo.com) (66.163.168.186) by sourceware.org with SMTP; 10 Sep 2004 04:03:25 -0000 Received: from unknown (HELO ?192.168.1.101?) (sampln@sbcglobal.net@67.121.168.201 with plain) by smtp807.mail.sc5.yahoo.com with SMTP; 10 Sep 2004 04:03:24 -0000 Subject: Possible bug in side_can_research From: Lincoln Peters To: Xconq list Content-Type: text/plain Message-Id: <1094789127.4338.103479.camel@localhost> Mime-Version: 1.0 Date: Fri, 10 Sep 2004 19:17:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01148.txt.bz2 When I re-wrote ai_plan_research, I had assumed that the side_can_research function would return false for advances that have already been researched. However, having run advances.g several times under AI control, I've found that the AI will frequently select an advance that it already has discovered. And I have not found any logic errors in the new ai_plan_research function.* Would it be reasonable to modify side_can_research so that it returns false for advances that the side already has? Or would it be better to place the necessary code in ai_plan_research instead? * This is not to imply that no logic errors exist in the new version, just that if they do exist, they are currently undiscovered. --- Lincoln Peters BOFH excuse #251: Processes running slowly due to weak power supply