From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21712 invoked by alias); 4 Dec 2003 00:22:07 -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 21704 invoked from network); 4 Dec 2003 00:22:06 -0000 Received: from unknown (HELO smtp14.fre.skanova.net) (195.67.227.31) by sources.redhat.com with SMTP; 4 Dec 2003 00:22:06 -0000 Received: from [212.181.162.155] (h155n1fls24o1048.bredband.comhem.se [212.181.162.155]) by smtp14.fre.skanova.net (8.12.10/8.12.10) with ESMTP id hB40M1MT028045; Thu, 4 Dec 2003 01:22:02 +0100 (CET) X-Sender: u22611592@m1.226.comhem.se Message-Id: In-Reply-To: <20031203221319.GA1306@leonardo> References: <20031201094951.GB812@leonardo> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 04 Dec 2003 06:34:00 -0000 To: Peter Garrone From: Hans Ronne Subject: Re: transport and the bug + fixed Cc: xconq7@sources.redhat.com X-SW-Source: 2003/txt/msg00960.txt.bz2 > With respect to the desynch bug, one obvious possibility did occur to me. >If the > pathfinding is invoked from the mplayer or ai code, then the found path > is cached in the local process, but not in other processes. Then when > the non-local process has to find a direction, it will usually find the > same path, but there is a possibility that conditions have changed and > a different path could be > found and cached, causing differences down the track. So this should > possibly give you a line of attack on the problem. This was indeed the case! I nuked the cahce code and the desynch bug went away. Further experiments showed that nuking get_dir_from_cache is all that is required. path_get_next_cached_move and path_get_next_cached_node do not contribute to the desync. Which is good, because taking out these functions as well has a huge impact on performance. The bad news is that no transports or bombers are ever built. I thought previously that this was a consequence of the move.c hack (off-list discussion) but apparently this is a general problem with the current path-finding code which has nothing to do with the desynch. I have seen other problems with transport path-finding as well, such as ships getting move-to tasks to inland destinations. I have not tested yet if these problems are still there in your latest developmental code. In any case, I will check in the get_dir_from_cache hack. We can worry about correct transport path finding later. It is good to be back in sync! Hans