Complete.Org: Mailing Lists: Archives: freeciv-dev: August 1999:
Re: [Freeciv-Dev] Re: patch: remove remaining hardwired tech effects (PR
Home

Re: [Freeciv-Dev] Re: patch: remove remaining hardwired tech effects (PR

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: sebauer@xxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx, bugs@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Freeciv-Dev] Re: patch: remove remaining hardwired tech effects (PR#118)
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Tue, 31 Aug 1999 15:30:45 +1000 (EST)

sebauer@xxxxxxxxxxx (Sebastian Bauer) wrote:

> > This patch adds some more data about techs to ruleset files, so
> > that the tech_type_id enum values are not used anywhere in the code.

> Great :-)
> I have send a patch a short time ago, which does this too ;-)
> But it's little bit more general, because I use flags. And
> it should also be variable and extendable (but not tested yet)

Good!  As I mentioned, it seemed like these should use flags,
but I was too lazy to implement the framework ;-)

Except, there is one way that lists benefit over flags: lists
allow explicit _ordering_.  For the techs, this applys for
the population pollution tech, but not really others.

Actually this point _does_ also apply for unit types, where
the order of the unit type sections in the ruleset is used
instead, which is potentially a hassle and a restriction
on generality.  (Eg for techs you don't want to have to
re-order the overall tech list just to get the population
pollution techs in the appropriate order.)  By listing unit
types for each flag instead of flags for each unit type,
you could express the ordering explicitly and with generality.

So actually in some ways lists win over flags :-/
(Though of course one could still utilize flags internally 
for easy lookup.)

> > Added game.rtech entries for:
> > +    int temple_plus;           /* eg Mysticism */
> > +    int construct_bridges;     /* eg Bridge Building */
> > +    int construct_fortress;    /* eg Construction */
> > +    int construct_rail;        /* eg Railroad */
> > (temple_plus in buildings.ruleset, others in techs.ruleset)
> 
> I have this done as flags. This would allow differnt tech
> trees for e.g. modpack writers.

Yep, flags win over single values.  :-)
 
> In my patch Population Pollution has already implemented as a flag.

So how did you handle the ordering problem?

One solution in this case would be to slightly change the rule,
so that its the number of pop_pollution techs which count,
and not just the highest one known by the player.

(That is, currently there is a list: A, B, C, D, and if the
player knows tech C but not A, B or D then pollution is 
times 3, (index of tech C counting from 1).  It could be
changed to simply the number of techs from this set.)

-- David

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