[Freeciv-Dev] Re: Hello; Elementarization of Unit Properties; New/Improv
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
On Mon, Jan 14, 2002 at 12:02:15AM +0100, Jörg Zuther wrote:
> Hello,
>
> I'm new on this list and want to contribute to the project
> for several reasons:
>
> - I enjoy civ-style games very much; this is an opportunity
> to make my wishes becoming reality.
> - Learning C.
> - Learn what it means to program a game.
>
> OK, I want to work on the following subjects:
>
> 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.
While you are at a redesign: what about compound units (from AC)?
> There's a patch from Gregor Zeitlinger splitting F_CARAVAN into
> the two elemental abilities.
>
> I have begun with the F_SETTLERS split but encountered many
> difficulties in the AI and elsewhere. For example, it seems
> that best_role_unit in unittype.c needs an overhaul so that
> it can test any combination of required properties/abilities
> of a unit. I fear that this patch could grow huge.
> 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.
> 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.
> 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.
> 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.
> - there should be a column showing the continent/island the
> city is on.
Yes.
> - total of trading points generated by trading routes
Yes.
> - 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.
> Example for a new chart: The unit chart
> - lists informations for each unit you have. You can center
> on each unit on the list by double-clicking it
> - columns for coordinates
> - column for goto-target (city or tile)
> - there should be a column that shows the damage status or
> something like that
> - column for nearest friendly city
> - column for nearest hostile city
> - etc.
Nice idea.
> Overall, it seems to me that it this subject is much easier
> to patch than the first one.
I agree.
Raimar
--
email: rf13@xxxxxxxxxxxxxxxxx
"The very concept of PNP is a lovely dream that simply does not translate to
reality. The confusion of manually doing stuff is nothing compared to the
confusion of computers trying to do stuff and getting it wrong, which they
gleefully do with great enthusiasm."
-- Jinx Tigr in the SDM
[Freeciv-Dev] Re: Hello; Elementarization of Unit Properties; New/Improved Info Screens,
Raimar Falke <=
[Freeciv-Dev] Re: Hello; Elementarization of Unit Properties; New/Improved Info Screens, Jörg Zuther, 2002/01/15
[Freeciv-Dev] Re: Hello; Elementarization of Unit Properties; New/Improved Info Screens, Petr Baudis, 2002/01/14
|
|