Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2001:
[Freeciv-Dev] Re: unit flags/capabilities
Home

[Freeciv-Dev] Re: unit flags/capabilities

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: unit flags/capabilities
From: Andrew Sutton <ansutton@xxxxxxx>
Date: Thu, 29 Nov 2001 09:47:29 -0500

> > 1. it's a clumsy implementation.
>
> From both points of view it is ok: the ruleset writer can do a nicely
>   flags         = "IgTer", "IgZOC"
>   roles         = "DefendGood", "Partisan", "BarbarianTech"
> and the programmer can do nicely
>   ./client/control.c:    if(unit_flag(punit_focus, F_CARAVAN))
>
> So these are the end points (the interfaces). You may now say that the
> implementation between these endpoints is bad. I don't think so.

not a big deal. the whole point is that i engineered the new stuff to run 
along side the old stuff so it doesn't require a complete rewrite. the 
ruleset interface will just be an extension of the current one with each flag 
category getting an assignment.

// for a settler
movement_class = Land
combat_class = Defenseless
build = City Fortress Airbase
improve = Irrigate Mine Road Rail

the programmatic interface changes a little bit, but we introduce a new 
method name to allow coexistence.

unit_test_flag( struct unit *, unit_flags *, unsigned flags );

> > 2. it isn't very extensible
>
> You first have to state in which direction and why you want to
> extend. What is the goal? What is the interface you want to achive?

the interface isn't the goal. its the creation of a gracefully extensible 
capability description for all units. the entire purpose is to tie all this 
information into a single uniform resource.

> > 3. it groups widely different types of data together into one bitfield.
>
> Data which are all flags (booleans) and may be used independently. You
> can have a unit which have the F_SPY,F_MARINES,F_IGTIRED flags. A
> bitfield is a quite good implementation.

yes. and it still is a bitfield implementation :) except now, there's alot 
more bit space to choose from.

> > 4. it separates out data that should be there.

things like diplomacy actions, settler actions. these are all capabilities 
that can be brought under the auspices of a single flags settings. uniformity 
is the goal.

> We both know that such a way would require a major
> rewrite. Fortunately freeciv doesn't have this many types and would is
> doesn't require a big flexibility because the set of types is more or
> less constant. I agree that from a programmers point of view it may be
> nicer to have a finer grained type set like struct land_unit, struct
> water_unit and struct air_unit.

that might be a good initial derivation. i can't think of any reason why you 
wouldn't do that.

>   struct {
>     int fuel;
>   } air_unit;
>   struct {
>     enum unit_activity activity;
>     int activity_count;
>     int activity_target;
>     int connecting;
>   } settler;

that's just grouping parameters. it doesn't really achieve the desired 
inheritence effect - although it does explicitly separate out the information.

andy


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