Complete.Org: Mailing Lists: Archives: freeciv-ai: October 2003:
[freeciv-ai] Re: [Freeciv-Dev] (PR#6293) pf iterator design woes
Home

[freeciv-ai] Re: [Freeciv-Dev] (PR#6293) pf iterator design woes

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [freeciv-ai] Re: [Freeciv-Dev] (PR#6293) pf iterator design woes
From: "Per I. Mathisen" <per@xxxxxxxxxxx>
Date: Mon, 20 Oct 2003 02:02:55 -0700
Reply-to: rt@xxxxxxxxxxxxxx

On Mon, 20 Oct 2003, Raimar Falke wrote:
> Mixing these two for one map is possible but not encouraged. I would
> even go this far to disable it i.e. after your first call to
> pf_get_position you can't use pf_next and the other way around.

This is a possibility which is better than the current solution, which is
bug prone.

> > Say you pf_next() for a short-term attack target, and then find something
> > that looks promising, but before you make this decision, you just want to
> > know how far you are from your long-term target. Calling pf_get_position()
> > on this long-term target will likely screw up the iterator. So you must
> > create a second pf map to find this information. This is bug prone and
> > slow.
>
> If this is _really needed_ (please think hard about it) we have to
> redesign the PF code. However for this you first have to describe the
> semantics you want.

It is also possible to add a cache layer on top of pf. I have written
this, but I believe it is too slow.

> You want that pf_next and pf_get_position are independent?!

I don't understand what you mean by independent. It would be nice if we
could use them interchangably, but it is not critical. It is worse that we
cannot traverse the same pf map twice, but this is also not critical. Or
at least that is what I think right now. I might change my mind some other
day ;)

  - Per




[Prev in Thread] Current Thread [Next in Thread]