Re: transport and the bug

Re: transport and the bug

[Peter Garrone]

On Wed, Dec 03, 2003 at 10:22:40PM +0100, Hans Ronne wrote:
> >mod 1. Need to consider not only occupants but if the transport is
> >actively on its way to pick up another unit. this complicates things,
> >but I am still struggling with a single unit solution.
> 
> Precisely. When I was working on a PLAN_TRANSPORT i experimented with a
> busy flag that blocked further pickups if occs were being delivered
> somewhere. Even if it causes the transports to run half empty, this mode of
> operation is frequently more efficient than trying to fill it up by waiting
> for more units to board. It all depends on the transport distance of course.
> 
> >mod 2. What if the transport is in another disconnected ocean? Big
> >problem. What if a whole lot of transports are there.
> 
> I had to deal with the same problem in the supply code. I added this
> landsea_regions area layer that is precomputed at startup time. You can use
> it to determine if any give cell is connected to another cell of the same
> type (liquid or not) without further computations.
> 
> Hans
>

Hi,

 I extended the "type_can_occupy" function so that it will calculate its
 fullness based on its current occupants and an array of units that
 represents its existing scheduled pickups. In this way it will fill up.

 A small problem might occur if units are going from a central point to
 widely dispersed points, so perhaps some grouping of dropoffs is
 important when calculating the "highjacking".

 At the moment I am struggling with prior plans/tasks causing the full
 transport to sail off to a point into the middle of an ocean then
 return. Also transports get told to hit an aircraft in the middle of
 the land somewhere, so just sit there, doing nothing, while units are
 waiting for transport. Also waiting units abort their move just before
 a transport reaches them, so dont board because they are on hold. So
 there are a few problems yet. The whole exercise is a study in why
 computers wont take over the world. I still have to understand this
 code structure fully, with plans, goals, tasks, doctrines.

 I did try to implement the PLAN_TRANSPORT, but gave up with the ai.
 However it would be extremely useful for a human to be able to assign
 a ferry to ferrying duties, then units could board ferries automatically.
 But I couldnt see a way in the interface to easily assign a unit to a
 plan for a human player.

 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. The ai code should
 still invoke pathfinding, but should turn off the caching. Or a moveto
 task could clear the current cache for that unit and calculate a new
 path. In my developing code, the only tasks that pathfind are moveto
 and pickup tasks.
 
 I am out of circulation for about 10 days.  
 Please reply to the list, as my email will probably fill up with spam
 and become unreilable.
 Peter

Re: transport and the bug + fixed

[Hans Ronne]

> 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