From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3693 invoked by alias); 15 Dec 2003 04:18:39 -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 3685 invoked from network); 15 Dec 2003 04:18:38 -0000 Received: from unknown (HELO smtp806.mail.sc5.yahoo.com) (66.163.168.185) by sources.redhat.com with SMTP; 15 Dec 2003 04:18:38 -0000 Received: from unknown (HELO 6-allhosts) (sampln@sbcglobal.net@64.175.248.254 with plain) by smtp806.mail.sc5.yahoo.com with SMTP; 15 Dec 2003 04:18:37 -0000 Subject: Re: Cannot do anything in water From: Lincoln Peters To: Xconq list In-Reply-To: References: <1070854101.22214.7955.camel@odysseus> (message from Lincoln Peters on Sun, 07 Dec 2003 19:28:22 -0800) <1070854101.22214.7955.camel@odysseus> Content-Type: text/plain Message-Id: <1071462057.11561.24.camel@odysseus> Mime-Version: 1.0 Date: Mon, 15 Dec 2003 04:38:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2003/txt/msg01040.txt.bz2 I have found that this mysterious water bug affects bolodd2.g, as well as the new game I'm working on. If you try to move a naval unit into the water (I haven't tried air units yet), the unit expends an ACP without going anywhere. I also noticed that, in roman.g, an infantry sometimes expends an ACP while trying to cross a river, but doesn't actually cross the river. Even stranger, if I tell it to move to a non-adjacent cell, it seems that the ACP readout shows "ACP 1", when it should say "ACP 1/2"! This usually seems to happen when the unit could have avoided crossing the river and spent as many or fewer ACP's by going around it (no problems if there is no way around the river). Perhaps the same bug? Or at least a related bug? Perhaps someone who understands the recent changes to the pathfinding code could look at bolodd2.g and roman.g and make some sense out of this mysterious problem. Meanwhile, I'll keep looking for more clues... -- Lincoln Peters