From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16960 invoked by alias); 20 Dec 2003 06:44:40 -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 16952 invoked from network); 20 Dec 2003 06:44:38 -0000 Received: from unknown (HELO acaymail.tel-pacific.com) (203.88.255.16) by sources.redhat.com with SMTP; 20 Dec 2003 06:44:38 -0000 Received: from leonardo (acay007133204.acay.com.au [203.7.133.204] (may be forged)) by acaymail.tel-pacific.com (8.12.8/8.12.8) with ESMTP id hBK6hFR0032026; Sat, 20 Dec 2003 17:43:16 +1100 Received: from garrone by leonardo with local (Exim 3.35 #1 (Debian)) id 1AXaOX-0000U4-00; Sat, 20 Dec 2003 17:15:21 +1100 Date: Sat, 20 Dec 2003 16:09:00 -0000 From: Peter Garrone To: Hans Ronne Cc: xconq7@sources.redhat.com Subject: Re: pathfinding refueling Message-ID: <20031220061521.GC1667@leonardo> References: <20031218063340.GA733@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/msg01086.txt.bz2 On Fri, Dec 19, 2003 at 02:42:58AM +0100, Hans Ronne wrote: > I think we need to refocus this discussion on how to handle refueling in > the best way. Peter's inital analysis had a lot of good points in it, but > so do some of Eric's comments. Here are my own reflections: > > >Refueling points are units whose capacity and current supply exceeds the > >travelling units capacity, are either immobile or have a "refueling" > >task. > > I would consider anything that has excess fuel a refueling point, even if > mobile and on a move-to task. Think of a carrier moving across the ocean on > its way to the enemy shore. It must be able to launch combat air patrols > while in transit and the latter must be able to find their way back to the > carrier for refueling. > > What should be considered excess fuel is the key question. In the standard > game, I found some time ago that airplanes almost never resupplied from > carriers, since the threshold was too high. I therefore lowered it. See > ChangeLog 2003-08-17 for details. What if the path was precalculated several turns before and the unit has moved on. A plane could run out of fuel and crash. It becomes a coordination problem if the carrier is moving. If you can tell me how to solve this, I'll do it your way. > > > > >1) The storage of that material is greater than zero > > > > > > Does this include treasury storage? > > > >Its not a fuel if it is not consumed every turn or hex. > > I think Eric was making the point that it is possible for fuel to be > consumed every turn or hex, but then filled up again at the start of each > turn from the treasury. This is a valid point, but it should be relatively > easy to handle. I would not consider it a fuel for pathfinding purposes in that situation because there is no need to go to a supply point and refill. I would assume that the supply code would replenish each turn. > > >Maybe we need to take a more piecewise approach to path-finding. > > > >So we don't try to calculate the entire path ab initio (which > >would require considering multiple fuel types and would be messy), > >but rather do it in segments.... > > This is an interesting point not only with respect to refueling, but for > path finding in general. One problem with the new path code is that if a > unit cannot find a path to its destination, it does not move at all. It > just sits where it is and accumulates failed move-to tasks. With the old > code, a unit would move in the direction of its target even if it could not > get there. Problems such as blocking enemy units or a lack of transports > (maybe because the necessary advances had not yet been researched) would > frequently get solved while the unit was on its way, and the side would > gain time, which is always important. Segmentation makes the whole thing suboptimal. It is relatively straightforward to allow ferries to be constructed and even developed in the pathfinding code so I hope that addresses the situation. > > The point here is that a war is a very dynamic situation. Tactical > decisions, including path finding, should be reconsidered frequently since > conditions may change rapidly. It could therefore make sense, as Eric > suggests, to recompute paths on every leg of a journey, and also to > reconsider what material is currently limiting the range (and thus to be > considered as fuel) for this unit here and now. To this I would add that if > a clear path to the destination cannot be found, any move that takes the > unit closer to its destination should be considered. I disagree somewhat. If there is no way, then that is simply that. The ai or whatever should assign the unit a different task. What if a ferry is assigned a hit-unit task on an enemy aircraft in the middle of a continent? > > The notion of precomputing a complex path involving perhaps both ferry > tasks and visits to multiple resupply points is very neat. I am therefore > not saying that one should not calculate the entire path ab initio (as Eric > put it). What I am suggesting is that a unit should stop at each leg on its > journey and dynamically reconsider how to best get where it wants to go, > just like a human would do. This would not be overly burdensome and it > would make path finding much more adaptive. I would agree actually. Not every hex, perhaps every other turn or something like that. > > A final comment is that this is also how the combat code has evolved over > the last few years. The strategy code was originally much more important. A > unit would get assigned to a theater, move there, and hold a position, with > no consideration for what would happen on the way. A unit in transit would > not attack enemy units or come to the rescue of beleaguered cities. This > lack of flexibility made it very easy to beat the mplayer. For this reason, > we added the action-reaction code which dynamically reassesses what the > unit should do. The AI is preety interesting in that often extremely simple algorithms have the best effect. It is somewhay beyond my conceptual capacities at the moment though. Obviously we need to stop it losing aircraft etc to lack of fuel. > > I think that in general, an AI that dynamically recomputes its tasks > (within reasonable limits) will do much better than a static AI which > adheres to a precomputed grand plan for each of its units. > > Hans Agreed. Peter > > > > > >