* Re: transport and the bug
[not found] ` <l03130300bbf4024592fd@[212.181.162.155]>
@ 2003-12-04 0:22 ` Peter Garrone
2003-12-04 6:34 ` transport and the bug + fixed Hans Ronne
0 siblings, 1 reply; 2+ messages in thread
From: Peter Garrone @ 2003-12-04 0:22 UTC (permalink / raw)
To: Hans Ronne; +Cc: xconq7
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
^ permalink raw reply [flat|nested] 2+ messages in thread