Complete.Org: Mailing Lists: Archives: freeciv-dev: June 2002:
[Freeciv-Dev] Re: [RFC] Path finding implementation.
Home

[Freeciv-Dev] Re: [RFC] Path finding implementation.

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Cc: Freeciv Development List <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [RFC] Path finding implementation.
From: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Thu, 6 Jun 2002 12:52:48 +0100 (BST)

On Wed, 5 Jun 2002, Raimar Falke wrote:

> On Wed, Jun 05, 2002 at 06:36:01PM +0100, Gregory Berkolaiko wrote:
> > On Wed, 5 Jun 2002, Raimar Falke wrote:
> > 
> > Why so categorically, "should use"?  Why not pass all the parameters as 
> > the arguments?  Where is the advantage in having a spoof data structure 
> > which is never used?
> > 
> > You are probably right, but please give reasons.
> 
> The struct is faster because you can reuse the struct and only have to
> change certain fields. Well this isn't such a big argument.
> 
> enum unit_move_result test_unit_move_to_tile(Unit_Type_id type,
>                                              struct player *unit_owner,
>                                              enum unit_activity activity,
>                                              bool connecting, int src_x,
>                                              int src_y, int dest_x,
>                                              int dest_y, bool igzoc);
> 
> has 9 arguments. Version 10's pf_parameter contains 17 fields. Can you
> expect how messy this will be? However we are far from the limits:

In my opinion 17 is a bit exaggerated ;)

You need: 
* pplayer       (for ZOC and vision-related things)
* x0, y0        (obvious)
* move_rate     (for correct calculation of BMCs)
* initial_moves (for correct calculation of AMCs)
* turn_mode     (   ditto   )
* costfn        (BMC function itself)
* extrafn       (extra cost function itself)
* igzoc         (but maybe we can manage without it)

You can comment function prototype as well as a struct, but the struct has 
the advantage of having named fields.

Also, I wouldn't want anything but the service code use either 
pf_parameter or this rather big function call.  But maybe service code can 
be allowed to fill the pf_map struct directly?

[...]

> > > > ZOC, yes, I forgot about it.  It can be done via (maybe even 
> > > > user-supplied) function is_enemy_zoc(int x, int y, struct player).
> > > 
> > > I though we have agreed that user supplied zoc checking is useless?!
> > 
> > Let me think again (I actually don't remember ever thinking about it, I 
> > think it was you arguing with yourself and then reaching an agreement with 
> > yourself.  I was too afraid to interfere ;)...
> 
> ;)
> 
> You didn't object so I took this as an agreement ;)
> 
> > Some goto-related code uses a rather esoteric function goto_zoc_ok...
> > 
> > There is no need to have an end-user-specified function, but maybe some
> > service code could specify it.  It really depends if we want to convert
> > find_the_shortest_path to use PF module.  That'd be a messy job though.
> 
> You will see that the zoc function can be splitted and cached
> nicely. So the zoc function is rather ditributed in the code (at least
> in my code).

Please share your code with us ;)

G.




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