Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2001:
[Freeciv-Dev] Re: generalized unit capabilities
Home

[Freeciv-Dev] Re: generalized unit capabilities

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Andrew Sutton <ansutton@xxxxxxx>
Cc: Freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: generalized unit capabilities
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 5 Dec 2001 17:28:01 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Wed, Dec 05, 2001 at 09:26:23AM -0500, Andrew Sutton wrote:
> all,
> 

Patches please in unified format.

> here is a patch that provides a patch that extends the flag space of unit 
> capabilities. 

> for lack of anything better to do all the document is in-code using
> javadoc (so it will extract nicely :)

Doxygen is all nice but still nobody has send a patch to add a make
target for this.

> this patch basically extends the unit_flag from an enum to an array of 
> unsigneds. each index of the array contains a "category" where like flags are 
> grouped. category ids are found in the utype_category_id enum, the last value 
> of which defines the size of the array (CAT_LAST).
> 
> flags are redefined from enums to #defines (don't have to shift any more). 
> there's a documentation section at the bottom using doxygen that provides 
> space to actually document all the capabilities. i've only filled out some of 
> them.
> 
> this has been integrated into the ruleset configuration. i changed the 
> registry code to return 0 on a failed string lookup instead of exitting, and 
> then realized i was using the wrong lookup, but i forgot to take that fix 
> back out. it shouldn't really matter. exitting from within the parser is a 
> terrible form of error handling. i also didn't bother to change any of the 
> other lookups to test for that - net result will probably be a core dump if a 
> required configuration directive is missing. now that's good error handling - 
> it'll really let you know if you've messed up the ruleset :)
> 
> now, this code doesn't replace anything. the old flag structure is still 
> there because god knows what i'd break if i took it out. it also isn't 
> entirely complete. i only stuck a subset of total capabilities in there 
> because there's some stuff that wasn't documented too well.
> 
> so, here's the basic plan. take a look. if you like it, keep it. if you don't 
> like it - think of something better.

The question is still: why dislike you the flat namespace of the enum? 
Why do you need more structure?

About running out of space for bits for the flags: I agree that this
is a problem, but a problem which can be solved in a 100 lines patch.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Using only the operating-system that came with your computer is just
  like only playing the demo-disc that came with your CD-player."


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