[Freeciv-Dev] Re: Hello; Elementarization of Unit Properties; New/Improved Info Screens

[Jörg Zuther <zuther.joerg@xxxxxxxxx>]

On Mon, 14 Jan 2002 09:08:27 +0100, Raimar Falke wrote:
> > 1. Elementarization of unit poperties:
> >
> >    Many properties/abilities are organized as a bunch, i.e.
> >    (see unittype.h/enum unit_flag_id)
> >    F_SETTLERS (contains all the worker abilities like irrigation,
> >                roads, mines, removing pollution, etc.)
> >    F_CARAVAN (contains helping wonders, establishing trade routes)
> >    F_DIPLOMAT (contains all diplomatic abilities)
> >
> >    Imho, it would be nice to have any elementary property/ability
> >    like road building and mining as an ability/property of its own
> >    that can be chosen for new unit types. E.g., you could design
> >    a unit called "railroad workers" that can only build railroads.
> >    (This example leads to another feature I would be interested in:
> >    to give all working abilities a respective effectiveness factor
> >    that can be chosen for each unit type. Maybe the flags could be
> >    replaced by integers that reflect the respective effectiveness,
> >    with 0 means that the unit type has not the respective ability/
> >    property.)
> >    What do you think?
> 
> Such a generalization is on the TODO list after the generalized
> improvement code (which we currently struggle with). It would be nice
> if these two share at least some ideas and the ruleset syntax.

OK, so I should gather info about the other subject first.


> While you are at a redesign: what about compound units (from AC)?

This would be great, of course. But would't this generate a huge
amount of problems/work? It starts with compatibility with Civ I/II
and ends with a graphical challenge.


> > Maybe it
> >    would be better first to analyse the necessary changes for the
> >    split patch and to put those changes into a set of other
> >    patches first, and make the split patch at last?
> 
> This is the usual way to do this. It is often that a patch shows some
> problems of the current code and a cleanup patch should be applied
> before the behavior changing patch is applied. Recent example is the
> tech_cost_style patch and the tech cleanup.

OK!


> >    Furthermore, has anyone made major changes to unittype.c?
> >    It is very likely that my patch would affect these changes
> >    in a nontrivial way. How should this be handled?
> 
> First come first served. But don't be afraid unittype.c isn't changed
> this often.

OK!


> > Building
> >    my patch onto existing but still not included ones? Or
> >    do it on the basis of the current version?
> 
> On the current CVS version. But for your development it may be good to
> have a stable ground. So you develop on a snapshot of the CVS and if
> you are finished update the patch for the now current CVS.

OK!


> > 2. New or more detailed charts:
> >
> >    E.g. in the cities chart,
> >    - the columns "workers", "surplus", "economy" and "currently
> >      building" should be splitted into several columns,
> >      respectively, so that you can sort wrt each elementary
> >      information.
> 
> There were are least two patches which addresses this problem.

I have searched on the site and found one of them. Btw, I don't
understand exactly all the classifications for the patches.
E.g. what means "not reproduced"? Are mac, win32, civserver and
wishlist applied or not? Can I read this kind of information
somewhere?


> >    - a set of columns (one for each unit type) which show the
> >      the number of units of the respective unit type in the city.
> >    - the same for buildings (well, of course showing only the
> >      (non)existence)
> 
> I also see a monitor problem here.

See my answer in another mail (will follow soon).

 ,,
Jorg