From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22835 invoked by alias); 20 Dec 2003 23:49:03 -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 22828 invoked from network); 20 Dec 2003 23:49:02 -0000 Received: from unknown (HELO acaymail.tel-pacific.com) (203.88.255.16) by sources.redhat.com with SMTP; 20 Dec 2003 23:49:02 -0000 Received: from leonardo (acay007133171.acay.com.au [203.7.133.171] (may be forged)) by acaymail.tel-pacific.com (8.12.8/8.12.8) with ESMTP id hBKNmxR0021821; Sun, 21 Dec 2003 10:48:59 +1100 Received: from garrone by leonardo with local (Exim 3.35 #1 (Debian)) id 1AXr0i-0000d7-00; Sun, 21 Dec 2003 10:59:52 +1100 Date: Sun, 21 Dec 2003 02:36:00 -0000 From: Peter Garrone To: Hans Ronne Cc: xconq7@sources.redhat.com Subject: Re: pathfinding refueling Message-ID: <20031220235952.GA2224@leonardo> References: <20031220065220.GD1667@leonardo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-SW-Source: 2003/txt/msg01095.txt.bz2 On Sat, Dec 20, 2003 at 11:48:59PM +0100, Hans Ronne wrote: > >> I have spent hours on all these emails. I would rather just code up my > >> approach now thanks. Fat chance. > > > >So then code it up. I already told you that I am not stopping you > >(I cannot stop you). Just don't expect me to check it in; I think > >your proposed solution is a bit narrow-minded in some cases. > > I think it is perhaps time to conclude this discussion and move on. There are many constructive comments in this thread, particularly from Hans. This is very helpful. It is tricky territory though. > The new > path-finding code is a significant improvement, and I would very much like > it to be included in the 7.5 release. However, there are three problems > that must be solved first: > > 1. Sync errors (unless the cache is disabled). > 2. Ferry problems. > 3. Resupply problems. > > If Peter can fix these problems, this will be a major contribution which is > certainly welcome. Maybe it doesn't address all possible scenarios, but we > can't let perfection be the enemy of good. Further improvements to the code > can always be made later, if necessary. I am trying to address all these. I think we should accept that it will be a major development though. I should have some time over the next few weeks. > > As for supporting more than one fuel, which is what much of the discussion > has been about, it is easy to do so if the path is recomputed when the unit > reaches a resupply point. And we already agreed that frequent > recalculations of the path is a good idea. All it would take is to check > what material is currently limiting the range, and use it as "fuel" in the > new path calculation. This would allow more than one material type to be > considered as fuel, and at the same time avoid the computational problems > that several fuel types would cause in any given path calculation. Perhaps dynamically changing the fuel type is the way but I cant see it right now. For now I plan to implement a multiple refuel of all material types that could constrain movement at resupply points, and if it is out of any such material in that it could not top up the unit, disallow that resupply point, both in the path-finding, and in the actual movement. But only the fuel type giving the minimal range will be actually tracked in the path-finding node state. It should be unnecessary to change fuel types in this manner because if the unit cannot be supplied with sufficient quantities of all fuel types, then both the pathfind will fail or the actual move task will fail. I do not think i was planning to do this before this thread, so this has developed anyhow. There is no way to tell in the pathfind that some other material than the tracked fuel is in short supply, because only the main fuel is tracked. > > I would therefore encourage Peter to go ahead with his scheme but include > dynamic recalculations of the path as often as is practical, and also make > the choice of which material type should be considered as "fuel" dynamic, > depending on the unit's supplies. > > Hans > Thanks for your contribution. But I would urge anyone who has any input to continue to provide it. If an algorithm is suggested, and I cannot think of a reason good why it wouldnt work, then I would use it. It is actually quite helpful to knock suggested algorithms over. Peter