[Freeciv-Dev] Re: (PR#2370) Path finding
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
On Wed, 19 Feb 2003, Raimar Falke wrote:
> On Wed, Feb 19, 2003 at 08:20:11PM +0000, Gregory Berkolaiko wrote:
> > On Wed, 19 Feb 2003, Raimar Falke wrote:
> > > > >
> > > > > It is get_BMC and not get_cost.
> > > >
> > > > I never liked BMC or for that matter any of the abbreviations. They
> > > > are
> > > > not user-friendly and so reduce maintainability.
> > >
> > > "cost" is just too general.
> >
> > move_cost ?
>
> Same. You can use any name you like in the implementation but the
> interface should stay clean.
Hmmm, I wouldn't call an abbreviation like BMC "clean".
And you are being obstinate for obstinancy's sake as "move_cost" is not
too general. It can mean only one thing: cost of move. Term "basic"
doesn't help to make it more special.
But I don't really care...
> > > + node->behavior =
> > > + params->get_TB(x, y, node->node_known_type, params->get_TB_data);
> > >
> > > + node->extra_tile =
> > > + params->get_ECOT(x, y, node->node_known_type,
> > > + params->get_ECOT_data);
> > >
> > > Both can be done in the callbacks.
> >
> > You mean both requests for the known type? I agree.
>
> The known parameter is removed from the signatures and the called
> functions query the known state by itself if required.
Yes.
> > ZoC cannot be done in get_TB, because move_ZoC_allowed is a two-tile
> > function and TB is one-tile function
>
> Correct. Than we could add ZoC handling to get_BMC.
Ok.
> > > About the known-management: if we remove it from the core code:
> > > - it will reduce the number of parameters
> > > - it will reduce the size of the cell/node
> >
> > true. Less memory -- faster.
> >
> > > - it will increase run-time because of extra function calls to
> > > map_get_known by the user functions.
>
> > mind you, caching can still be done through void *data parameter.
> > We can pass pointer to caching map.
>
> Can you explain more?
we make
struct cached_values {
int is_initialized;
int known;
int zoc_number;
int behavior;
}
then
struct last_arg {
struct player *owner;
struct cached_values *vals;
} cache;
and then do (at fill_parameter time)
cache.vals = fc_calloc(...)
get_BMC_data = &cache;
get_ECOT_data = &cache;
then inside, say, get_BMC, we do
if (!data->vals[index].is_init) {
data->vals[index].known = is_known_tile(x, y, owner);
// .....
}
if (data->vals[index].known == TILE_UNKNOW) {
return 0;
}
Almost the same as we have now, just done in callbacks themselves.
G.
- [Freeciv-Dev] Re: (PR#2370) Path finding, (continued)
- [Freeciv-Dev] Re: (PR#2370) Path finding, Ross Wetmore, 2003/02/22
- [Freeciv-Dev] Re: (PR#2370) Path finding, Raimar Falke, 2003/02/22
- [Freeciv-Dev] Re: (PR#2370) Path finding, Gregory Berkolaiko, 2003/02/19
- [Freeciv-Dev] latest aidiplomat.c changes, Per I. Mathisen, 2003/02/19
- [Freeciv-Dev] Re: (PR#2370) Path finding, Raimar Falke, 2003/02/19
- [Freeciv-Dev] Re: (PR#2370) Path finding, Gregory Berkolaiko, 2003/02/19
- [Freeciv-Dev] Re: (PR#2370) Path finding, Raimar Falke, 2003/02/19
- [Freeciv-Dev] Re: (PR#2370) Path finding,
Gregory Berkolaiko <=
- [Freeciv-Dev] Re: (PR#2370) Path finding, Raimar Falke, 2003/02/19
- [Freeciv-Dev] Re: (PR#2370) Path finding, Gregory Berkolaiko, 2003/02/19
- [Freeciv-Dev] Re: (PR#2370) Path finding, Raimar Falke, 2003/02/19
- Message not available
- [Freeciv-Dev] Re: (PR#2370) Path finding, Jason Short, 2003/02/19
- [Freeciv-Dev] Re: (PR#2370) Path finding, Gregory Berkolaiko, 2003/02/20
- [Freeciv-Dev] Re: (PR#2370) Path finding, Raimar Falke, 2003/02/20
- [Freeciv-Dev] Re: (PR#2370) Path finding, Gregory Berkolaiko, 2003/02/21
- [Freeciv-Dev] Offtopic: Re: Re: (PR#2370) Path finding, Andreas Røsdal, 2003/02/21
- [Freeciv-Dev] Re: Offtopic: Re: Re: (PR#2370) Path finding, Raimar Falke, 2003/02/21
- [Freeciv-Dev] Re: (PR#2370) Path finding, Gregory Berkolaiko, 2003/02/21
|
|