Complete.Org: Mailing Lists: Archives: freeciv-ai: July 2004:
[freeciv-ai] (PR#9247) cm shouldn't count waste as a good thing

[freeciv-ai] (PR#9247) cm shouldn't count waste as a good thing

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [freeciv-ai] (PR#9247) cm shouldn't count waste as a good thing
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 17 Jul 2004 18:17:53 -0700
Reply-to: rt@xxxxxxxxxxx

<URL: >

> [bhudson - Fri Jul 16 16:42:52 2004]:

> > I like the idea but the patch doesn't apply (conflicts in cm.c) and
> > doesn't compile (factor_target is still used in some  of the GUI code).
> Doesn't apply?  Odd, I had just updated minutes before.  As for
> compiling for all the GUI front-ends, is there a convenient way of doing
> that?

Well some other patches were committed before I got to it.

> > It would also be nice to split it up into smaller patches, but that's
> > not strictly necessary.
> Looking more carefully, I wonder about removing factor_target -- what is
> the dio_... stuff?  I feel leery about changing an interface without
> need.  We could simply ignore the field, instead of removing it.  This
> also fixes the problem with GUI front-ends.

dio_*** is just network stuff.  Removing the factor_target will probably
require some network changes.  But now that factor_target is ignored we
need to remove it lest someone be tempted to use it.

Can you make a patch?

> Attached: one patch (cm-ign-...) that ignores factor_target but does not
> eliminate that field.
> Independantly, one patch (cm-1-...) that removes the duplicate functions
> from cma_core.c and makes them extern in cm.[ch] ; and one patch that
> depends on it (cm-2-...) that removes the production field (and, while I
> was at it, makes a couple things go from enumerating 0..5 into being a
> for loop).  

Very nice.


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