From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32648 invoked by alias); 21 Dec 2003 00:28:19 -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 32634 invoked from network); 21 Dec 2003 00:28:18 -0000 Received: from unknown (HELO smtp14.fre.skanova.net) (195.67.227.31) by sources.redhat.com with SMTP; 21 Dec 2003 00:28:18 -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 hBL0SD4h018530; Sun, 21 Dec 2003 01:28:14 +0100 (CET) X-Sender: u22611592@m1.226.comhem.se Message-Id: In-Reply-To: <20031220220620.GA725@leonardo> References: <20031218063340.GA733@leonardo> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 21 Dec 2003 07:22:00 -0000 To: Peter Garrone From: Hans Ronne Subject: Re: pathfinding refueling Cc: xconq7@sources.redhat.com X-SW-Source: 2003/txt/msg01096.txt.bz2 >This heuristic should work. After refueling successfully at a refueling >point, a units checks its next refueling point by examining the cached >path. > >If it has insufficient movement points >to reach the next point in the move, and it has used some mp this turn, >and the next point is a mobile >unit, it goes into reserve for that turn, >and rechecks at the start of its next turn. Yes, if fuel consumption is per-move. If it is per-turn, going into reserve makes little sense. Unless it can resupply itself from the terrain, of course. >Obviously there are some extraordinary situations that would defeat >this. Too many aircraft could such the carrier dry. The carrier could be >sunk, or die somehow. But we only want something simple that mostly >works. Agreed. Accidents happen in real life, too. >I dont think it is up to the pathfinding to ensure supply, otherwise it >replicates the supply code. Rather the human or ai player should not >send units on extended moveto tasks if running out. However the >pathfinding could ensure that units skirt around local shortages of >av-fuel, sea-oil, "c". Yes. But we must still check the treasury in order to decide what materials should at all be considered as fuel. >> Assigning a new task is what I had in mind. A move-to task to the closest >> point on the failed path. Which means that the path-finding code would have >> to return that point to the AI when it fails. >> >> As for ships getting tasks that they cannot possibly reach, this is really >> an AI problem. I would say that the best way to handle that is to let the >> AI use the landsea_regions area layer to check if a possible destination is >> reachable for a unit that cannot be ferried. > >No. If the pathfinding fails, then there really will be no way for that >task to succeed, not even by developing the technology to build a ferry >and by building a ferry. The ai would be better off selecting a completely >different mission for that unit. The pathfinding means that the ai has >much better ability to determine which missions have any chance and which >have none. I think getting closer to the enemy is generally a good idea, even if you cannot reach him. At least, you can perhaps stop him from invading you by massing your troops on the beaches. However, finding a new plan is a good alternative. The problem is that the AI will do neither. It will keep the plan, typically a PLAN_OFFENSIVE which assigns the unit to hold an area which it cannot reach, and then set the same move-to task resulting in the same path failure over and over again. This is what I meant when I said that it is really an AI problem rather than a path-finding problem. The AI should check if a point is at all reachable already at the plan level. This could be done by using the landsea_regions area layer, path-finding, or a combination of both. If the plan goal is not possible, the AI should replan instead of proceeding with impossible tasks. >> Yes. It depends on how big the computational load is. The optimal solution >> would be once each turn, right before the unit moves, so that the tactical >> situation always is up-to-date. This is how the action-reaction code works. >> But if we cannot afford that, I would suggest at least at the following >> points: >> >> 1. When the unit leaves a resupply point (so that it may check what >> material is currently limiting its movement and use it as fuel in the path >> calculation). > >I think my suggested heuristic ovecomes this. It investigates the next cached >resupply point, and if it is out of any sort of fuel, or has moved, then >recalculate. > >> 2. When a unit leaves a ferry. > >I am not in complete agreement here. >The ferry will drop a unit off at its planned point. >Perhaps when a ferry drops off a unit, a recalculation for all >other occupants might be justified, because the current dropdown point might >be better than the scheduled point for a unit. This should provide sufficient >tactical flexibility. My thinking was that after the unit has been sitting x number of turns on a ferry, the tactical situation has changed. And it is the unit that gets off that has to worry about blocking enemy units etc. So a path recalculation at this point seemed like a good idea. >> 3. When its movement is obstructed in any way. > >What do you mean by obstruction? The pathfinding will naturally move >around terrain obstructions, and also calculate optimal paths based on >friendly units moving out of the way to an extent. But if an action >suggested by the pathfinding fails, then it would probably be reasonable >for a re-calculation. That's what I meant. The prime example being an enemy unit that blocks the path. >One point is that with refueling and a more sophisticated >transportation ferrying model, pathfinding will become quite expensive. >There are some very big games in the library, so some care needs to be >taken. I agree. Only testing can tell what we can afford in the end. And I think getting the path cache to work without desync problems will be critical. The code is much faster with it. Hans